怎么利用 Thread.sleep 让当前线程进入计时等待并释放 CPU

顺亿

2026-09-16 • 👁 0人浏览过

会，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

就不是合适工具了——它设计目标本就是“粗粒度休眠”，不是实时调度原语。

相关文章