notify 不处理超时与中断，仅唤醒等待线程；超时和中断由 wait() 处理，需配合 while 循环、异常捕获及条件重检来正确实现线程协作。
notify 本身不处理超时与中断，它只负责唤醒一个等待线程，后续的超时和中断逻辑需由 wait() 调用方自行保障。
wait() 才是超时与中断的实际入口
Java 中线程进入等待状态靠的是 Object.wait()（或带超时参数的 wait(long timeout)、wait(long timeout, int nanos)），不是 notify()。notify 只是“发信号”，不参与等待控制。
- 调用
wait()的线程会释放锁并挂起，直到被notify()或notifyAll()唤醒，或超时到期，或被中断 - 如果用了带超时的
wait(5000)，5 秒后即使没收到 notify，线程也会自动醒来（返回后需检查条件是否真正满足） - 若线程在 wait 中被其他线程调用
interrupt()，会立即抛出InterruptedException，并清除中断状态
notify 不会响应中断，也不感知超时
notify() 是一个无阻塞、无异常、无返回值的本地方法。它只是修改对象监视器的等待队列状态，不会：
- 检查调用者是否被中断（调用 notify 时中断状态不影响它）
- 等待任何条件或时间（它瞬间完成）
- 保证唤醒的是“预期的那个线程”（唤醒哪个由 JVM 决定，不可控）
正确配合超时与中断的典型写法
实际开发中，应把超时判断、中断响应、条件重检都放在 wait 外层循环里，notify 仅作辅助信号：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
立即学习“Java免费学习笔记（深入）”；
- 用 while 循环包裹 wait，防止虚假唤醒（spurious wakeup）
- 捕获 InterruptedException 并合理处理（如恢复中断状态、退出等待逻辑）
- 超时后仍要检查业务条件，不能默认条件已满足
示例片段：
synchronized (lock) {
while (!conditionMet()) {
try {
lock.wait(3000); // 最多等 3 秒
} catch (InterruptedException e) {
Thread.currentThread().interrupt(); // 恢复中断状态
throw new RuntimeException("Wait interrupted", e);
}
}
// 条件满足，继续执行
}
notify 和 interrupt 的协作边界要分清
若想让等待线程“立刻退出等待”，推荐做法是：先中断线程，再 notify（可选）：
- 中断正在 wait 的线程 → 触发 InterruptedException → 线程跳出 wait
- notify 不是必须的，但有时可作为“双重保险”，尤其当不确定线程是否真在 wait 中
- 注意：notify 无法唤醒已被中断并抛出异常的线程（它已经醒了）
