sleep()不释放锁，wait()释放锁；前者可在任意上下文调用、时间驱动唤醒，后者必须在synchronized块内调用、事件驱动唤醒，且需匹配对象锁。
sleep() 不释放锁，wait() 释放锁——这是两者在锁资源处理上最根本、最不可忽略的规则。
锁行为：阻塞时是否交出对象锁
线程进入阻塞状态后，对已获取的同步锁（monitor）的处置方式，直接决定了其他线程能否进入临界区：
- sleep()：无论是否处于 synchronized 块中，只要线程持有锁，调用 sleep() 后仍牢牢占据该锁。其他线程尝试进入同一同步块时会被阻塞在 BLOCKED 状态，直到 sleep 结束且原线程退出同步区域。
- wait()：必须在 synchronized 块内调用，一旦执行，立即释放当前持有的对象锁，并将线程转入 WAITING 或 TIMED_WAITING 状态。此时其他线程可成功获取该对象锁，进入同步代码执行。
调用前提：为什么 wait() 必须同步，而 sleep() 没有此限制
约束源于设计意图和锁操作的安全性要求：
AI舌诊面诊问诊医疗系统+诊疗商城系统源码
下载
AI 舌诊面诊问诊医疗系统 + 诊疗商城系统源码是一套结合 AI 辅助诊断与商品转化的健康类程序，基于浩创云、ThinkPHP（PHP）开发，支持微信服务号与 H5 端，适合做中医舌诊面诊问答、健康建议推送以及配套诊疗商品的运营。
- wait() 的本质是“释放我正占着的锁，然后等别人通知我”。若未持有锁就允许调用，会导致语义混乱甚至运行时异常（IllegalMonitorStateException），所以 JVM 强制要求调用前必须已通过 synchronized 获得对应对象锁。
- sleep() 只是让当前线程暂停执行，不涉及任何对象锁的转移或协调，因此可在任意上下文调用，无需前置同步条件。
唤醒机制：谁来决定线程何时恢复执行
阻塞结束的触发逻辑完全不同，直接影响线程协作的可控性：
- sleep()：时间驱动。指定毫秒数一到，线程自动从 TIMED_WAITING 进入 RUNNABLE 状态，重新参与 CPU 竞争；也可被 interrupt() 中断提前唤醒，抛出 InterruptedException。
- wait()：事件驱动。默认无限等待，必须由其他线程在同一对象上调用 notify() 或 notifyAll() 才能唤醒；支持 wait(timeout) 设置超时，超时后线程自动回到锁竞争队列，但需重新获取锁才能继续执行。
典型误用场景与后果
违反锁规则常引发死锁或响应停滞，例如：
- 在非同步块中调用 wait() → 抛出 IllegalMonitorStateException，程序中断。
- 用 sleep() 替代 wait() 实现“等待条件成立” → 锁一直被占，其他线程无法修改共享状态，造成假死或忙等。
- 调用 notify() 时未使用与 wait() 相同的对象锁 → 唤醒失效，等待线程永远挂起。
