Understanding Java Object Locks and Their Implementation in the Android Runtime (ART)

During Java programming, thread synchronization is a common challenge. While many solutions exist (synchronized, JUC, atomic operations, volatile, condition variables, etc.), synchronized is the most convenient and widely used mechanism for protecting critical sections.

This article explains the concept of object locks, detailing the usage of synchronized on instance methods, static methods, and synchronized blocks, as well as the underlying JVM implementation.

Instance method synchronization : When synchronized decorates an instance method, only one thread can execute that method on the same object at a time. Different object instances are not mutually exclusive.

Static method synchronization : When applied to a static method, the lock is associated with the Class object, ensuring exclusive access across all threads for that class.

Synchronized block : A block can be synchronized on any object reference. The block acquires the monitor of the specified object, allowing finer‑grained protection than method‑level synchronization.

Each synchronized region generates a monitor-enter instruction at the start and a monitor-exit instruction at the end. The monitor is tied to an object’s lock word, which can be in one of several states: unlocked/thin lock, fat lock, hash state, or forwarding address (used during concurrent copying GC).

The article then shifts to Android-specific details, describing the memory layout of an object in ART: the object header (containing kclass_ and monitor_ ), instance fields, and alignment padding.

The monitor_ field is defined in art/runtime/mirror/object.h and is manipulated via functions such as SetLockWord , CasLockWord , and GetLockWord . The LockWord structure encodes lock state, owner thread ID, re‑entrancy count, hash code, and other flags within a 32‑bit value.

Lock state transitions are explained:

Unlocked/Thin lock – default state; thin lock stores owner thread ID and re‑entrancy count.

Fat lock – created when contention exceeds thin‑lock limits, allocating a separate Monitor object.

Hash state – stores the object's hash code.

Forwarding address – used during GC copying.

The article provides a step‑by‑step analysis of the following JVM runtime functions:

Object.wait() : validates that the calling thread holds the object monitor, inflates a thin lock to a fat lock if necessary, and then puts the thread into the waiting set.

Object.notify() : wakes a single waiting thread (or all if notifyAll is used) after checking lock state.

monitor-enter : acquires the monitor, handling thin‑lock fast‑path, lock inflation, and spin‑wait thresholds.

monitor-exit : releases the monitor, handling thin‑lock decrement, unlocking fat locks, and signaling waiting threads.

Key internal components such as FakeLock , kExtraSpinIters , MonitorPool , and the Mutex used for the actual OS‑level futex wait are also described.

Finally, the article summarizes that it has covered the usage patterns of object locks, the memory structure of Java objects in Android, the layout of the lock word, and the detailed JVM implementation of synchronized , Object.wait() , and Object.notify() .