Java 中 sleep 方法在多线程环境下如何释放 CPU 资源

先说一个核心结论：Thread.sleep() 确实会让出 CPU，但它在锁面前寸步不让。这个差异正是多线程开发中最容易踩的坑之一。

sleep 确实让出 CPU 执行权

调用 Thread.sleep(n) 之后，当前线程从 RUNNABLE 跳转到 TIMED_WAITING，JVM 会把它从 CPU 调度队列中踢出去。操作系统不再给它分配时间片，CPU 资源实打实地释放了，其他线程——不管要不要同一把锁——都有机会被调度执行。

• 即便只休眠 1 毫秒，线程也会短暂退出 CPU 竞争
• Thread.sleep(0) 不是“不休眠”，而是主动触发调度器重评估；可能被立刻选中，也可能让出剩余时间片
• 实际休眠时长受系统定时器精度影响（Windows 通常 10–15ms，Linux 可达 1ms），别指望用它做高精度计时

但它完全不碰锁——这点必须警惕

如果线程正握着 synchronized 锁或者 ReentrantLock，调用 sleep() 不会释放锁。其他线程要是想拿这把锁，只能眼巴巴等着休眠结束；如果不需要这把锁，那倒不受影响。

• 错误写法：synchronized(obj) { doWork(); Thread.sleep(1000); } → 锁被霸占 1 秒，吞吐量直接往下掉
• 正确做法：先干完临界区的活儿，退出同步块，然后再 sleep —— 锁及时释放，CPU 也释放，两不耽误
• ReentrantLock 同理：必须在 lock.unlock() 之后 sleep，别在 lock 保护范围内磨蹭

中断处理不可忽略

sleep() 是可以被 interrupt() 提前唤醒的，而且会抛出 InterruptedException。要是把这个异常随手忽略，上层就没法知道线程已经被中断了，可能导致资源泄漏或者优雅关闭失效。

• 必须用 try-catch 包起来，并且推荐恢复中断状态：Thread.currentThread().interrupt();
• 别搞空 catch 或者只打印堆栈——这等于是把关键的控制器信号给屏蔽了
• 被中断后，线程状态从 TIMED_WAITING 直接变成 RUNNABLE，可以继续执行后面的逻辑

适用场景与替代选择

sleep() 的本质是“固定延迟 + 主动让 CPU”，不是“等待条件”。场景用错了比语法用错了更难救。

• 适合：轮询间隔（比如每 2 秒查一次状态）、模拟网络延迟、防高频重试、定时任务节奏控制
• 不适合：等着某个变量变成 true、等着 I/O 完成、协调多个线程协作——这些场合应该选 wait()/notify()、CountDownLatch、Condition.await() 或者 LockSupport.park()
• 对比记忆：sleep 是“我睡我的，锁照拿”；wait 是“我把锁交出去，等通知再抢”