会，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 就不是合适工具了——它设计目标本就是“粗粒度休眠”，不是实时调度原语。
