登录
首页 >  文章 >  java教程

Java线程唤醒:notify与notifyAll怎么选

时间:2026-02-20 12:01:07 377浏览 收藏

Java中线程唤醒的正确选择关乎程序稳定与逻辑正确:notify虽轻量却随机唤醒、无法定向控制,仅适用于单一线程等待或角色完全等价的极简场景,一旦用于生产者-消费者等多角色协作环境,极易引发隐性死锁或逻辑错乱;而notifyAll虽唤醒所有等待线程,但实际开销远低于想象,配合while循环条件重检,是兼顾安全性、可维护性与实际性能的可靠首选——别被过时的性能顾虑误导,真正的代价往往是调试数小时却找不到的“程序不推进”bug。

在Java中notify和notifyAll如何选择_Java线程唤醒解析

notify 会随机唤醒一个等待线程,但不保证是你要的那个

当多个线程在同一个 Object 上调用 wait()(比如共享队列、生产者消费者共用同一把锁),notify() 只唤醒其中一个——JVM 自由选择,无法控制。如果你的业务逻辑依赖“唤醒特定类型线程”(例如只该唤醒消费者,结果唤醒了另一个生产者),就会卡死或逻辑错乱。

常见错误现象:IllegalMonitorStateException 不常出现,但更隐蔽的是“程序看似运行却不再推进”,比如生产者发了信号,消费者没醒,而另一个本不该响应的线程醒了又立刻 wait() 回去。

  • 仅适用于:明确知道只有一个线程在等,或多个线程行为完全等价(如线程池中任意空闲 worker 都能处理任务)
  • 不能用于:有不同角色/状态的等待者(如生产者 vs 消费者、读线程 vs 写线程)
  • 注意:即使你写了 if (condition) wait();,被唤醒后也必须用 while 重检条件,因为存在虚假唤醒

notifyAll 是安全兜底,但不是性能杀手

很多人怕 notifyAll() 效率低,觉得“唤醒所有线程再竞争锁太浪费”。实际上,在绝大多数实际场景中,等待线程数很少(notifyAll() 做了优化(如 Linux 下使用 futex,不会真让全部线程走完整调度流程)。真正影响性能的是锁竞争本身,而不是唤醒动作。

使用场景:只要等待者角色不同、条件复杂、或你不确定有多少线程在等,就该无脑选 notifyAll()

  • 必须用 notifyAll() 的典型例子:读写锁实现、有界阻塞队列(ArrayBlockingQueue 内部就用它)、状态机驱动的协作线程
  • 参数上无差异——它不需要传任何参数,就是对当前对象监视器上的所有等待线程广播
  • 副作用:所有被唤醒线程会重新进入锁竞争队列,但只有拿到锁的那个能继续执行;其余再次阻塞(不是立刻回到 wait set)

别忘了 while + wait 的固定写法

wait() 前的条件检查和唤醒后的重检,不是可选项。用 if 就可能跳过条件变化,导致线程在不满足条件时继续执行。

synchronized (lock) {
    while (!ready) {  // 必须用 while,不是 if
        lock.wait();
    }
    // 处理逻辑
}

这个模式和 notify()/notifyAll() 选择强相关:哪怕你用了 notifyAll(),如果里面是 if,仍可能漏判;反过来,就算你误用了 notify()while 至少能防止直接出错。

  • 虚假唤醒(spurious wakeup)是 JVM 规范允许的,不依赖操作系统信号也能发生
  • 条件变量应始终是 volatile 或被 synchronized 保护,避免可见性问题
  • 不要在循环里做耗时操作,否则会拖慢整个等待队列的响应

现代 Java 更推荐 Condition + Lock 替代 wait/notify

原生 wait/notify 绑死在 Object 上,无法区分不同等待条件(比如“队列非空”和“队列未满”只能共用一个锁对象)。而 ReentrantLock.newCondition() 允许为每种逻辑建独立 Condition,配合 signal()/signalAll() 精准唤醒。

示例:ArrayBlockingQueue 内部就用了两个 Condition:一个叫 notEmpty,一个叫 notFull,生产者只 signal(notEmpty),消费者只 signal(notFull),彻底避免误唤醒。

  • signal()notify()signalAll()notifyAll(),但语义更清晰、可读性更强
  • 必须搭配 Lock 使用,不能和 synchronized 混用
  • 忘记 unlock() 会导致死锁,比 synchronized 更容易出错——所以建议用 try-finally 或 try-with-resources(配合 Lock 的封装工具类)
真正难的不是选 notify 还是 notifyAll,而是想清楚“哪些线程该被唤醒”以及“它们醒来后靠什么判断自己是否该干活”。条件表达式写错、漏掉 while、混用锁机制,比唤醒方式本身更容易引发线上问题。

文中关于的知识介绍,希望对你的学习有所帮助!若是受益匪浅,那就动动鼠标收藏这篇《Java线程唤醒:notify与notifyAll怎么选》文章吧,也可关注golang学习网公众号了解相关技术文章。

资料下载
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>