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 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
正确做法是：
- 在业务逻辑允许中断时，保留 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() 当成语法糖，却忘了它让中断契约更明显了——一旦用了它，你就不能再假装没看见线程协作机制。
