Thread.sleep会释放CPU但不释放锁，仍持有synchronized或ReentrantLock锁；与wait不同，它不用于协作等待，仅适用于简单延时，需正确处理InterruptedException并重设中断状态。
Thread.sleep 会释放 CPU 但不释放锁
这是最常被误解的一点：Thread.sleep 只是让当前线程暂停执行指定毫秒数，期间它仍然持有所有已获取的 synchronized 锁（或 ReentrantLock 的显式锁，如果没主动释放）。这和 Object.wait() 有本质区别——后者必须在同步块中调用，且会自动释放锁。
常见错误现象：在 synchronized 方法里调用 Thread.sleep(5000)，结果其他线程一直阻塞等不到锁，误以为“休眠等于让出资源”。
- 使用场景：适合做简单延时、轮询间隔、模拟耗时操作，**不涉及协作等待**
- 参数差异：
Thread.sleep(long)精度依赖系统定时器，通常有 10–15ms 误差；Thread.sleep(long, int)的纳秒部分会被忽略（JVM 不保证支持） - 必须捕获
InterruptedException，否则编译失败；若忽略该异常（比如只打印堆栈），可能掩盖线程被中断的意图
被中断时 sleep 会抛出 InterruptedException 并清除中断状态
Thread.sleep 是可响应中断的阻塞方法。一旦线程在休眠中收到 interrupt()，它会立即退出休眠，并抛出 InterruptedException，同时 JVM 自动将该线程的中断状态置为 false（即清空中断标记）。
容易踩的坑：只捕获异常却不重设中断状态，导致上层无法感知中断意图。
立即学习“Java免费学习笔记（深入）”；
- 正确做法是在
catch块末尾调用Thread.currentThread().interrupt() - 不要用
Thread.interrupted()判断后吞掉中断——它本身就会清除状态 - 如果线程正在执行计算型任务（无阻塞调用），需定期检查
Thread.currentThread().isInterrupted()主动退出
替代 sleep 的更合理选择
单纯“等一段时间”没问题，但凡涉及“等某个条件成立”，就该换方案。比如等待队列非空、资源就绪、信号到达——这些都不是 Thread.sleep 的设计目标。
- 用
LockSupport.parkNanos()：底层更轻量，不依赖锁，但需自行管理阻塞/唤醒逻辑 - 用
Condition.awaitNanos()：配合ReentrantLock，支持精确等待 + 中断响应 + 条件唤醒 - 用
ScheduledExecutorService延迟执行任务：比手动 sleep + 启动新线程更可控、可取消 - 避免在循环里写
while (!done) { Thread.sleep(10); }—— 这是 busy-waiting 的反模式，浪费 CPU 且延迟不准
public class SleepExample {
private static volatile boolean ready = false;
public static void main(String[] args) throws InterruptedException {
Thread t = new Thread(() -> {
try {
Thread.sleep(2000); // 模拟初始化耗时
ready = true;
} catch (InterruptedException e) {
Thread.currentThread().interrupt(); // 重设中断状态
return;
}
});
t.start();
// 错误：轮询+sleep，低效且不可靠
while (!ready) {
Thread.sleep(10);
}
// 正确：用 CountDownLatch 或 wait/notify，或改用 CompletableFuture
}
}
线程休眠不是同步机制，它不解决协作问题。真正难的不是“怎么睡”，而是“睡醒之后怎么知道该不该继续”——这个判断逻辑，往往比 sleep 本身更关键。 
