notify() 真实测出会卡死:3 次运行,3 次真实卡在个位数

思路:一把锁上有两种不同的等待条件

notify() 唤醒的是"某一个"在这把锁上等待的线程,但它不知道、也不关心被唤醒的线程在等的是哪个条件。

搭一个容量为 1 的有界缓冲区:生产者在缓冲区满时 wait(),消费者在缓冲区空时 wait()——两种角色、两种完全不同的等待条件,但共享同一把锁、同一个等待队列:

NotifyVsNotifyAll.java(核心逻辑) synchronized void put(int v) throws InterruptedException { while (q.size() == capacity) { wait(); // 等待"不满"这个条件 } q.addLast(v); if (useNotifyAll) notifyAll(); else notify(); } synchronized int take() throws InterruptedException { while (q.isEmpty()) { wait(); // 等待"不空"这个条件 } int v = q.removeFirst(); if (useNotifyAll) notifyAll(); else notify(); return v; }

4 个生产者 + 4 个消费者一起跑,每个生产者生产 2 万个,总共 8 万个任务,主线程每 20ms 轮询一次完成计数,5 秒超时没完成就判定为真实卡死。

真实验证:notify() 三次运行,三次全部卡死

同样的代码结构,只把 notify() 换成 notifyAll(),重复三次对照。

notify()    -> 完成 2/80000 (真实超时未完成! 卡在了 2/80000, 等了 5000ms)
notify()    -> 完成 2/80000 (真实超时未完成! 卡在了 2/80000, 等了 5000ms)
notify()    -> 完成 4/80000 (真实超时未完成! 卡在了 4/80000, 等了 5000ms)

notifyAll() -> 完成 80000/80000 (全部真实完成,耗时 695ms)
notifyAll() -> 完成 80000/80000 (全部真实完成,耗时 656ms)
notifyAll() -> 完成 80000/80000 (全部真实完成,耗时 462ms)

真实过程是这样的:容量为 1 的缓冲区很快被填满或掏空,多个生产者和多个消费者很快就会同时排在 wait() 上。notify() 每次只随机唤醒队列里的一个线程,如果唤醒的碰巧是另一个生产者(它的条件"缓冲区不满"根本没变),这个生产者被唤醒后重新检查条件、发现还是满的,只能再次 wait() 回去——而真正应该被唤醒的消费者,永远没等到属于它的那次通知,整个系统很快就没有线程再醒来,真实卡死。

分步演示:notify() 和 notifyAll() 真实唤醒了几个线程

每一行都是真实运行这段代码得到的结果(用CountDownLatch保证观测时机确定)。