Thread.sleep() 释放 CPU 但不释放锁，调用后线程进入 TIMED_WAITING 状态，持有 synchronized 或 ReentrantLock 时其他线程无法获取该锁；需在同步块外调用，并正确处理 InterruptedException。
Java 中的 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。若忽略该异常，上层无法感知线程已被中断，可能导致资源泄漏或无法优雅关闭。
立即学习“Java免费学习笔记（深入）”；
- 必须用 try-catch 包裹，且推荐恢复中断状态：
Thread.currentThread().interrupt(); - 不要空 catch 或只打印堆栈——这等于屏蔽了关键控制信号
- 被中断后，线程状态从 TIMED_WAITING 直接转为 RUNNABLE，可继续执行后续逻辑
适用场景与替代选择
sleep() 的本质是“固定延迟 + 主动让 CPU”，不是“等待条件”。用错场景比用错语法更危险。
- 适合：轮询间隔（如每 2 秒查一次状态）、模拟网络延迟、防高频重试、定时任务节奏控制
- 不适合：等待某个变量变为 true、等待 I/O 完成、协调多个线程协作 —— 此类应选
wait()/notify()、CountDownLatch、Condition.await()或LockSupport.park() - 对比记忆：
sleep是“我睡我的，锁照拿”；wait是“我把锁交出去，等通知再抢”
