system.nanotime()是java中唯一可靠支撑微秒级测量的工具，它返回纳秒级单调递增差值，需除以1000换算为微秒；实际分辨率通常为10–50纳秒，单次测量小于100纳秒多属噪声，稳定结果需批量执行取中位数或p50，并规避jit、gc及调度干扰。
System.nanoTime() 是 Java 中唯一能可靠支撑微秒级任务测量的计时工具，但它本身不“直接表现”为微秒——它的价值在于提供高分辨率、单调递增的纳秒差值，再经合理换算与使用，才能真实反映微秒级行为。
它能测出微秒级差异，但不是所有微秒都可信
底层实际分辨率通常在 10–50 纳秒（Linux 常见 10 ns，Windows 可能 100 ns），这意味着：
- 小于 100 纳秒（即 0.1 微秒）的单次测量，大概率是噪声，而非真实执行耗时；
- 1234 纳秒的差值，可合理表达为 ≈1.23 微秒，但若只测一次，结果可能在 1200–1300 ns 间抖动；
- 真正稳定的微秒级判断，需靠批量执行（如 10⁴–10⁶ 次）摊平抖动，再取均值或中位数。
微秒级任务测量必须绕开三大干扰源
哪怕代码本身只花 2 微秒，计时结果也可能严重失真，除非主动规避：
- JIT 编译干扰：首次运行含类加载、方法编译开销，应预热足够轮次（建议 ≥5 万次空调用）；
- 计时器自身开销：每次 nanoTime() 调用约 10–30 纳秒，若目标操作仅 50 纳秒，开销占比超 20%，必须用“总耗时 ÷ 次数”方式稀释；
- 调度与 GC 污染：线程被抢占、Minor GC 触发都会把无关延迟计入结果，压测时需开启 GC 日志并剔除 P99.9 以上离群值。
微秒级输出怎么写才不丢精度
纳秒差值转微秒，写法直接影响数据可信度：
- 整数截断（durationNs / 1000）：适合日志打点或阈值判断（如“是否 ≤ 5μs”），但系统性低估，1999ns → 1μs；
- 四舍五入（Math.round(durationNs / 1000.0)）：更符合工程直觉，1999ns → 2μs，统计偏差小；
- 浮点保留（durationNs / 1000.0）：用于性能分析、绘图或计算分位数，不丢失原始信息，推荐作为原始样本存储。
比“能测”更重要的是“怎么信”
微秒级任务的真实耗时，往往藏在统计分布里，而非单个数字中：
- 平均值易被尖峰拉高，优先用中位数或 P50；
- 关注 P90/P99 延迟，它们暴露缓存未命中、锁竞争等真实瓶颈；
- 同一台机器上对比 A/B 版本时，确保各自完成独立预热，避免共享状态（如 CPU cache、JIT profile）造成伪加速。
