System.currentTimeMillis()适合粗略估算整体耗时，单位毫秒，但受系统时间调整和线程阻塞影响，精度低且不单调；应使用long类型、try-finally包裹、避免测微秒级耗时，推荐System.nanoTime()等更精准方案。
用 System.currentTimeMillis() 计算程序运行总耗时，操作简单但容易踩坑。它适合粗略估算整体耗时（比如接口响应、批处理任务完成时间），不适合测毫秒级以下的代码段或做性能压测。
基本写法：两行取差，单位是毫秒
核心就是执行前记一次，执行后记一次，相减得到耗时（单位毫秒）：
long start = System.currentTimeMillis();- 你的业务逻辑（如调用服务、读文件、循环计算）
long end = System.currentTimeMillis();-
long elapsedMs = end - start;—— 注意是 end 减 start，不是反过来
必须注意的几个关键点
看似简单，但这些细节直接影响结果是否可信：
- 变量类型必须用
long，别用int：跨天或长时间运行会溢出（int最大约 24.8 天就翻转） - 起始时间要放在真正业务逻辑开始前，比如参数校验之后、主流程之前，而不是方法一进来就记
- 结束时间要覆盖所有执行路径：如果代码可能抛异常，建议用
try-finally包裹，确保end一定被记录 - 别指望它测出“几微秒”的耗时：系统精度通常为 1–15ms，短于这个值很可能返回 0
它为什么不准？什么情况下别用
System.currentTimeMillis() 返回的是“墙上时间”，不是 CPU 执行时间。这意味着：
- 受 NTP 校时、手动改系统时间影响，可能出现 倒退（负数）或跳变
- 线程被挂起、GC 暂停、I/O 等待都会计入耗时，结果远大于真实执行时间
- 不适合用于：性能压测、SLA 判断、熔断阈值、算法对比、分布式链路子段计时
更准的替代方案推荐
真需要可靠耗时数据，优先考虑这些：
-
System.nanoTime()：纳秒级、单调递增、不受系统时钟调整影响，专为测量间隔设计。用法类似，只是单位是纳秒（除以1_000_000得毫秒） -
Spring 的
StopWatch：适合顺序执行的多步骤任务，能分段统计并格式化输出，减少手写重复代码 - 生产环境交由工具链：Web 层用 Filter/AOP、RPC 用 Interceptor、分布式用 OpenTelemetry，避免手动插桩
