从源码看 JVM wait/notify:ObjectMonitor 三个队列

写篇文章搞清楚一件事：为什么 wait()/notify()/notifyAll() 必须写在 synchronized 里，条件变量的正确用法到底是什么。

先跑个例子

public class BlockingQueue<E> {
    private final Object[] items;
    private int count = 0;
    private int putIndex = 0;
    private int takeIndex = 0;

    public BlockingQueue(int capacity) {
        items = new Object[capacity];
    }

    public synchronized void put(E e) throws InterruptedException {
        while (count == items.length) {
            wait();  // 队列满了，等消费者取走
        }
        items[putIndex] = e;
        putIndex = (putIndex + 1) % items.length;
        count++;
        notify();  // 叫醒一个等待的消费者
    }

    public synchronized E take() throws InterruptedException {
        while (count == 0) {
            wait();  // 队列空了，等生产者放入
        }
        E item = (E) items[takeIndex];
        items[takeIndex] = null;
        takeIndex = (takeIndex + 1) % items.length;
        count--;
        notify();  // 叫醒一个等待的生产者
        return item;
    }
}

线程 A 执行 put() 等锁，线程 B 执行 take() 等锁——两个线程交替等待和唤醒。wait() 和 notify() 到底在内核里干了什么？

为什么必须在 synchronized 里

wait()/notify()/notifyAll() 是 Object 的方法，但 Java 语言规范明确要求调用时必须在持有对象锁的状态下，否则抛 IllegalMonitorStateException。

Object obj = new Object();
obj.wait();  // IllegalMonitorStateException: current thread not owner

这不是随意设计的。wait() 的语义是"持有锁的情况下，主动释放锁并等待"，notify() 的语义是"持有锁的情况下，唤醒一个正在这个对象上等待的线程"。两个操作都依赖于对同一个对象 monitor 的独占访问，所以必须先拿锁。

ObjectMonitor 里的 _WaitSet

synchronized 底层是 ObjectMonitor（JDK 21 源码：src/hotspot/share/runtime/objectMonitor.hpp）。ObjectMonitor 有三个队列：

// OpenJDK 21 src/hotspot/share/runtime/objectMonitor.hpp
class ObjectMonitor : public CHeapObj<mtObjectMonitor> {
    void* volatile _owner;              // 当前持有锁的线程
    volatile intx _recursions;          // 重入次数
    ObjectWaiter* volatile _EntryList; // 等锁的线程（可竞争）
    ObjectWaiter* volatile _cxq;        // 刚到等锁的线程（FIFO）
    ObjectWaiter* volatile _WaitSet;    // 调用 wait() 后进入等待的线程
};

三个队列用途完全不同：

• _cxq / _EntryList：等锁的线程——锁释放后从这里唤醒
• _WaitSet：调用了 wait() 主动进入等待的线程——只能被 notify()/notifyAll() 唤醒

调用 wait() 时，线程从同步队列移动到 _WaitSet，然后释放锁、进入睡眠。调用 notify() 时，从 _WaitSet 里挑一个线程唤醒，放回竞争队列，等锁释放后重新竞争。

wait() 的完整流程

来看 JDK 21 ObjectMonitor 的真实实现：

// OpenJDK 21 src/hotspot/share/runtime/objectMonitor.cpp
void ObjectMonitor::wait(jlong millis, bool interruptible, TRAPS) {
    CHECK_OWNER();  // 必须是锁持有者，否则抛 IMSE

    // 1. 创建等待节点，加入 _WaitSet 链表（尾插，环形双向链表）
    ObjectWaiter node(current);
    node.TState = ObjectWaiter::TS_WAIT;
    Thread::SpinAcquire(&_WaitSetLock, "WaitSet - add");
    AddWaiter(&node);          // 插入 _WaitSet 尾部
    Thread::SpinRelease(&_WaitSetLock);

    _waiters++;                // 等待计数 +1

    // 2. 记录重入次数，然后清零
    intx save = _recursions;
    _recursions = 0;

    // 3. 退出 monitor（释放锁）
    exit(current);             // 关键：这一步释放 _owner

    // 4. park() 挂起，直到被唤醒或超时
    if (node._notified == 0) {
        if (millis <= 0) {
            current->_ParkEvent->park();       // 无限等待
        } else {
            current->_ParkEvent->park(millis); // 带超时
        }
    }
}

注意：第 3 步 exit() 是关键——wait() 之前线程已经持锁了，exit() 才真正把锁释放掉，让其他线程可以进来。

_ParkEvent->park() 底层是 Linux 的 futex：

Java: obj.wait()
  → JVM: ObjectMonitor::wait()
    → ParkEvent::park()
      → pthread_cond_wait(&_cond, &_mutex)
        → Linux: futex(WAIT, uaddr, val, timeout)
          → 当前线程挂起，不消耗 CPU

notify() 的完整流程

同样来看 JDK 21 的真实实现：

// OpenJDK 21 src/hotspot/share/runtime/objectMonitor.cpp
void ObjectMonitor::INotify(JavaThread* current) {
    // 1. 从 _WaitSet 头部取出一个线程（FIFO）
    ObjectWaiter* iterator = DequeueWaiter();

    // 2. 设置状态，移入竞争队列
    iterator->TState = ObjectWaiter::TS_ENTER;
    iterator->_notified = 1;
    iterator->_notifier_tid = JFR_THREAD_ID(current);

    // 3. 关键：放到哪个队列？
    //    _EntryList 空 → 直接进 _EntryList
    //    _EntryList 非空 → 插入 _cxq 队列头部
    ObjectWaiter* list = _EntryList;
    if (list == nullptr) {
        _EntryList = iterator;   // 直接进入可竞争队列
    } else {
        iterator->TState = ObjectWaiter::TS_CXQ;
        // 头插法进入 _cxq
        for (;;) {
            ObjectWaiter* front = _cxq;
            iterator->_next = front;
            if (Atomic::cmpxchg(&_cxq, front, iterator) == front) break;
        }
    }
}

一个重要细节：如果 _EntryList 里已经有等锁的线程，notify() 唤醒的线程会插到 _cxq 的头部，而不是尾部。这意味着新唤醒的线程反而排在老等待线程前面——这叫 expedited handoff，减少等待延迟。

// OpenJDK 21 注释明确说明
// For now we use (b): push it onto the front of the _cxq

_cxq 和 _EntryList 是什么关系

来看 exit() 的逻辑（锁释放路径）：

// OpenJDK 21 src/hotspot/share/runtime/objectMonitor.cpp
void ObjectMonitor::exit(bool impl, JavaThread* current) {
    // ... 重入计数处理 ...

    // _cxq 和 _EntryList 的合并逻辑
    ObjectWaiter* w = _EntryList;
    if (w != nullptr) {
        // _EntryList 非空，直接从 _EntryList 唤醒一个
        DequeueSpecificWaiter(w);
    } else {
        // _EntryList 空，从 _cxq 迁移到 _EntryList，再唤醒
        w = _cxq;
        if (w != nullptr) {
            // 将整个 _cxq 逆序迁移到 _EntryList
            _EntryList = w;
            // ... 逆序处理代码 ...
        }
    }
    // 唤醒线程
    if (w != nullptr) {
        // unpark 线程，使其从 park() 返回
    }
}

所以三个队列的关系：

_WaitSet  ← wait() 入队（尾）
  ↓
notify() / notifyAll() 取出
  ↓
_EntryList 非空 → 直接追加到 _EntryList 尾部
_EntryList 为空 → 插入 _cxq 头部（插队）
  ↓
锁释放时，Exit() 先看 _EntryList，不为空则直接唤醒
_EntryList 为空，则把整个 _cxq 迁移过来再唤醒

一个线程从 wait() 到真正被 park() 唤醒重新竞争锁，经历：_WaitSet → _cxq/EntryList → unpark → 竞争锁 → 拿到锁继续执行。

为什么必须用 while 而不是 if

// 错误写法
synchronized(obj) {
    if (count == 0) {    // ❌ 用 if
        obj.wait();
    }
    // 继续执行...
}

// 正确写法
synchronized(obj) {
    while (count == 0) {  // ✅ 用 while
        obj.wait();
    }
    // 继续执行...
}

while 是防止虚假唤醒（spurious wakeup）的标准做法。

Linux 的 pthread_cond_wait 本身不保证每次唤醒都是由 signal/broadcast 触发的。POSIX 标准明确说，虚假唤醒是允许的——线程可能在没有任何条件变化的情况下被唤醒。JDK 层面对此也无能为力，wait() 只能保证"最终会被唤醒"，不保证"只有 notify 才唤醒"。

所以必须每次唤醒后重新检查条件——while 循环在虚假唤醒后会再次检查条件，不满足就继续 wait()。

/proc 验证 wait() 的挂起状态

在 Linux 上，可以通过 /proc 验证线程的等待状态：

# 假设一个线程调用了 obj.wait()
$ cat /proc/<pid>/task/<tid>/status
Name:   Thread-B
State:  S (sleeping)        ← 内核状态：睡眠
wchan:  futex_wait_queue    ← 内核等待的函数
SWap:   0
$ cat /proc/<pid>/task/<tid>/wchan
futex_wait_queue

wchan 显示 futex_wait_queue，证明线程确实被 futex 挂起，不消耗 CPU。State: S 是 Linux 进程状态中的睡眠状态（可中断睡眠）。

再看正常等锁的线程（synchronized 竞争失败）：

$ cat /proc/<pid>/task/<tid>/status
Name:   Thread-C
State:  S (sleeping)
wchan:  futex_wait_queue    ← 也是 futex，但不是 wait()
                           ← 是在 EntryList/cxq 中等锁

两类线程都显示 S 状态，但 wchan 有细微差别——wait() 的线程最终进入 ObjectMonitor::wait() 里的 park() 调用。

ReentrantLock + Condition 的做法

JDK 5 之后引入的 java.util.concurrent.locks.ReentrantLock 解决了这个问题：

private final Lock lock = new ReentrantLock();
private final Condition notFull  = lock.newCondition();
private final Condition notEmpty = lock.newCondition();

public void put(E e) throws InterruptedException {
    lock.lock();
    try {
        while (count == items.length) {
            notFull.await();   // 只等 notFull 这个条件
        }
        items[putIndex] = e;
        putIndex = (putIndex + 1) % items.length;
        count++;
        notEmpty.signal();    // 只叫醒等 notEmpty 的线程
    } finally {
        lock.unlock();
    }
}

public E take() throws InterruptedException {
    lock.lock();
    try {
        while (count == 0) {
            notEmpty.await();  // 只等 notEmpty 这个条件
        }
        E item = (E) items[takeIndex];
        items[takeIndex] = null;
        takeIndex = (takeIndex + 1) % items.length;
        count--;
        notFull.signal();      // 只叫醒等 notFull 的线程
        return item;
    } finally {
        lock.unlock();
    }
}

每个 Condition 背后是一个独立的等待队列，不再和对象锁绑定。await() 把线程放入条件队列并释放锁，signal() 从条件队列里叫线程——不需要叫醒整个对象上的所有线程。

底层实现：ReentrantLock 内部用 AbstractQueuedSynchronizer（AQS）实现，每个 Condition 对应 AQS 里的一个 Node 链表。await() 就是把当前节点从 AQS 的同步队列移到条件队列，signal() 再从条件队列移回同步队列。LockSupport.park()/unpark() 最终走的还是 Linux futex。

所以为什么必须写在 synchronized 里

总结一下，wait()/notify()/notifyAll() 必须写在 synchronized 里的原因：

1. 依赖独占访问：_WaitSet 是 ObjectMonitor 的一部分，读写它需要持有对象锁
2. wait() 语义：必须先持锁，wait() 才能安全地"持锁→释放锁→挂起"——不能释放一把没持有的锁
3. notify() 语义：必须先持锁，才能叫醒"在同一个对象上等待的线程"——不能叫醒不属于自己 monitor 的线程
4. 条件变量的本质：wait()/notify() 是条件变量（condition variable）的实现，条件变量必须和一个互斥锁绑定，这是它的语义要求

ReentrantLock + Condition 换汤不换药——Condition.await() 内部也是先释放锁再 park，只是把"哪个条件"这个信息显式化了，避免 notifyAll() 的额外开销。两种写法走到最底层，都是 futex。