不推荐用 system.currenttimemillis() 高精度计时,因其精度仅10~16ms、依赖系统时钟、易受时间调整影响且不单调;应使用 system.nanotime() 测量时间间隔,它基于单调高分辨率计时器,纳秒级且不受系统时间变更干扰。
用 system.currenttimemillis() 计算业务代码耗时,**不推荐用于高精度场景**。它的精度通常在 10~16 毫秒(取决于操作系统和 jvm 实现),无法准确测量毫秒级以下、尤其是微秒或纳秒级的执行时间。
为什么 currentTimeMillis 不适合高精度计时
该方法返回自 1970-01-01 00:00:00 UTC 起的毫秒数,底层依赖系统时钟(如 Windows 的 GetTickCount64 或 Linux 的 CLOCK_REALTIME)。这类时钟:
- 更新频率低(常见为每 10–16ms 更新一次)
- 可能受系统时间调整(NTP 同步、手动改时间)影响,导致倒退或跳变
- 不具备单调性(即 t2 ≥ t1 无法严格保证)
高精度计时的正确选择:System.nanoTime()
System.nanoTime() 是专为性能测量设计的 API:
- 返回的是纳秒级时间戳(实际精度仍取决于硬件,但通常优于 1 微秒)
- 基于单调递增的高分辨率计时器(如 CPU TSC、CLOCK_MONOTONIC),不受系统时间修改影响
- 只适用于“时间间隔”计算(差值有意义),绝对值无业务含义
✅ 正确用法示例:
long start = System.nanoTime(); doBusinessLogic(); // 你的业务代码 long end = System.nanoTime(); long costNanos = end - start; double costMs = costNanos / 1_000_000.0; // 转毫秒(保留小数)
实际使用中的关键注意事项
- 避免空循环或单次测量:JIT 编译、CPU 频率变化、GC 干扰会导致单次结果偏差大;应多次运行取平均值或使用 JMH 等专业基准测试工具
- 不要混用 nanoTime 和 currentTimeMillis:两者基准不同,相减无意义
- 注意 long 溢出风险:nanoTime 值极大(约每 292 年翻转一次),但差值计算极难溢出,无需担心
- 日志/监控中慎用:高频打点会显著增加开销,建议采样或使用异步计时器(如 Micrometer + Timer)
简单替代方案(仅限粗略估算)
如果只是快速验证某段逻辑是否“明显慢”,且对精度无要求(比如 >100ms),currentTimeMillis 可勉强用:
long start = System.currentTimeMillis(); doBusinessLogic(); long costMs = System.currentTimeMillis() - start; // 结果是整数毫秒
但请明确:这不是高精度,也不适合压测、性能调优或 SLA 统计。











