java中wait()不支持多条件判断，必须用while循环检查复合条件；需封装为原子谓词如canprocess()，配合notifyall和超时机制确保线程安全与可靠性。
Java 中 wait() 方法本身不支持“多条件”逻辑判断，它只负责挂起线程并释放锁；真正的多条件等待控制，必须由程序员在 循环中用 while 检查复合条件 来实现。关键不是 wait 怎么改，而是怎么组织等待逻辑。
必须用 while 而非 if 包裹 wait
这是最易忽略却最关键的一点。if 只检查一次，一旦发生虚假唤醒（spurious wakeup）或条件被其他线程中途修改，线程就会错误地继续执行。
- ✅ 正确写法：每次被唤醒后都重新评估所有条件是否真正满足
- ❌ 错误写法：
if (conditionA && conditionB) { wait(); }—— 醒来就执行，不管条件是否还成立
把多个条件合并为一个可判定的布尔表达式
多条件等待的本质是“等待直到所有条件同时为真”，比如：“缓冲区非空 且 数据类型匹配 且 校验通过”。应将其抽象为一个清晰、原子的业务谓词：
- 定义一个私有方法，如
canProcess()，内部封装全部判断逻辑 - 在同步块中持续轮询该方法，例如：
while (!canProcess()) { wait(); } - 避免在 while 条件里直接写长表达式，易读性差且难以复用
配合 notifyAll 保证条件变更的可见性
当多个不同条件共用同一个锁对象时（常见于共享资源类），单用 notify() 很可能唤醒错的线程——比如只改变了 conditionA，却唤醒了只等 conditionB 的线程。
- 只要共享状态发生变化，就调用
notifyAll()，让所有等待者重新竞争并各自检查自己的条件 - 虽然看似低效，但比漏唤醒或逻辑错乱更可靠；JVM 对等待队列的唤醒调度不保证顺序
- 若性能敏感，可考虑为不同条件分配独立锁对象，但会增加设计复杂度
超时机制防止无限等待
即使条件逻辑正确，外部依赖（如网络响应、I/O）也可能长期不就绪。建议始终使用带超时的 wait(long timeout)：
- 超时后再次检查条件，决定是重试、降级还是抛异常
- 注意：
wait(timeout)返回时无法区分是被 notify 还是超时，需靠条件变量二次确认 - 示例：
long remaining = deadline - System.currentTimeMillis(); if (remaining > 0) lock.wait(remaining);
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
