System.currentTimeMillis()不准因受NTP同步、时钟回拨、休眠等影响，反映墙钟时间而非CPU执行时间；仅适用于单机调试、粗粒度耗时预估；推荐用System.nanoTime()测间隔，生产环境应交由AOP、Filter或OpenTelemetry等工具链处理。
直接用 System.currentTimeMillis() 测耗时，为什么不准
因为 System.currentTimeMillis() 返回的是系统当前时间戳（毫秒级），本质是基于系统时钟，受 NTP 同步、时钟回拨、系统休眠等影响。它反映的是“墙钟时间”，不是 CPU 实际执行时间。在高并发或跨机器场景下，两次调用之间可能被调度暂停、线程切换、GC 暂停，导致测出的耗时远大于真实 CPU 运行时间。
什么场景下还能凑合用 System.currentTimeMillis()
只适用于粗粒度、非关键路径、单机调试阶段的耗时观察，比如：接口整体响应时间预估、后台批处理任务的大致完成间隔、日志里打个“开始/结束时间戳”用于人工对齐。
- 必须确保两次调用在同一线程、无明显阻塞（如 I/O 等待、锁竞争）
- 不能用于性能压测、SLA 统计、熔断阈值判断
- 避免跨 JVM 或分布式调用链中单独依赖它计算子环节耗时
更靠谱的替代方案：用 System.nanoTime()
System.nanoTime() 返回的是纳秒级单调递增计数器，不受系统时钟调整影响，适合测量间隔。虽然它不对应真实世界时间，但差值就是精确的相对耗时（精度通常在 10–100 纳秒量级）。
示例写法：
long start = System.nanoTime(); // 你的业务代码 doSomething(); long end = System.nanoTime(); long costNs = end - start; long costMs = costNs / 1_000_000;
- 注意：不要用
System.nanoTime()做时间戳存储或比较绝对时间 - 避免在循环内高频调用（有微小开销），但一般业务代码里一次 start/end 完全没问题
- 某些老旧 JVM（如 Java 6 早期版本）在 Windows 上可能存在计时器抖动，但现代 JDK（8u202+ / 11+）已基本稳定
生产环境该用什么——别手写计时逻辑
真实业务中，手动插桩 System.nanoTime() 易遗漏、难维护、侵入性强。应该交由成熟工具链处理：
- Web 层统一用 Spring AOP 或 Servlet Filter 包裹请求，记录
System.nanoTime()差值 - RPC 调用走 Dubbo/Spring Cloud 的 Filter/Interceptor，自带耗时统计字段
- 异步任务用线程池包装器（如
ThreadPoolTaskExecutor的beforeExecute/afterExecute） - 需要分布式的，必须结合 OpenTelemetry 或 SkyWalking，靠 traceId 关联各段
System.nanoTime()时间戳
真正容易被忽略的是：耗时统计本身也有开销，尤其在 QPS 极高（>10k/s）且逻辑极轻（如纯内存 map 查找）的场景下，计时操作可能成为瓶颈。这时候得权衡是否采样（如每 100 次记录 1 次），而不是无脑全量埋点。
