可行但需多次采样、排除干扰、合理统计，因单次测量受JVM预热、JIT、GC、CPU波动等影响偏差大，应预热后多轮循环测总耗时再均值化并清洗极值。
用 System.nanoTime() 做高频函数的微秒级基准测试是可行的，但必须规避常见陷阱——它本身精度高（纳秒级），但不代表单次调用测量就准确。关键在于**多次采样、排除干扰、合理统计**，而非直接拿两次 nanoTime 相减就当结果。
为什么不能只测一次调用？
System.nanoTime() 返回的是单调递增的纳秒时间戳，不受系统时钟调整影响，适合测间隔。但单次函数执行可能被 JVM 预热不足、JIT 尚未优化、GC 干扰、CPU 频率波动或上下文切换打断，导致结果偏差极大（比如某次多出 5000 纳秒）。微秒级（1 微秒 = 1000 纳秒）目标下，单次误差可能高达数微秒甚至更多。
正确做法：预热 + 多轮循环 + 统计清洗
以测试一个简单加法函数为例：
- 先预热 JVM：让方法被 JIT 编译（通常执行 1~10 万次空跑，具体看方法复杂度）；
- 用大循环包裹待测逻辑：例如 100 万次调用，测总耗时再除以次数，大幅摊平单次抖动；
- 分多组独立运行（如 10~30 组），每组测一次总耗时，得到多个“百万次耗时”样本；
- 剔除首尾各 10% 极值（或用中位数），避免 GC 或调度尖峰污染；
- 最终结果用中位数（单位：纳秒/次），再除以 1000 得到微秒/次。
代码结构示例（精简版）
不依赖 JMH，纯 JDK 可行：
// 预热 for (int i = 0; i // 多组采样 long[] samples = new long[20]; for (int r = 0; r
还要注意这些细节
-
禁用 CPU 节能模式（如 Linux 的
cpupower frequency-set -g performance），防止频率动态降频拉长耗时； - 避免在测量循环内创建对象，否则触发 Young GC 会严重污染数据；
- 确保待测函数无副作用且可被 JIT 优化掉——若返回值未被使用，JIT 可能整个删掉逻辑（加个 volatile 写入或累加到全局变量可阻止）；
-
Linux 下可用
taskset -c 0 java ...绑定单核，减少跨核迁移开销。
