会，Thread.sleep 使当前线程进入 TIMED_WAITING 状态，释放 CPU 时间片但不释放 synchronized 或 ReentrantLock 锁，需捕获 InterruptedException 并建议恢复中断状态。

Thread.sleep 会释放 CPU 吗？

会。调用 Thread.sleep 后，当前线程进入 TIMED_WAITING 状态，操作系统会将其从运行队列移出，不占用 CPU 时间片，直到指定毫秒数过去或被中断。

怎么正确调用 Thread.sleep 避免阻塞和异常

它抛出 InterruptedException，必须处理，否则编译失败；忽略它或吞掉异常是常见错误。

• 必须用 try-catch 包裹，不能只声明 throws（尤其在 Runnable/lambda 中）
• 捕获后建议恢复中断状态：调用 Thread.currentThread().interrupt()
• 传入负数会立即抛出 IllegalArgumentException
• 传入 0 表示“让出当前时间片，但不保证休眠”，等价于 Thread.yield() 的弱化版

示例：

try {
    Thread.sleep(1000);
} catch (InterruptedException e) {
    Thread.currentThread().interrupt();
    // 或根据业务决定是否退出循环、清理资源
}

Thread.sleep 和 Object.wait 的关键区别

两者都让线程等待，但语义和行为完全不同：

• Thread.sleep 不释放任何锁，即使在 synchronized 块中调用，锁依然持有
• Object.wait 必须在 synchronized 块内调用，且会释放当前持有的该对象锁
• Thread.sleep 只能被 interrupt() 中断；wait 还可被 notify() 唤醒
• 没有对象依赖，适合纯延时场景（如轮询间隔、限流降频）

为什么 sleep(1) 实际可能停顿远大于 1ms

这是操作系统调度精度和 JVM 实现共同导致的：

• Windows 默认定时器精度约 15.6ms，sleep(1) 往往实际停 15–16ms
• Linux 下受 CONFIG_HZ 和 CFS 调度影响，通常更准，但仍非微秒级
• JVM 不做补偿，不会“补足”误差；连续 sleep 累积偏差明显
• 高精度延时（如音视频同步）应避免依赖 Thread.sleep，改用 LockSupport.parkNanos 或系统级 timer

真正需要亚毫秒控制时，Thread.sleep 就不是合适工具了——它设计目标本就是“粗粒度休眠”，不是实时调度原语。