System.currentTimeMillis和System.nanoTime的区别与应用场景

测耗时用 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，容忍几十毫秒误差，兼顾效率与可用性。