notify只唤醒一个等待线程，notifyAll唤醒所有等待线程；二者均不释放锁，仅改变线程在Monitor队列中的位置，适用场景分别为精确控制与安全兜底。
notify 和 notifyAll 的本质区别在于：唤醒等待线程的**数量与确定性不同**，背后对应的是线程调度策略和并发安全逻辑的根本差异。
唤醒目标不同：一个 vs 全部
notify 只从对象的等待队列（WaitSet）中随机挑选一个处于 wait 状态的线程，将其移入锁竞争队列（EntryList），该线程需重新抢锁后才能继续执行。
notifyAll 则把等待队列中所有 wait 线程全部移入锁竞争队列，它们同时参与锁争夺，谁先抢到谁先执行。
关键点：被唤醒 ≠ 立即运行；notify 唤醒后仍要等锁释放，notifyAll 唤醒后也要抢锁——两者都不释放当前持有的锁。
立即学习“Java免费学习笔记（深入）”；
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
适用场景不同：精确控制 vs 安全兜底
notify 更适合条件唯一、线程角色明确的场景。例如单生产者-单消费者模型中，每次只产生一个新元素，只需唤醒一个消费者即可。
notifyAll 更适用于多条件共存或线程职责不唯一的场景。比如多个消费者等待不同类型的资源，或存在虚假唤醒（spurious wakeup）风险时，必须用 while 循环重检条件，此时 notifyAll 能确保所有可能符合条件的线程都有机会检查并处理。
常见建议：除非你完全确定只有一个线程在等待且条件严格一对一，否则优先使用 notifyAll，避免因漏唤醒导致死锁或永久阻塞。
底层行为不同：影响线程状态迁移路径
每个 Java 对象关联的 Monitor 包含两个队列：
– _EntryList：等待获取锁的线程（BLOCKED 状态）
– _WaitSet：调用 wait() 后挂起的线程（WAITING 状态）
notify 仅将一个线程从 _WaitSet → _EntryList；
notifyAll 是将全部线程从 _WaitSet → _EntryList。
这意味着 notifyAll 可能引发更多上下文切换和锁竞争，但换来的是更强的可预测性和容错性。
实际编码中容易忽略的关键细节
– 必须在 synchronized 块内调用，否则抛 IllegalMonitorStateException
– wait 必须配合 while 循环使用，不能用 if（防虚假唤醒）
– notify/notifyAll 不释放锁，只有同步块结束或显式 return 才会释放
– 唤醒操作对“谁该醒”无业务语义判断，只是通知机制；业务逻辑必须由线程自己在 wait 后重新验证条件
