夜雨聆风写篇文章搞清楚一件事：为什么 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 里的原因：
依赖独占访问： _WaitSet是ObjectMonitor的一部分，读写它需要持有对象锁wait() 语义：必须先持锁， wait()才能安全地"持锁→释放锁→挂起"——不能释放一把没持有的锁notify() 语义：必须先持锁，才能叫醒"在同一个对象上等待的线程"——不能叫醒不属于自己 monitor 的线程 条件变量的本质： wait()/notify()是条件变量（condition variable）的实现，条件变量必须和一个互斥锁绑定，这是它的语义要求
ReentrantLock + Condition 换汤不换药——Condition.await() 内部也是先释放锁再 park，只是把"哪个条件"这个信息显式化了，避免 notifyAll() 的额外开销。两种写法走到最底层，都是 futex。