How Does Java’s synchronized Work? A Deep Dive into Lock Mechanisms

Interview Simulation

The scenario reproduces a Baidu second‑round interview question about synchronized, using it as a case study to explore its internal mechanics.

Interview Scene

The interviewer asks whether a static method and an instance method both marked with synchronized are thread‑safe. The candidate explains that a static synchronized method locks the Class object, while an instance synchronized method locks the specific object instance.

The interviewer then probes the low‑level implementation of synchronized. The candidate describes that the JVM inserts monitorenter at the beginning of a synchronized block and monitorexit at the end.

When a synchronized block is compiled, each object’s header contains a Mark Word that stores runtime metadata such as hashcode, GC age, lock state, and the owning thread.

Lock acquisition depends on the current lock state:

Biased lock : the Mark Word holds the thread ID of the thread that first acquired the lock.

Lightweight lock : a lock record (Lock‑Record) is created on the thread’s stack; the object’s Mark Word is swapped with a pointer to this lock record using CAS.

Heavyweight lock : when contention occurs, the lightweight lock inflates to a monitor object (heavyweight lock) that contains a wait set, entry list, and owner.

If CAS succeeds, the thread owns the lock; if it fails because another thread already holds a lightweight lock, the lock inflates to a heavyweight monitor. Re‑entrancy is handled by adding another lock record and incrementing a counter.

Monitor = WaitSet + EntryList (blocked threads) + Owner (thread holding the lock)

During lock release, the JVM uses CAS to restore the original Mark Word. If the lock had been inflated to a heavyweight monitor, the monitor’s owner is cleared and blocked threads in the entry list are awakened.

Lock Escalation Process

The full escalation sequence is:

No lock

Biased lock

Lightweight lock

Lock spin

Heavyweight lock

Biased lock checks whether the Mark Word already contains the current thread ID. If not, CAS attempts to replace the Mark Word with the thread ID; failure triggers escalation to a lightweight lock.

Lightweight locking creates a lock record on the thread stack, stores the object’s Mark Word there, and attempts CAS to point the object’s Mark Word to the lock record. On CAS failure, two cases arise:

Another thread holds a lightweight lock – the lock inflates to a heavyweight monitor.

The same thread re‑enters the synchronized block – a new lock record is added for re‑entrancy counting.

When a heavyweight lock is needed, the JVM allocates a monitor object, links the object’s header to the monitor, and places competing threads into the monitor’s blocked queue.

Upon exiting the synchronized block, if the lock record is null (no re‑entrancy), the lock record is cleared; otherwise, the lock record’s counter is decremented. If the lock had been inflated, the monitor’s owner is set to null and waiting threads are notified.

Key Takeaways

The article provides a comprehensive walkthrough of how synchronized works at the JVM level, including bytecode insertion, object header changes, lock states, CAS operations, lock inflation, and unlock procedures.