直接对System.nanoTime()差值取算术平均是错的，因其无法抑制JIT编译、STW GC和计时器开销等噪声，易被异常值扭曲结果；应采用截尾均值、批量调用+单次计时、GC污染标记等抗干扰统计方法。
System.nanoTime() 本身不提供统计能力，JMH 已经内置了完整的预热、采样、异常值剔除和置信区间计算——手写均值平均只会让结果更不可靠。
为什么直接对 System.nanoTime() 差值取算术平均是错的
微基准测试的核心不是“测一次再除以次数”，而是控制变量、压制噪声、识别 JIT 和 GC 干扰。手写循环 + System.nanoTime() + 算术平均会放大三类偏差：
- 单次
System.nanoTime()调用开销约 20–50ns，在测量亚微秒级方法时，其占比可能超 50%，导致大量样本为 0 或离散毛刺 - 算术平均对异常值极度敏感：一次 STW GC（300ms）混入 1000 次采样，会把 P99 拉高两个数量级，而你根本看不出哪次被污染
- JIT 编译过程本身有阶段性（C1 → C2 → OSR → 逆优化），不同轮次执行路径不同，强行平均等于把汇编指令、字节码、解释执行全揉在一起算“平均速度”
JMH 怎么用 System.nanoTime() 却不暴露给你
JMH 不是“封装了 System.nanoTime()”，而是把它嵌入一套受控执行框架中。关键设计点包括：
- 每个 fork JVM 实例独立运行，避免跨测试污染；每轮 fork 前强制触发 GC，减少内存压力干扰
- 预热阶段执行数万次，同时监听
HotSpotDiagnosticMXBean确认 C2 编译完成，才进入正式测量 - 正式测量分 multiple iterations，每次 iteration 内部执行 thousands of invocations，并用
System.nanoTime()包裹整个 iteration —— 不是单次调用，规避调用开销占比问题 - 最终上报的是每个 iteration 的吞吐量（ops/time）或平均耗时，JMH 自动剔除前 10% 和后 10% 的 iteration，再对剩余 iteration 的均值做 Student’s t-test 计算置信区间
如果你非得手写，至少避开这三个坑
不用 JMH 的真实场景往往受限于环境（如生产容器无额外依赖、安全策略禁用 fork）。此时必须放弃“取平均”，改用抗干扰更强的统计逻辑：
- 拒绝
(sum / count)：改用截尾均值（trimmed mean），例如去掉最高 5% 和最低 5% 的 iteration 耗时，再求均值 - 拒绝单次
System.nanoTime()包裹目标方法：改为每轮 iteration 执行 1000+ 次目标方法，只在 iteration 前后各调一次System.nanoTime()，再除以次数 - 必须同步采集 GC 状态：用
ManagementFactory.getGarbageCollectorMXBeans()在 iteration 前后比对getCollectionCount()，若变化则整轮标记为无效，不参与统计
真正难的从来不是拿到纳秒数字，而是判断哪个数字该信、哪个该扔。JMH 的价值不在计时器，而在它知道什么时候该停表、什么时候该重跑、以及哪次结果该进垃圾桶。
