How Does synchronized Work in Java?

synchronized is built on intrinsic locks, also called monitors. Every Java object has one. When a thread enters a synchronized block or method, it acquires the monitor of the object named in the synchronized clause, and it releases it when the block exits — normally, by throwing, or by returning.

The difference between the two forms is which object is locked and how wide the lock is. A synchronized instance method locks this — the receiver of the call — for the whole method body. A synchronized static method locks the Class object of the declaring class. A synchronized block locks exactly the object you name, and only for the statements inside the braces.

public class Main {
    public static void main(String[] args) {
        Counter counter = new Counter();
        Runnable task = () -> {
            for (int i = 0; i < 1000; i++) {
                counter.increment();
            }
        };

        Thread a = new Thread(task);
        Thread b = new Thread(task);
        a.start();
        b.start();
        try {
            a.join();
            b.join();
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }

        System.out.println("expected 2000, got " + counter.value());
    }
}

class Counter {
    private int count;

    synchronized void increment() {
        count++;
    }

    synchronized int value() {
        return count;
    }
}

The output shows the count reaching exactly 2000, which is what the counter would report if the increment were atomic. Without the synchronization, the read-modify-write inside count++ could interleave between the two threads and lose an update.

The recommendation is to prefer a synchronized block on a private lock object over a synchronized method, for two reasons. A synchronized method exposes this as a lock, which means any other code that obtains a reference to your object can also lock it — including code you do not control. And a synchronized method holds the lock for its entire body, including the parts that do not need it, which is a lot of unnecessary contention in a method that does IO.

A monitor is the lock associated with an object. Every Java object has one, whether you use it or not. When a thread executes synchronized (someObject) { ... } it acquires that object's monitor, and it holds it until the block exits.

When two threads contend for the same monitor, exactly one of them gets it and the other waits. The waiting thread moves to the BLOCKED state and is placed in the monitor's entry set. When the holder releases the monitor, the JVM picks one of the blocked threads — there is no fairness guarantee about which one — and it becomes runnable. The waiting thread does not spin; it is parked, which is why it costs nothing while it waits.

Two details matter. The monitor is reentrant: a thread that already holds a monitor can acquire it again, and it must release it the same number of times. That is what lets a synchronized method call another synchronized method on the same object without deadlocking. And every object has a monitor, including String literals and objects from the JDK, which is exactly why synchronizing on a shared object is dangerous.

The wait and notify methods behave differently from ordinary monitor operations. Calling wait() releases the monitor and parks the thread, which is how a thread lets others in. But wait may only be called while holding the monitor, and it can only be woken by a notify or notifyAll from another thread that also holds the monitor. That handshake is the basis of every producer-consumer queue written with plain synchronization.

Because a synchronized method publishes this as a lock, and a synchronized block does not have to.

When you write synchronized void increment(), the lock is the receiver. Any other code in the whole program that has a reference to that object can call synchronized (obj) { ... } and block your increment. If the object is something you return from a public method — a shared cache, a domain object handed to a callback — then external code can interfere with your internal locking, or worse, hold your lock while doing something slow. Locking on a private final object that never escapes the class removes that possibility entirely.

The second reason is that a synchronized block is narrower. A synchronized method holds the lock across its entire body, including any code that does IO or calls out to other components. Two threads calling that method are serialised for the whole duration even though only the field update needs to be exclusive. A block lets you protect exactly the critical section.

public class Main {
    public static void main(String[] args) {
        BadCounter bad = new BadCounter();
        GoodCounter good = new GoodCounter();

        Runnable task = () -> {
            for (int i = 0; i < 1000; i++) {
                bad.increment();
                good.increment();
            }
        };

        Thread a = new Thread(task);
        Thread b = new Thread(task);
        a.start();
        b.start();
        try {
            a.join();
            b.join();
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }

        System.out.println("bad  : " + bad.value());
        System.out.println("good : " + good.value());
    }
}

class BadCounter {
    private int count;

    void increment() {
        // Dangerous: every part of the program that locks the same
        // interned literal is contending for the same monitor.
        synchronized ("LOCK") {
            count++;
        }
    }

    int value() {
        synchronized ("LOCK") {
            return count;
        }
    }
}

class GoodCounter {
    private int count;
    private final Object lock = new Object();

    void increment() {
        synchronized (lock) {
            count++;
        }
    }

    int value() {
        synchronized (lock) {
            return count;
        }
    }
}

The output shows both counters reaching 2000. The bad version is correct but fragile — it locks on an interned string literal, and any other code anywhere that locks the same literal contends for the same monitor, for no good reason. The good version locks on a private object that never leaves the class, so the monitor is entirely under its control.

There is a third problem with locking on a string literal that people forget: string literals are interned, so "LOCK" in two different classes is the same object, and therefore the same monitor, even though the two classes have nothing to do with each other.