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 状态：
- 内核层面挂起线程，无需用户态循环或锁竞争
- 唤醒由定时器中断触发，无主动检查开销
- 相比
wait/notify或park/unpark，它不涉及对象监视器，调用路径更短
何时用 sleep？何时该换方案？
选 sleep 是因为它简单、安全、低开销；但精度要求一旦超过 ±10ms，就应考虑替代方案：
- 适合：日志轮转间隔、心跳探测周期、UI 刷新节流、模拟网络延迟等容忍误差的场景
- 不适合：实时音视频同步、高频行情推送、微秒级传感器采样控制
- 替代选择：
ScheduledExecutorService（基于DelayQueue，精度略优）、System.nanoTime()+ 自旋校准（仅适用于极短且可控的等待）、或 JNI 调用高精度定时器（如 Windows 多媒体定时器）
几个容易被忽略的关键细节
理解这些能避免常见陷阱：
-
sleep(0)不休眠，等效于Thread.yield()，只是让出当前时间片 -
sleep(millis, nanos)中的纳秒部分仅作“向上取整”：若 nanos > 0，实际休眠至少为millis + 1ms - 被中断时抛出
InterruptedException，同时会清除线程中断状态，需手动恢复（Thread.currentThread().interrupt()） - 精度误差是单向的——
sleep只会“睡过头”，不会提前唤醒（除非被中断）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
