Java Object类notify方法如何唤醒单个等待线程

先说说一个常见的误解：很多开发者以为 notify() 能“精确唤醒某个指定的线程”，其实不然。它只是从当前对象监视器的等待队列里，随机挑一个正在 wait() 的线程唤醒——注意，唤醒的是“单个”没错，但具体是哪一个，你说了不算，JVM 说了算。

换句话说，notify() 保证“只唤醒一个”，但绝不保证“唤醒你想要的那个”。这个“单个”是存在性意义上的——不是全部，但不是可控、可选择的某一个。

notify() 的唤醒行为本质

notify() 的设计初衷是打破等待状态，避免虚假唤醒或资源竞争，但它压根就没打算提供线程选择能力：

• JVM 从该对象的等待队列中选取一个处于 WAITING 状态的线程，具体选哪个由 JVM 内部决定，完全不可预测；
• 被唤醒的线程并不会立刻执行，它得重新竞争该对象的监视器锁，只有抢到锁才能继续往下走；
• 如果等待队列本来就是空的，那 notify() 就什么都不做，不会有异常，也不会有任何提示。

为什么不能指定唤醒某个线程

这其实是 Java 内存模型和监视器机制的设计限制，不是功能遗漏：

• wait()/notify() 基于对象级别的监视器，它根本不记录线程身份或优先级；
• Java 没有提供任何 API 让你传入线程引用或条件标识来定向唤醒；
• 强行把线程和唤醒逻辑绑定在一起，很容易引发死锁或竞态，这违背了 monitor 的简洁抽象原则。

想精准唤醒特定线程？用替代方案

如果业务确实需要“唤醒某个特定的等待者”，那就别在 notify() 上死磕了，换更可控的协作机制：

• 使用 java.util.concurrent 工具类：比如 Condition 配合 ReentrantLock，可以为不同的等待条件创建多个 Condition 实例，实现分组唤醒；
• 用标志位 + notifyAll() + 循环检查：每个等待线程按自己关心的条件等待，唤醒后重新判断是否轮到自己处理，未命中就继续 wait()；
• 使用阻塞队列或信号量：比如 LinkedBlockingQueue 或 Semaphore，把“唤醒请求”建模成数据或许可，让目标线程主动去消费。

典型误用提醒

下面这种写法看起来很“合理”，其实不可靠：

synchronized (obj) {
    obj.notify(); // 无法确保唤醒的是你期望的那个线程
}

即便当时只有一条线程在等，也不建议依赖这个行为做逻辑分支——因为多线程环境下，很可能在 notify() 之后、被唤醒线程运行之前，又有新线程进入了 wait()，导致唤醒错乱。