notify仅唤醒等待队列中一个线程，具体由JVM调度器决定，不保证顺序；被唤醒线程需重新竞争对象锁才能继续执行，其余线程保持wait状态。
notify 方法只唤醒等待队列中的一个线程，且不保证是哪个，具体由 JVM 调度器决定。它不会清空等待队列，也不会改变其他仍在 wait 状态的线程状态；被唤醒的线程需重新竞争对象锁，成功获取后才能继续执行。
等待队列不是 FIFO，唤醒顺序不可预测
Java 中每个对象关联一个等待队列（wait set），由 JVM 内部维护。notify 并不按“先进先出”或任何显式策略选择线程，而是交由底层线程调度机制决定——可能是随机选，也可能受操作系统线程优先级、JVM 实现（如 HotSpot 的 Park/Unpark 机制）影响。因此，不能依赖 notify 唤醒特定线程，也不应假设唤醒顺序。
notify 不释放锁，被唤醒线程需重新争抢
调用 notify 时，当前线程必须持有该对象的 monitor 锁；notify 执行完后，当前线程仍持有锁，直到 synchronized 块结束或显式退出临界区。此时，被唤醒的线程从 wait 状态转为“blocked”，进入该对象的锁竞争队列，只有成功获得锁后，才会从 wait() 调用处继续向下执行。
未被唤醒的线程保持 wait 状态，不受影响
notify 只影响一个线程，其余在同一个对象上 wait 的线程继续阻塞，不会被中断或超时（除非设置了 timeout 或被 interrupt）。若需唤醒全部，应使用 notifyAll；若业务逻辑依赖精确唤醒（如生产者-消费者中只唤醒一个消费者），需配合条件判断和循环 wait 模式，避免虚假唤醒。
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
立即学习“Java免费学习笔记（深入）”；
典型误用：不配合 while 循环检查条件
常见错误是在 wait 前用 if 判断条件，导致唤醒后直接执行后续逻辑，忽略条件是否真正满足。正确做法是：
- 始终用 while 循环包裹 wait()，每次唤醒都重新检查条件
- notify 前确保条件已更新（如修改共享状态、插入数据）
- 避免在非 synchronized 上下文中调用 notify，否则抛 IllegalMonitorStateException
不复杂但容易忽略：notify 的语义很轻量，它只是“发个信号”，真正的协调靠锁、条件变量和程序员的逻辑控制。
