System.currentTimeMillis()适合粗略计时，精度约10–15毫秒，返回自1970年1月1日UTC起的毫秒数，用法为前后调用取差值，单位毫秒。
用 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？
当你要：
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 测低于 1 毫秒的操作（如方法调用开销、小数组排序）
- 做性能基准测试（JMH 就默认用
nanoTime） - 需要单调递增、不受系统时间修改影响（比如管理员手动调了系统时间，
currentTimeMillis可能倒退，nanoTime不会）
换成它只需改两处：long start = System.nanoTime();long end = System.nanoTime();
注意结果单位是纳秒，除以 1_000_000 得毫秒，除以 1000 得微秒。
一个小技巧：封装成工具方法
重复写 start/end 太啰嗦，可以写个简单工具：
立即学习“Java免费学习笔记（深入）”；
public static long time(Runnable task) {
long s = System.currentTimeMillis();
task.run();
return System.currentTimeMillis() - s;
}
用法：long ms = time(() -> doSomething());
适合快速验证，但注意 Lambda 本身有微量开销，不影响大局。
