TimeUnit 更安全因封装单位换算逻辑，避免手算错误；提供 sleep() 方法自动处理中断；toXxx() 为向上转换，convert() 为向下转换；并发工具类强制指定单位防误传。
TimeUnit 为什么比直接用毫秒更安全
因为 TimeUnit 把时间单位和换算逻辑封装进枚举值里，避免手写 1000 * 60 * 60 这类易错计算。比如把 2 小时转成毫秒，TimeUnit.HOURS.toMillis(2) 比 2 * 60 * 60 * 1000 更可读、不易漏乘或错位。
常见错误现象：Thread.sleep(30 * 60 * 1000) 写成 Thread.sleep(30 * 60)，结果只睡了 1.8 秒，而不是预期的 30 分钟。
- 所有转换都基于标准定义（1 小时 = 3600 秒），不依赖系统时区或夏令时
- 支持的单位从
NANOSECONDS到DAYS，但TimeUnit.WEEKS不存在——Java 没提供周级枚举 - 在高精度场景（如
NANOSECONDS转MICROSECONDS）要注意整数截断：TimeUnit.NANOSECONDS.toMicros(999)返回0，不是四舍五入
Thread.sleep 怎么用 TimeUnit 避免类型混淆
Thread.sleep() 只接受 long 类型的毫秒数，但业务逻辑里常以分钟、小时表达等待时间。TimeUnit 提供了 sleep(long) 方法，直接封装了单位转换和异常处理。
使用场景：定时任务中“每 5 分钟检查一次”，不要写 Thread.sleep(5 * 60 * 1000)，改用：
立即学习“Java免费学习笔记（深入）”；
TimeUnit.MINUTES.sleep(5);
这行代码等价于 Thread.sleep(TimeUnit.MINUTES.toMillis(5))，但更简洁，且自动处理 InterruptedException 并重新抛出（不吞异常）。
- 必须捕获或声明
InterruptedException，TimeUnit.sleep()不会静默忽略它 - 不能传负数，否则抛
IllegalArgumentException；而Thread.sleep(-1)会直接抛IllegalArgumentException，行为一致 - 如果在循环中调用，别忘了在 catch 块里恢复中断状态：
Thread.currentThread().interrupt();
toXxx() 和 convert() 两个转换方法的区别在哪
toSeconds()、toMillis() 等是“向上转换”：把小单位数值转成大单位的等效值（如 120_000 毫秒 → 120 秒）；convert() 是“向下转换”：把一个数值按指定单位解释后，转成目标单位的等效值（如把数字 2 当作“2 小时”，转成毫秒）。
示例对比：
TimeUnit.SECONDS.toMillis(120); // → 120_000（120 秒 = 120_000 毫秒）<br>TimeUnit.MILLISECONDS.convert(2, TimeUnit.HOURS); // → 7_200_000（2 小时 = 7_200_000 毫秒）
-
toXxx()的参数是“源单位下的数值”，返回“目标单位下的等效数值” -
convert()的第一个参数是“原始数值”，第二个是“该数值所代表的单位”，返回“换算到目标单位的数值” - 两者在整数溢出时都可能返回错误结果（如超大数值转
NANOSECONDS），但不会抛异常——得靠调用方自己校验范围
并发工具类里哪些地方隐式用了 TimeUnit
java.util.concurrent 包里大量 API 接收 TimeUnit 参数，比如 Future.get(long timeout, TimeUnit unit)、ScheduledExecutorService.schedule(Runnable, long delay, TimeUnit unit)。这些地方不接受毫秒，强制你显式声明单位，避免误传。
容易踩的坑：
- 传错单位：比如把
TimeUnit.SECONDS写成TimeUnit.MILLISECONDS，导致任务延迟被放大 1000 倍 - 忽略默认单位：某些构造器（如
ThreadPoolExecutor的keepAliveTime）必须配TimeUnit，漏掉就编译不过，但 IDE 可能提示模糊 - 测试时用
TimeUnit.NANOSECONDS做超短延迟，实际执行可能因系统调度达不到精度，尤其在 Windows 上
复杂点在于，不同 JVM 实现对纳秒级精度的支持差异很大，而 TimeUnit 本身不解决调度问题——它只做数学换算。真正控制精度的，是底层 OS 和 JVM 的线程调度器。
