System.nanoTime()是精准定位微秒级性能瓶颈的测量工具，需结合循环采样、预热、中位数统计及JVM干扰排除才能真实反映代码性能。
System.nanoTime() 本身不优化程序性能，它只是精准暴露性能瓶颈的“显微镜”。真正提升微秒级响应性能，靠的是用它看清问题、验证改动、排除干扰——而不是把它当加速器。
下面从实际出发，说清楚怎么用它推动真实优化：
微秒级耗时必须靠 nanoTime 才能被看见
Java 中多数操作（如简单计算、数组访问、位运算）本身就在几十到几百纳秒量级。currentTimeMillis() 最小单位是毫秒，测出来全是 0 或 1，完全无法区分快慢。只有 nanoTime() 能返回像 12847、39205 这样的纳秒值，换算后是 12.8μs、39.2μs，才具备可比性。
- ✅ 正确做法：
long ns = end - start; double μs = ns / 1000.0; - ❌ 错误写法：
int μs = ns / 1000;（整数截断，1999ns → 1μs，丢失近一半精度）
用 nanoTime 定位真实瓶颈，不是测单次
单次调用 nanoTime() 开销约 20–50 纳秒，而一次 i++ 或 array[i] 可能才 1–5 纳秒。直接包一层测，结果全是计时器噪声。
要让它有用，得这样设计测量逻辑：
- 把目标操作循环执行 10,000 次以上，只测一次总耗时，再除以次数
- 每轮采样独立预热、独立输入（比如每次
new int[1000]，不复用） - 至少跑 20–30 轮，取各轮“平均单次耗时”的中位数，避开 GC 尖峰或调度抖动
例如测哈希计算：
立即学习“Java免费学习笔记（深入）”；
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
volatile int sink;
for (int r = 0; r < 30; r++) {
long totalNs = 0;
for (int i = 0; i < 50_000; i++) {
long s = System.nanoTime();
sink = computeHash(data[i]); // 结果必须被使用
totalNs += System.nanoTime() - s;
}
samples[r] = totalNs / 50_000.0 / 1000.0; // 单次平均微秒
}
double medianUs = median(samples); // 中位数更可靠识别并剔除 JVM 干扰，让数据反映代码本身
测出来的数字偏高，大概率不是算法慢，而是被以下因素污染：
- JIT 未预热：头几次运行包含类加载、方法编译，耗时可能是稳定态的 5–10 倍
- GC 干扰：一次 Young GC 可能暂停几毫秒，让微秒级测量全失效
-
对象分配：哪怕一个
new String()都可能触发内存分配和逃逸分析开销 - 线程切换：多线程环境里，测量块被调度出去再回来，时间就飞了
应对方式很实在：
- 预热阶段空跑目标方法 ≥10,000 次，再进正式测量
- 测量块内禁用日志、不 new 对象、不抛异常、不调外部 API
- 关键变量声明为
volatile（如sink），防止 JIT 把整个计算优化掉 - 单线程运行，Linux 下可用
taskset -c 0绑核，减少跨核迁移
用它验证每一次微小改动是否真有效
微秒级优化常来自细节：
- 把
a % b换成a & (b-1)（当 b 是 2 的幂） - 把
ArrayList.get(i)换成数组直访 - 把分支预测失败的
if-else改成查表或位运算
这些改动可能只省下 5–20 纳秒，没有 nanoTime + 多轮统计，根本看不出差别。而一旦你确认某处改动能稳定降低 15ns，乘以每秒百万次调用，就是 15ms/s 的实打实收益。
不复杂但容易忽略
