Thread.sleep()在循环中伤性能因频繁线程状态切换引发内核态调度开销，1000次1ms睡眠可能累积数百微秒延迟；LockSupport.parkNanos()更轻量但需配合unpark和状态检查使用。
Thread.sleep() 在循环里为什么特别伤性能
因为每次调用 Thread.sleep() 都会触发线程状态切换：从 RUNNABLE 切到 TIMED_WAITING，再被 JVM 调度器唤醒切回 RUNNABLE。这个过程涉及内核态介入、上下文保存/恢复，不是纯用户态操作。高频循环中反复睡醒，CPU 时间大量耗在调度开销上，而不是干活。
- 哪怕只睡 1ms，1000 次循环 ≈ 至少几百微秒实际调度延迟（尤其在负载高的机器上）
- 如果循环体本身很轻（比如轮询一个标志位），
Thread.sleep()的开销可能比业务逻辑还高 - JVM 不保证睡眠精度——Linux 下通常依赖
timerfd或nanosleep()，但受系统负载、CFS 调度周期影响，实际唤醒可能延迟 10–50ms
替代方案：用 LockSupport.parkNanos() 更可控
LockSupport.parkNanos() 是 JVM 底层等待机制，不经过线程状态机全量切换，唤醒路径更短，精度也略好（仍不绝对精确，但抖动小）。它适合做“轻量级自旋+等待”混合策略。
- 必须配合
LockSupport.unpark()使用，不能单独当 sleep 替代品——它不释放 monitor，也不参与 synchronized 锁竞争 - 常见误用：在无条件循环里直接
LockSupport.parkNanos(1_000_000)，结果线程永远 park 住（没别的线程 unpark 它） - 正确姿势是和状态检查结合，比如：
while (!ready) { LockSupport.parkNanos(100_000); }
真正该用 sleep 的场景其实很窄
只有当你明确需要「让出 CPU + 强制暂停一段可观测时间」时才该用 Thread.sleep()，比如模拟人工操作、限流降频、或调试时临时卡点。其他情况基本都有更好选择。
- 轮询共享变量？用
volatile+ 自旋 +Thread.onSpinWait()（Java 9+）更合适 - 等某个条件满足？优先用
CountDownLatch、Condition.await()或CompletableFuture，它们由 JVM 和 OS 协同优化唤醒 - 定时任务？交给
ScheduledExecutorService，别自己 while + sleep 模拟 - 注意：
Thread.sleep(0)并不“不睡”，它会让出当前时间片，但仍是完整状态切换，和 parkNanos(0) 行为不同
容易被忽略的兼容性细节
Thread.sleep() 在所有 Java 版本行为一致，但 park 系列方法在 JDK 8 和 JDK 11+ 有细微差异：JDK 11 后 parkNanos() 对极小值（如
立即学习“Java免费学习笔记（深入）”；
- 不要假设
parkNanos(1)一定能停够 1 纳秒——它只是提示 JVM “尽量等这么久”，实际取决于系统时钟粒度（通常 10–15ms） - 在容器环境（尤其是 CPU limit 限制下的 Kubernetes Pod）里，
Thread.sleep()的唤醒延迟可能突然放大到 100ms+，而 park 相对稳定些 - 如果代码要跑在 Android（Dalvik/ART）上，
LockSupport行为和 HotSpot 有差异，建议统一走Handler或Looper机制
Thread.sleep()。 
