Understanding Java Synchronization: `synchronized` and Monitors

The Intrinsic Lock: Every Object's Guardian

In Java, every object has a single, built-in lock associated with it. This is called an intrinsic lock or a monitor. This monitor is the mechanism that the synchronized keyword uses to control access. When a thread wants to execute a synchronized method or block, it must first acquire the monitor of the associated object. Only one thread can "own" a monitor at any given time.

The key to understanding synchronized is identifying which object's monitor is being used.

• Synchronized Instance Methods: The lock is acquired on the monitor of the instance itself (the this object).
• Synchronized Static Methods: The lock is acquired on the monitor of the Class object representing the class in which the method is declared.
• Synchronized Blocks: The lock is acquired on the monitor of the object provided in the parentheses.

This distinction is crucial. Two threads can execute a synchronized static method and a synchronized instance method of the same class concurrently, because they are locking on two different objects (MyClass.class and an instance of MyClass, respectively).

The following video provides an excellent walkthrough of these different synchronization contexts.

The Conceptual Model of a Java Monitor

Now that you know every object has a monitor, let's visualize how threads interact with it. A monitor can be conceptually understood as a building with only one room (the critical section) and a single key (the lock).

Let's break down the numbered steps in this diagram:

1. Enter: A thread arrives and wants to execute a synchronized block. It enters the Entry Set, which is conceptually a queue of threads waiting for the lock to become available. These threads are in the BLOCKED state.
2. Acquire: When the current owner releases the lock, the JVM's scheduler selects a thread from the Entry Set. This thread acquires the lock and becomes the Owner. It moves from BLOCKED to RUNNABLE and begins executing the critical section.
3. Release: The owner thread can voluntarily release the lock by calling the wait() method (e.g., waiting for a condition to become true). When it does, it enters the Wait Set and is in the WAITING or TIMED_WAITING state. It is no longer competing for CPU time.
4. Re-acquire: A thread in the Wait Set is moved back to the Entry Set when another thread calls notify() or notifyAll() on the same monitor. It must then re-compete for the lock like any other thread in the Entry Set.
5. Release and Exit: Once the owner thread completes the synchronized block, it automatically releases the lock and exits. A new owner can now be selected from the Entry Set.

This model provides a robust framework for managing concurrent access. The most common path for simple synchronization is 1 -> 2 -> 5. The wait/notify mechanism (steps 3 and 4) is used for more complex thread coordination patterns, which we'll cover later.

From synchronized to Bytecode

Your interest in Java's inner workings naturally leads to the question: how does the compiler translate the synchronized keyword into something the JVM can execute? The implementation differs slightly for methods and blocks.

For a synchronized method, the compiler simply sets a flag called ACC_SYNCHRONIZED in the method's metadata within the .class file.

For a synchronized block, the compiler generates explicit bytecode instructions: monitorenter and monitorexit.

The monitorenter instruction is placed at the beginning of the block. It attempts to acquire the monitor for the specified object. The monitorexit instruction is placed at the end to release the lock.

But what if an exception is thrown inside the synchronized block? If the lock isn't released, the application could deadlock. The Java compiler handles this gracefully.

This automatic lock release is a major advantage of synchronized—it's impossible to forget to release the lock.

The Cost of Locking and JVM Optimizations

Acquiring and releasing a "fat" or "heavyweight" lock, which involves the operating system to park and unpark threads, is a relatively expensive operation. To minimize this overhead, the HotSpot JVM employs a clever optimization strategy called lock escalation. The JVM assumes that most contention is non-existent or brief and only uses heavyweight locks as a last resort.

This is managed using a few bits in every object's header, specifically in a field called the mark word. The value of the mark word changes to reflect the lock's current state.

Let's summarize the escalation path:

1. Unlocked: The initial state. The mark word stores the object's hash code.
2. Biased Lock: When a thread T1 first acquires a lock, the JVM "biases" it towards T1 by storing T1's ID in the mark word. Subsequent lock acquisitions by T1 are nearly free—just a simple check of the thread ID. This optimizes for the common case where a lock is used by only one thread.
3. Thin Lock: If another thread, T2, tries to acquire the biased lock, the bias is revoked. The lock escalates to a "thin lock". The JVM uses an atomic Compare-And-Swap (CAS) operation to point the mark word to a lock record on the thread's stack. This is still very fast as it doesn't involve the OS. If T2 fails the CAS (because T1 still holds the lock), it will "spin" (perform a tight loop) for a short time, hoping the lock is released quickly.
4. Fat Lock: If contention continues and spinning fails, the lock finally inflates to a "fat lock". A full-fledged monitor object is created in the heap, and any threads that fail to acquire the lock are parked by the OS until they are notified, incurring the full cost of a context switch.

This escalation means that in the common low-contention scenarios, synchronized is highly efficient.

Reentrancy: Locking Without Deadlocking Yourself

What happens if a synchronized method calls another synchronized method on the same object?

public class ReentrantExample {
    public synchronized void outer() {
        System.out.println("In outer");
        inner(); // Calls another synchronized method
    }

    public synchronized void inner() {
        System.out.println("In inner");
    }
}

If the lock wasn't reentrant, the thread holding the lock for outer() would block forever when trying to acquire the lock for inner(), because it's already holding it! This would be a self-deadlock.

Fortunately, Java's intrinsic locks are reentrant. A thread that already owns a monitor can re-acquire it without blocking. The monitor simply keeps a count of how many times the thread has entered a synchronized block protected by it. The lock is only truly released when the count returns to zero.

Conclusion

In this lesson, we moved from the "what" to the "how" of Java's synchronized keyword. You now have a much deeper model of how the JVM provides thread safety, connecting a simple language feature to complex underlying mechanics.

Key Takeaways:

• Every Java object has an intrinsic lock, or monitor, which is the foundation of the synchronized mechanism.
• The monitor being locked depends on the context: this for instance methods, the .class object for static methods, and an explicit object for synchronized blocks.
• The synchronized keyword is translated by the compiler into either the ACC_SYNCHRONIZED method flag or the monitorenter/monitorexit bytecode instructions. The compiler ensures locks are released even if exceptions occur.
• The JVM optimizes locking via lock escalation, starting with cheap biased and thin locks (using CAS) and only inflating to expensive fat (heavyweight) locks under high contention.
• The state of the lock is stored in the mark word of the object's header.
• Intrinsic locks are reentrant, allowing a thread to acquire a lock it already holds, which is essential for object-oriented designs.

In the previous lesson, we introduced synchronized as a robust way to manage concurrent access. Now you understand the sophisticated machinery that makes it both safe and performant. In our next lesson, we will explore explicit locks, specifically ReentrantLock, and compare their features and trade-offs against the intrinsic locks you've just mastered.