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

许多Java开发者常常误以为 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() 状态，从而导致唤醒结果错乱。