TimeUnit.SECONDS.sleep() 比 Thread.sleep() 更可读、更安全：前者显式表达时间单位并强制处理 InterruptedException，后者需手动换算毫秒且易忽略中断；二者性能无差异，但纳秒级休眠存在精度风险。
TimeUnit.SECONDS.sleep() 为什么比 Thread.sleep() 更可读
因为 TimeUnit.SECONDS.sleep(5) 直观表达了“休眠 5 秒”，而 Thread.sleep(5000) 需要人工换算毫秒，容易出错且语义模糊。Java 的 TimeUnit 枚举把时间单位显式暴露在 API 层，编译期就约束了单位含义，避免魔数误用。
必须捕获 InterruptedException，不能忽略
调用 TimeUnit.SECONDS.sleep() 会声明抛出 InterruptedException，这是强制的。常见错误是直接吞掉异常或只打印堆栈却不恢复中断状态，导致上层无法感知线程被中断。
在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。
正确做法是：
- 在业务逻辑允许中断时，保留 throws InterruptedException
- 若必须捕获（如 Runnable 实现），应调用 Thread.currentThread().interrupt() 恢复中断标志
- 绝对不要写 catch (InterruptedException e) { } 这种空处理
支持所有 TimeUnit 枚举值，但注意精度丢失风险
TimeUnit.NANOSECONDS.sleep(1_000_000)、TimeUnit.MINUTES.sleep(1) 都合法，但底层仍调用 Thread.sleep()，而 JVM 对纳秒级休眠不保证精度——实际最小分辨率通常在 10–15ms。所以：
- 不要用 NANOSECONDS 或 MICROSECONDS 控制精确延时
- SECONDS、MINUTES、HOURS 更安全，语义也更匹配使用场景
- 若需高精度定时（如游戏循环、实时采样），应改用 ScheduledExecutorService 或系统级计时器
和 Thread.sleep() 性能完全一致，没有额外开销
TimeUnit.SECONDS.sleep(3) 底层就是调用 Thread.sleep(3000)，没有对象创建、无装箱、无反射。反编译 JDK 源码可见它只是做了单位换算和异常包装。所以：
- 可放心在高频路径中使用，比如日志限流、重试退避
- 不必担心 TimeUnit 枚举实例化成本（它是静态常量）
- 但别为了“看起来高级”而嵌套调用，例如 TimeUnit.HOURS.convert(5, TimeUnit.MINUTES) 再传给 sleep —— 直接用 TimeUnit.MINUTES.sleep(5) 更清晰
真正容易被忽略的是中断处理那一步：很多团队把 TimeUnit.sleep() 当成语法糖，却忘了它让中断契约更明显了——一旦用了它，你就不能再假装没看见线程协作机制。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
