sleep()不能替代wait()，因为sleep()不释放锁而wait()必须释放锁，这是二者不可互换的根本原因；错误混用会导致卡死或死锁。
为什么 sleep() 不能替代 wait()？锁行为是分水岭
因为 Thread.sleep() 从不释放锁，而 Object.wait() 必须释放锁——这是二者不可互换的根本原因。你在线程协作中若用错，轻则逻辑卡死，重则引发死锁。
-
Thread.sleep(1000)在synchronized块里执行时，其他线程根本进不来同一把锁的临界区，哪怕你只是想“等 1 秒再看看条件是否满足” -
obj.wait(1000)会立刻释放obj的锁，让别的线程能进去修改状态、调用notify()，这才是协作的基础 - 常见错误现象：
wait()报IllegalMonitorStateException——说明没在synchronized(obj)块里调用；sleep()被误放在协作逻辑里，导致消费者永远等不到生产者（因为生产者被锁住进不来）
什么时候该用 sleep()？轮询、延时、节奏控制就用它
Thread.sleep() 是“我暂停一下，不关别人事”的单线程节拍器，适合不需要通信、只控制自身节奏的场景。
- 典型使用场景：定时日志打印、HTTP 重试间隔、模拟网络延迟、UI 线程防抖
- 参数注意：
Thread.sleep(0)不是“不睡”，而是主动让出当前时间片，效果接近Thread.yield()，但更可靠；Thread.sleep(1)实际可能休眠 10–15ms（受系统调度精度限制） - 必须捕获
InterruptedException，且通常应向上抛或恢复中断状态（Thread.currentThread().interrupt()），否则会吞掉中断信号，破坏线程协作契约
wait() 怎么写才安全？三要素缺一不可
Object.wait() 不是独立可用的 API，它必须和 synchronized、notify()/notifyAll() 组成闭环，漏掉任一环都会出问题。
- 三要素必须同时满足：持有对象锁 + 在同步块内调用 wait() + 由另一个线程在同对象上调用 notify()/notifyAll()
- 别用
wait()替代sleep()来“简单等待几秒”——除非你真需要释放锁并允许其他线程介入；否则直接用wait(3000)也得配套notify()或接受超时后继续执行 - 唤醒建议用
notifyAll()：多个线程wait()同一个对象时，notify()只随机唤醒一个，容易遗漏；而notifyAll()虽有性能开销，但语义清晰、不易出错
wait(long) 和 sleep(long) 都带超时，区别在哪？
表面都是“等够时间就继续”，但背后机制完全不同：wait(long) 是条件等待的兜底策略，sleep(long) 是无条件暂停。
-
obj.wait(5000)：进入阻塞队列，释放锁；5 秒内若被notify()就提前醒来；超时后自动重新竞争锁，再检查条件是否成立（推荐配合 while 循环使用） -
Thread.sleep(5000)：进入 TIMED_WAITING 状态，不释放锁；5 秒一到立刻回到 RUNNABLE，不管外部状态有没有变化 - 性能影响：频繁
wait/notify涉及锁队列与条件队列切换，比sleep()开销略大；但这是为协作付出的必要成本，不能因怕开销就退化成轮询 +sleep()
sleep() 轮询，既浪费 CPU，又无法响应中断，还容易错过状态变更。 
