Understanding Java Object.wait() and notify() Implementation in the HotSpot JVM

The article examines why the Object class is fundamental in Java, focusing on the implementation of its wait and notify methods that enable multithreaded coordination.

Execution result example:

thread A is waiting to get lock thread A get lock thread B is waiting to get lock thread A do wait method thread B get lock thread B do notify method wait end

Premise: Both wait and notify are invoked on the same lock object. When thread A calls wait , it is suspended; when thread B calls notify , it wakes one suspended thread.

The lock object, thread A, and thread B interact through a waiting queue: the lock maintains a list, thread A is added to the list when it calls wait , and thread B removes it when it calls notify . The real HotSpot implementation is more complex than this simple model.

Key questions addressed:

Why must a synchronized lock be acquired before entering wait / notify ?

How can thread B acquire the lock again after thread A has called wait and released it?

Why synchronized ? The compiled bytecode for a synchronized block contains the monitorenter and monitorexit instructions, which acquire and release the object's monitor. The JVM specification requires that a thread own the object's monitor before invoking wait , which is why the call must be inside a synchronized block.

Code execution analysis:

On a multicore CPU, threads A and B may simultaneously execute monitorenter . Only one succeeds; assume thread A acquires the monitor.

Thread B fails to acquire the monitor and enters the waiting (entry) queue.

When thread A reaches wait , it places itself in the wait set and releases the monitor, allowing thread B to acquire it.

Thread B, now holding the monitor, executes notify . The JVM selects an arbitrary thread from the wait set (effectively the first ObjectWaiter ) and moves it to the entry list.

After notify returns, the monitor is still held by thread B until it executes monitorexit . Only then can the awakened thread compete for the monitor again.

What is a monitor? In HotSpot, a monitor is implemented by ObjectMonitor . Each thread has free and used lists of ObjectMonitor objects; if the free list is empty, a global list is consulted.

The ObjectMonitor contains two queues: _WaitSet (threads in wait state) and _EntryList (threads blocked on the lock), and an _owner reference to the thread that currently holds the monitor.

ObjectWaiter objects form a doubly‑linked list, storing the thread reference and its state. Every thread waiting for a lock is represented by an ObjectWaiter .

wait method implementation

lock.wait()

ultimately calls

ObjectMonitor::wait(jlong millis, bool interruptable, TRAPS)

which:

Wraps the current thread into an ObjectWaiter node.

Adds the node to _WaitSet via ObjectMonitor::AddWaiter .

Releases the monitor using ObjectMonitor::exit , allowing other threads to acquire it.

Invokes the native park operation to suspend the thread.

notify method implementation

lock.notify()

calls

ObjectMonitor::notify(TRAPS)

which:

If _WaitSet is empty, returns immediately.

Dequeues the first ObjectWaiter from _WaitSet via ObjectMonitor::DequeueWaiter .

Moves the dequeued node to _EntryList or performs a CAS spin using Atomic::cmpxchg_ptr (implementation details omitted).

notifyAll method implementation

lock.notifyAll()

iterates over all nodes in

_WaitSet

, moving each to

_EntryList

(or using the same CAS strategy). Neither

notify

nor

notifyAll

releases the monitor; the monitor is released only when the owning thread executes

monitorexit

, after which threads in the entry list can compete for the lock.

Overall, the article provides a detailed walkthrough of how HotSpot 1.7 implements Java's intrinsic monitor mechanisms, clarifying the relationship between synchronized blocks, wait sets, entry lists, and the underlying native operations that enable thread coordination.