System.currentTimeMillis与System.nanoTime的区别与应用场景
在 Java 开发中,时间处理是绕不开的话题。很多新手甚至老手都会在 System.currentTimeMillis() 和 System.nanoTime() 之间犯迷糊。简单一句话总结就是:测代码跑多快,用 nanoTime;记时间点、设超时、存时间戳,用 currentTimeMillis。
在 Java 开发中,时间处理是绕不开的话题。很多新手甚至老手都会在 System.currentTimeMillis() 和 System.nanoTime() 之间犯迷糊。简单一句话总结就是:测代码跑多快,用 nanoTime;记时间点、设超时、存时间戳,用 currentTimeMillis。两者起点不同、单位不同、目标不同,绝对不能混用。

先放个大原则:测代码执行时间,只用 nanoTime;记日志、设超时、存时间戳,则靠 currentTimeMillis。两者从一开始就是为不同场景设计的,混用只会带来隐蔽的 bug。
测代码执行时间,只用 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,容忍几十毫秒的误差,这样能在效率和可用性之间找到平衡。


































