sleep()在同步块内不释放锁，线程保持timed_waiting状态并独占monitor；而wait()会释放锁并进入waiting状态，需配合notify()使用，二者在锁管理和协作机制上存在本质区别。
Java 中 sleep() 方法在同步块内执行时，不会释放当前线程持有的锁。这是它与 wait() 的关键区别之一。
sleep 不释放锁，线程仍独占 monitor
Thread.sleep(long) 是一个静态方法，仅让当前线程暂停执行指定毫秒数，但线程状态变为 TIMED_WAITING，而它所持有的 synchronized 锁（即 monitor）依然被牢牢占用。其他线程即使满足进入同步块的条件，也会因锁未释放而阻塞等待。
- 例如：两个线程同时竞争同一把对象锁，线程 A 进入 synchronized 块后调用
sleep(5000)，线程 B 在这 5 秒内无法进入该同步块 - 锁的释放只发生在 synchronized 块自然退出、异常抛出或显式使用
Lock.unlock()（针对显式锁）时
与 wait() 的核心差异在于锁管理
wait() 必须在 synchronized 块中调用，且会主动释放锁，进入 WAITING 状态；而 sleep() 无需同步上下文，也不参与锁的协作机制。
-
wait()：释放锁 → 等待唤醒 → 重新竞争锁 → 继续执行 -
sleep()：不释放锁 → 暂停执行 → 时间到自动恢复 → 继续持有锁执行 - 误用
sleep()替代wait()容易导致死锁或吞吐量下降
实际编码中的注意事项
在需要“让出 CPU 但保持临界区排他性”的场景（如轮询检查+短暂休眠），sleep() 是合适的；但若目标是“等待某个条件成立并允许其他线程修改共享状态”，就必须用 wait()/notify() 或 Condition.await()/signal()。
- 避免在长耗时的 sleep 前持有粗粒度锁，否则严重降低并发性
- 不要在 synchronized 块里用
sleep()实现条件等待逻辑——这是设计缺陷 - 可考虑用
LockSupport.parkNanos()或ReentrantLock配合Condition实现更可控的等待
小结：行为明确，选对工具
sleep() 的语义就是“我歇一会儿，但东西还归我管”；它不是同步协调工具，而是线程调度辅助手段。理解这一点，才能避免在并发设计中踩坑。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
