Java代码测速：System.nanoTime实现高精度的时间追踪

在Ja va世界里做代码性能测试，System.nanoTime()绝对算得上是标配，也是获取高精度时间差最可靠的方式。它返回的是纳秒级的单调递增时间戳，这个特性很关键——意味着它完全不受系统时钟调整的影响，天然就是为了测量代码执行耗时而设计的。

为什么不用System.currentTimeMillis()？

这是不少开发者刚开始接触性能测试时容易踩的坑。System.currentTimeMillis()返回的是从1970年1月1日算起的毫秒数，精度通常只有10–15毫秒（具体取决于操作系统），更要命的是它可能因为NTP同步或者手动调时发生跳变。一旦跳变，你测得的时间差要么变成负值，要么出现一个完全不合理的大数值，整个测速结果也就废了。

而nanoTime()走的是底层高精度计时器（比如CPU的TSC），实际有效位虽然通常停留在微秒级，但精度上已经远超currentTimeMillis()。更关键的是，它严格单调递增，完全不会因为外部时间同步而“闪回”。说到底，它就是为性能测量量身定做的工具。

正确使用nanoTime()的写法

用法看起来很简单，但细节里藏着不少门道。核心原则其实很清晰：只关心差值，别在意绝对值的含义；起止调用的位置要尽可能贴近待测代码；不要在循环体内部反复调用造成无谓的干扰。

• 记录起点：long start = System.nanoTime();
• 执行目标代码（尽量排除JIT预热、GC等干扰因素）
• 记录终点：long end = System.nanoTime();
• 计算耗时：long elapsed = end - start;（单位是纳秒）
• 如果要换算成毫秒：用(double) elapsed / 1_000_000，注意用double类型转换，避免整数截断把结果吞掉。

常见陷阱与优化建议

说句实在话，单独跑一次，测出来的数据意义其实很有限。JVM预热、上下文切换、GC的发生时机……这些干扰因素随便来一个，就能让单次结果产生剧烈波动。真正的性能分析，必须建立在多次采样和统计的基础上。

• 先做预热：让目标代码运行几十到几百次，给JIT编译留出充分的准备时间。
• 多轮测量：至少独立运行10到100次，然后取平均值或者中位数，会比单次结果靠谱得多。
• 避免污染：测量段内尽量不要创建新对象或触发GC，否则测得的数据反映的不是代码本身的耗时，而是内存管理的开销。
• 调度把戏不靠谱：用Thread.sleep(0)或Thread.yield()想“隔开”测量段，这个想法看起来有理，实际上无法保证线程调度，建议直接放弃。
• 警惕极短操作：如果被测的是类似单个整数加法这种微秒级的操作，JVM可能会做指令重排甚至空循环优化。一个常见的对策是在关键位置加入volatile读写，让优化器知道这里“动不得”。

简单示例：对比两种字符串拼接方式

以下是一个典型对比场景，用来验证两种字符串拼接方式的差异。注意红线：真实的生产级测试应当统一变量生成逻辑，并尽量隔离JIT的影响。如果追求极致可靠性，直接上JMH框架会比手写nanoTime测量稳妥得多。

// 预热
for (int i = 0; i < 1000; i++) {
    String a = "a" + "b"; // 字符串常量折叠，实际开销并不在“+”上
}
// 正式测量
long start = System.nanoTime();
for (int i = 0; i < 10000; i++) {
    String s = "hello" + i;
}
long end = System.nanoTime();
System.out.printf("String concat: %.3f ms%n", (end - start) / 1e6);