System.nanoTime()是Java中唯一支持微秒级性能测试的计时工具，需配合预热JVM、批量测量摊平噪声、多轮采样取中位数三步才能获得真实抗干扰结果。
System.nanoTime() 是 Java 中唯一能支撑微秒级性能测试的计时工具，它不提供“当前时间”，只提供高精度、单调递增的纳秒差值——这正是微秒级测量所需的全部条件。关键不在调用本身，而在于如何用它测出真实、可比、抗干扰的耗时数据。
微秒级测量必须做三件事
只写两行 nanoTime 调用远远不够。真实压测中，以下三点缺一不可：
- 预热 JVM：让目标方法被 JIT 编译优化，避免把类加载、解释执行、分支预测初始化等开销混进结果。建议空跑 1–10 万次（视方法复杂度而定）
- 批量测量 + 摊平噪声：单次 nanoTime 调用开销约 20–50 纳秒，若测一个 30ns 的操作，结果会严重失真。应每轮执行 1000–100000 次，只记一次总耗时，再除以次数
- 多轮采样 + 剔除异常值：至少运行 20–30 轮独立测量，每轮得一个“平均单次耗时”；丢弃首尾各 10% 极值，或直接取中位数——比平均值更能抵抗 GC 暂停、CPU 频率切换等瞬态干扰
单位换算：别让整数除法偷走精度
System.nanoTime() 返回纳秒值，但“微秒”不是简单除以 1000 就完事：
- 用 durationNs / 1000 → 得 long，向下截断（1999ns → 1μs），系统性低估
- 用 Math.round(durationNs / 1000.0) → 四舍五入，适合日志和阈值判断
- 用 durationNs / 1000.0 → double，保留全部小数位，是绘图、分位数统计、P95/P99 计算的唯一可靠输入
注意：除以 1000.0（double）而非 1000（int），否则 Java 自动做整数除法，永远丢小数。
立即学习“Java免费学习笔记（深入）”；
对比算法时最易踩的坑
两个方法 A 和 B 的耗时不能各自跑一遍就比数字——环境变量稍有偏差，结论即失效：
- JIT 状态不同步：A 已被 C2 编译，B 还在解释执行。必须让 A 和 B 各自完成完整预热（非共用一轮），再进入正式测量
- 共享状态污染：共用同一个 ArrayList 或缓存，A 触发的 CPU cache 预热或对象晋升会让 B 显著变快。每次测量前应重建干净实例
- 测量粒度失配：若 A 实际 25ns、B 实际 180ns，而 nanoTime 分辨率约 40ns，单次测量会让 A 大量报 0/40ns、B 报 160–200ns——直接比均值会严重扭曲优势比。提高每轮执行次数可有效摊平
生产监控中的轻量实践
在高频服务中嵌入 nanoTime 不等于堆日志：
- 用 ThreadLocal
+ 原子索引实现环形缓冲区，避免频繁 new 对象触发 Young GC - 直方图分桶始终用原始纳秒值（如 Micrometer Timer），别提前转毫秒——整数截断会错判区间，且除法本身消耗 CPU
- 关联 GC 日志：STW 期间 nanoTime 照常走，但业务暂停。若某时段耗时突增且 Full GC 同步发生，大概率是 GC 干扰，而非代码退化
