system.nanotime() 本身不能防止 jit 优化空循环，真正有效的是让循环产生逃逸的、必须保留的计算结果；jit 会移除无副作用的空循环，导致测得时间为 0；正确做法是累加并显式使用结果，如 long result = 0; for(...) result += i; 后续输出或返回 result。
用 System.nanoTime() 本身不能防范 JIT 对空循环的擦除优化——它只是个高精度计时工具，不参与编译控制。真正起作用的是**如何组织循环逻辑**，让 JIT 无法判定循环体无副作用，从而放弃优化。关键在于：让循环产生一个“逃逸”的、必须保留的计算结果。
为什么空循环会被JIT优化掉
JIT 编译器（尤其是 C2）在识别到循环体内没有任何可观察行为（如变量修改、I/O、内存写入、方法调用）时，会直接将整个循环移除，甚至把循环变量和条件判断一并消除。此时用 nanoTime() 测得的时间接近 0，不代表真实执行耗时，而是优化后的结果。
用nanoTime配合防优化的正确姿势
核心原则：让循环的计算结果被后续代码“使用”，且该使用不能被 JIT 静态推断为无用。常见可靠做法包括：
-
累加一个局部变量，并在循环后输出或返回它：例如
long sum = 0; for (int i = 0; i ，最后打印 <code>sum或赋值给volatile字段 -
写入 volatile 变量：声明
private static volatile long sink;，循环中执行sink = i;（最后一次赋值即可，JIT 不敢删） -
作为方法返回值参与外部逻辑：把循环封装成方法，返回计算结果，并在 main 中用它做一次简单判断（如
if (result > 0) System.out.println("done");） -
避免仅靠 nanoTime 差值“隐式使用”：仅用
end - start计算耗时，但未将该差值用于任何分支或输出，JIT 仍可能优化掉整个循环
典型防优化测试模板
以下代码能稳定阻止 JIT 擦除（经 JMH 和 -XX:+PrintCompilation 验证）：
long result = 0;
for (int i = 0; i result ^= i * 31; // 使用异或+乘法，避免简单累加被向量化优化
}
long end = System.nanoTime();
System.out.println("Result: " + result + ", Time: " + (end - start) + " ns");
额外保障：预热与JVM参数
单次测量不可靠。建议补充：
- 先执行 1~10 万次相同循环（预热），触发 JIT 编译
- 运行时添加
-XX:+UnlockDiagnosticVMOptions -XX:+PrintCompilation，确认循环所在方法已编译（非 interpreted） - 禁用分层编译（
-XX:-TieredStopAtLevel1）可减少 C1/C2 切换干扰，适合精细对比
