system.currenttimemillis()适合粗略估算整体耗时，单位毫秒，但受系统时间调整和线程阻塞影响，精度低且不单调；应使用long类型、try-finally包裹、避免测微秒级耗时，推荐system.nanotime()等更精准方案。

用 System.currentTimeMillis() 计算程序运行总耗时，操作简单但容易踩坑。它适合粗略估算整体耗时（比如接口响应、批处理任务完成时间），不适合测毫秒级以下的代码段或做性能压测。

基本写法：两行取差，单位是毫秒

核心就是执行前记一次，执行后记一次，相减得到耗时（单位毫秒）：

• long start = System.currentTimeMillis();
• 你的业务逻辑（如调用服务、读文件、循环计算）
• long end = System.currentTimeMillis();
• long elapsedMs = end - start; —— 注意是 end 减 start，不是反过来

必须注意的几个关键点

看似简单，但这些细节直接影响结果是否可信：

Clickable

一款利用 AI 快速生成数字广告素材的在线创作工具，可根据产品和营销需求制作视觉与文案方案，帮助企业提高广告创意生产速度。

下载

• 变量类型必须用 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，避免手动插桩