system.nanotime()是性能评估起点，因其提供单调、高分辨率、不受系统时钟影响的纳秒差值；但必须配合预热、多轮采样、中位数统计及gc干扰剔除等流程，才能真实反映代码开销。
用 System.nanoTime() 做基准测试，核心不是“能测纳秒”，而是如何让测出来的数字真正反映代码本身的开销。它本身不解决预热、干扰、统计偏差等问题——这些全靠你设计测量流程。
为什么 nanoTime 是性能评估的起点
它提供单调、高分辨率、不受系统时钟调整影响的时间差值，这是其他 API（比如 currentTimeMillis()）做不到的。毫秒级计时在测微秒级操作时，大量结果会坍缩成 0 或 1 毫秒，完全失去区分度。
- 返回值无物理意义，只用于相减：不要打印、存储或跨 JVM 比较单个 nanoTime 值
- 底层通常基于
CLOCK_MONOTONIC，Linux/macOS 下分辨率多在 10–100 纳秒之间 - 调用开销极小（约 20–50 纳秒），远低于一次日志输出或对象分配
必须做的三步预热与采样
不预热就测，等于把 JIT 编译、类加载、分支预测初始化的开销一起算进结果里。
- 先空跑目标方法 10,000–100,000 次，确保其被 C2 编译器优化并稳定执行
- 正式测量分至少 20 轮，每轮执行 1,000–100,000 次目标逻辑（次数要让总耗时明显大于计时器误差）
- 每轮记录总纳秒数，除以次数得该轮“平均单次耗时”，再对所有轮次取中位数——比平均值更能抵抗 GC 尖峰或调度抖动
对比算法时最常踩的坑
两个方法看似独立，实则容易互相污染。
- 共享对象状态：比如共用同一个
ArrayList，前一个方法触发的扩容或缓存预热会让后一个明显变快。应为每次测量新建干净实例 - JIT 状态不对等：A 方法已编译优化，B 还在解释执行。必须让 A 和 B 各自完成完整预热，再进入正式轮次
- 测量粒度失配：若 A 耗时约 30ns、B 约 200ns，但只测单次，nanoTime 分辨率 40ns 就会导致 A 大量报 0/40ns，B 报 200±20ns——直接比均值会严重低估 A 的优势。提高每轮执行次数可摊平这种抖动
生产环境或高频压测的延伸要点
单纯调用 nanoTime 不足以支撑可靠监控，需配合轻量工程机制。
- 用
ThreadLocal<long></long>+ 原子索引实现无锁环形缓冲区，避免频繁对象分配和锁竞争 - 直方图分桶必须用原始纳秒值，别提前转毫秒——整数截断会错判区间，且除法本身有 CPU 开销
- 开启 GC 日志并关联采集：STW 期间 nanoTime 照常走，但业务暂停。若某段时间耗时突增且 GC 次数同步上升，大概率是 GC 干扰而非代码变慢
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
