Java耗时测量：currentTimeMillis使用技巧

本文深入讲解了Java中使用System.currentTimeMillis()进行代码耗时测量的实用技巧，强调其简单高效、适合粗略计时（如调试对比或宏观性能观察）的优势，同时明确指出其约10–15毫秒的精度限制及常见误用陷阱——如测量过短操作易得零值、单次测量受JVM预热和系统调度干扰、跨线程差值包含等待时间等；并自然引出更高精度替代方案System.nanoTime()的适用场景与转换方法，最后还提供了简洁的工具方法封装建议，帮助开发者快速、可靠地完成日常性能评估。

用 System.currentTimeMillis() 测量代码块执行时间，简单直接，适合粗略计时，比如调试、对比不同写法的快慢。它返回的是自 1970 年 1 月 1 日 00:00:00 UTC 起的毫秒数，精度约 10–15 毫秒（取决于系统），不适合测微秒级或高精度场景。

基本用法：两行搞定

在代码块前后各调一次 currentTimeMillis()，相减即得耗时（单位：毫秒）：

// 示例：测量一个循环的执行时间
long start = System.currentTimeMillis();
for (int i = 0; i   // 你的代码
}
long end = System.currentTimeMillis();
System.out.println("耗时：" + (end - start) + " ms");

注意这几点，结果才靠谱

• 别测太短的代码：如果执行快于系统时钟精度（比如几微秒），可能得到 0，不代表没耗时，只是测不出来
• 避免单次测量：JVM 预热、GC、系统调度都会干扰。建议循环多次取平均，或用 System.nanoTime() 替代（更准）
• 别跨线程直接相减：不同线程中获取的时间戳没问题，但若线程被挂起、休眠或调度延迟，差值会包含等待时间，不是纯执行时间
• 不用 try-finally 包裹也行：因为是纯数值计算，无资源释放问题；但若代码可能抛异常且你仍想统计耗时，加 try-finally 更稳妥

什么时候该换 nanoTime？

当你要：

• 测低于 1 毫秒的操作（如方法调用开销、小数组排序）
• 做性能基准测试（JMH 就默认用 nanoTime）
• 需要单调递增、不受系统时间修改影响（比如管理员手动调了系统时间，currentTimeMillis 可能倒退，nanoTime 不会）

换成它只需改两处：
long start = System.nanoTime();
long end = System.nanoTime();
注意结果单位是纳秒，除以 1_000_000 得毫秒，除以 1000 得微秒。

一个小技巧：封装成工具方法

重复写 start/end 太啰嗦，可以写个简单工具：

public static long time(Runnable task) {
  long s = System.currentTimeMillis();
  task.run();
  return System.currentTimeMillis() - s;
}
用法：
long ms = time(() -> doSomething());
适合快速验证，但注意 Lambda 本身有微量开销，不影响大局。

到这里，我们也就讲完了《Java耗时测量：currentTimeMillis使用技巧》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！