Java中Thread.sleep()定时精度不高且单向延迟，实际休眠时间总≥指定值；其精度受OS调度粒度限制（Windows约15ms，Linux/macOS约10–20μs），并可能因负载波动，中断时抛出InterruptedException且清中断状态。
Java 中 Thread.sleep() 的定时精度并不高，实际休眠时间往往比指定值更长；它开销极小，但不适合高精度场景——这是权衡的核心。
sleep 的实际精度受操作系统限制
Java 的 sleep 最终依赖底层系统调用（如 Linux 的 clock_nanosleep、Windows 的 SleepEx），因此精度由 OS 决定：
- Windows 下最小调度粒度约 15ms，即使传入
sleep(1)，真实延迟通常在 10–20ms 之间波动 - Linux/macOS 理论支持纳秒级参数，但实际误差仍为 ±10–20μs，且受系统负载、调度器抢占影响
- 当指定毫秒数小于系统时钟粒度（如 Windows 下
性能开销几乎可忽略
sleep 是轻量级阻塞操作，不轮询、不占用 CPU，线程直接进入 TIMED_WAITING 状态：
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 内核层面挂起线程，无需用户态循环或锁竞争
- 唤醒由定时器中断触发，无主动检查开销
- 相比
wait/notify或park/unpark，它不涉及对象监视器，调用路径更短
何时用 sleep？何时该换方案？
选 sleep 是因为它简单、安全、低开销；但精度要求一旦超过 ±10ms，就应考虑替代方案：
立即学习“Java免费学习笔记（深入）”；
- 适合：日志轮转间隔、心跳探测周期、UI 刷新节流、模拟网络延迟等容忍误差的场景
- 不适合：实时音视频同步、高频行情推送、微秒级传感器采样控制
- 替代选择：
ScheduledExecutorService（基于DelayQueue，精度略优）、System.nanoTime()+ 自旋校准（仅适用于极短且可控的等待）、或 JNI 调用高精度定时器（如 Windows 多媒体定时器）
几个容易被忽略的关键细节
理解这些能避免常见陷阱：
-
sleep(0)不休眠，等效于Thread.yield()，只是让出当前时间片 -
sleep(millis, nanos)中的纳秒部分仅作“向上取整”：若 nanos > 0，实际休眠至少为millis + 1ms - 被中断时抛出
InterruptedException，同时会清除线程中断状态，需手动恢复（Thread.currentThread().interrupt()） - 精度误差是单向的——
sleep只会“睡过头”，不会提前唤醒（除非被中断）
