测耗时用 nanoTime，记日志、设超时、存时间戳用 currentTimeMillis；二者起点、单位、目标不同，不可混用：nanoTime 是单调递增纳秒计数器，适合精确测时；currentTimeMillis 对应 Unix 时间戳，适合时间点记录与外部对齐。
测耗时用 nanoTime，记日志、设超时、存时间戳用 currentTimeMillis。二者起点不同、单位不同、目标不同，不能混用。
测代码执行时间，只用 nanoTime
System.nanoTime() 是专为测量“过了多久”设计的单调递增计数器，不受系统时间调整影响——手动改时间、NTP 同步、闰秒都不会导致负值或跳变。它返回纳秒值，实际分辨率在 Linux/macOS 常达纳秒级，Windows 约 100 纳秒，远高于毫秒级的 currentTimeMillis。
使用时注意：
- 只做差值，不关心绝对值（比如
startTime和endTime相减） - 转毫秒要除以
1_000_000.0，不是1000 - 单次测量意义有限，建议批量运行（如 1000 次以上）并取中位数，避开 JIT 预热和 GC 干扰
- 避免在高频循环里反复调用，计时本身会干扰热点路径
记录时间点、判断超时，用 currentTimeMillis
System.currentTimeMillis() 对应 Unix 时间戳，表示自 1970-01-01 UTC 起的毫秒数，能直接转成 Date、LocalDateTime 或 ISO 格式，适合人类可读、数据库存储、订单号生成、任务调度等场景。
适用情况包括：
- 写日志时打上“现在几点”的时间戳
- 设置连接超时（如“5 秒未响应则断开”）
- 计算有效期（如 token 过期时间 = 当前时间 + 3600000）
- 与外部系统按标准时间对齐（如 HTTP Date 头、数据库时间字段）
注意：它不适合测短耗时，两次调用可能返回相同值；若业务对时钟稳定性要求极高（如金融撮合），需配合 NTP 监控或硬件校准。
绝对不能混用的典型错误
两者数值没有数学关系，交叉使用会引入隐蔽 bug：
- 不用
nanoTime()做定时调度（如“10 秒后发通知”），它不映射真实时间点 - 不拿
currentTimeMillis()减nanoTime()，结果无意义 - 不把
nanoTime()值传给Thread.sleep()或ScheduledExecutorService - 不把
nanoTime()绝对值当时间戳存库或打印日志
性能与精度的现实考量
虽然 currentTimeMillis() 在 Windows 上调用开销略低（约 25ns vs nanoTime 的 50ns），但其毫秒级分辨率在多数性能敏感场景下反而成为瓶颈。例如游戏帧率控制（16ms/帧）、锁竞争分析、微基准测试等，都依赖 nanoTime() 的稳定性和高分辨率。
若需高频低开销时间戳（如大量日志打点），可封装一个定期刷新的 CachedClock，容忍几十毫秒误差，兼顾效率与可用性。
