System.currentTimeMillis()仅在单线程、无阻塞、无时钟干扰、周期较长且仅用于临时排查时可粗略估算任务周期；否则应使用System.nanoTime()、AOP/Filter、OpenTelemetry等更可靠方案。
System.currentTimeMillis() 可以粗略估算任务执行周期，但它反映的是墙钟时间（wall-clock time），不是 CPU 实际执行耗时。它适合单机调试、日志打点、非关键路径的周期观察，但不能用于精度要求高或生产环境的性能统计。
什么时候能用 currentTimeMillis() 看周期
仅在满足以下条件时，它的差值才具备参考意义：
- 任务运行在单线程、无阻塞场景下（比如纯计算、无 I/O、无锁等待）
- 系统未发生 NTP 时间同步、时钟回拨、休眠唤醒等干扰
- 周期本身较长（秒级或以上），毫秒级误差可接受
- 仅用于人工排查或临时验证，不作为 SLA、熔断、告警依据
怎么写才不容易出错
基本写法简单，但容易忽略细节：
- 起始和结束必须在同一方法、同一调用栈中获取，避免被异常跳过或提前 return
- 不要跨线程使用——不同线程里取的时间戳无法准确对应同一段逻辑
- 避免在循环体内部高频调用，否则测量开销本身会干扰结果
- 记录日志时建议同时输出 start 和 end 时间戳，方便后续对齐或排查时钟漂移
更靠谱的替代方案
真正需要可靠周期数据时，应升级工具链：
- 测单段代码间隔：用 System.nanoTime()，它不受系统时钟调整影响，纳秒级单调递增
- Web 请求周期：用 Spring AOP 或 Servlet Filter 统一拦截，自动记录 nanoTime 差值
- 分布式任务周期：必须依赖 OpenTelemetry 或 SkyWalking，靠 traceId 关联各节点耗时
- 定时任务周期（如 Quartz）：直接读取调度器自身上报的触发/完成时间，比手算更可信
一个典型误用场景
比如用 currentTimeMillis() 判断某个异步回调是否超时：
long start = System.currentTimeMillis();
doAsyncTask(() -> {
long cost = System.currentTimeMillis() - start; // ❌ 错！回调可能在另一线程执行，start 值已失效
if (cost > 5000) log.warn("超时");
});
这种写法在多线程下完全不可靠。正确做法是把 start 时间随任务一起传递，或改用 CompletableFuture 的 timeout 机制。
