Unlocking Java: How synchronized Locks Evolve from MarkWord to Heavyweight

Why discuss this?

After reviewing AQS, we revisit several high‑frequency questions about Java object memory layout, the underlying implementation of synchronized and ReentrantLock, why AQS relies on CAS + volatile, the four lock states and upgrade process, the memory size of a new Object, and the efficiency of spin locks, biased locks, and heavyweight locks.

What does an object's memory layout look like?

Describe the low‑level implementation and re‑entrancy principle of synchronized and ReentrantLock.

Why does AQS use CAS + volatile?

Explain the four lock states and the lock‑upgrade process.

How many bytes does Object o = new Object() occupy?

Is a spin lock always more efficient than a heavyweight lock?

Does enabling biased locking always improve performance?

When is a heavyweight lock actually faster than a lightweight lock?

What happens when a lock is acquired?

Many common APIs use locks implicitly, such as System.out.println and StringBuffer. The following snippet shows that println is synchronized:

public void println(String x) {
    synchronized (this) {
        print(x);
        newLine();
    }
}

When an object is created, its memory consists of four parts:

MarkWord – stores lock information and other object metadata (e.g., GC flags, age).

Klass pointer – points to the class metadata.

Instance data – holds the fields of the object.

Padding – aligns the object size to an 8‑byte boundary on 64‑bit JVMs.

Using the JOL (Java Object Layout) library, we can print the layout of a newly created object:

public class JOLDemo {
    private static Object o;
    public static void main(String[] args) {
        o = new Object();
        synchronized (o) {
            System.out.println(ClassLayout.parseInstance(o).toPrintable());
        }
    }
}

The output shows a 12‑byte object header (MarkWord + Klass pointer) and a total size of 16 bytes after padding.

Lock upgrade process

We verify lock upgrades by running two versions of the same code: one sleeps for 5 seconds before creating the object, the other does not. The memory layouts differ, demonstrating that biased locking is disabled for the first 4 seconds in JDK 8, causing the lock to start as lightweight.

Why does lock upgrade exist? Early JDK 1.2 used only heavyweight locks, which required costly OS kernel calls. Modern JVMs introduce biased, lightweight, and heavyweight locks to reduce contention and avoid unnecessary kernel transitions.

Why biased locking?

Most synchronized operations (e.g., System.out.println, StringBuffer) are uncontended. Biased locking records the owning thread in the MarkWord, allowing subsequent entries without CAS or OS involvement. If another thread competes, the bias is revoked and the lock upgrades to lightweight.

When does lightweight lock become heavyweight?

If contention is high (e.g., thousands of threads) or a CAS spin fails after ~10 attempts, the JVM escalates to a heavyweight lock, delegating ownership to the OS scheduler.

What makes a heavyweight lock “heavy”?

Heavyweight locks involve OS‑level mutexes, thread queueing, and context switches, which are far more expensive than JVM‑managed lightweight mechanisms.

Synchronized implementation details

The bytecode for a simple synchronized block contains monitorenter and monitorexit instructions:

public class RnEnterLockDemo {
    public void method() {
        synchronized (this) {
            System.out.println("start");
        }
    }
}

monitorenter attempts to acquire the object's monitor: if the entry count is zero, the thread becomes the owner; if the thread already owns it, the count increments; otherwise the thread blocks.

Each object is associated with a monitor. A monitor is locked if and only if it has an owner. The thread that executes monitorenter attempts to gain ownership of the monitor associated with objectref ...

monitorexit releases the monitor: the owning thread decrements the entry count, and if it reaches zero, the monitor becomes available for other threads.

The thread that executes monitorexit must be the owner of the monitor associated with the instance referenced by objectref ...

Thus, synchronized relies on a monitor object that tracks a lock counter and a pointer to the owning thread. When the counter drops to zero, the lock is released.

Conclusion

Historically, synchronized was a heavyweight lock, but JVM optimizations introduced biased and lightweight locks to avoid costly OS interactions. Modern Java developers can use synchronized without worrying about its internal state; the JVM automatically selects the most efficient lock type based on contention.