System.nanoTime()仅提供单调递增纳秒值，适合测间隔而非时间戳；其差值为0因分辨率低、JIT优化或调用开销大；不可与currentTimeMillis()混用；微基准测试需预热、避GC、保内联、多次测量。
System.nanoTime() 本身不提供“绝对时间”，它只返回一个单调递增的纳秒级计时值，适合测间隔，不适合做时间戳。它的精度和稳定性取决于底层操作系统与硬件，不是所有平台都能真正达到纳秒级分辨率。
为什么 System.nanoTime() 测出来的时间差有时为 0
常见现象：连续两次调用 System.nanoTime() 相减得 0，尤其在空循环或极短操作中。
- 底层计时器分辨率有限（如 Windows 上常为 10–15ms，Linux 可能是 1–10ns，但受 CPU 频率调节、虚拟化影响）
- JIT 编译可能优化掉“无副作用”的代码段，导致实际没执行
- 单次调用开销本身就可能接近或超过计时器最小可分辨间隔
- 建议至少重复测量 100 次以上取平均，并用
Thread.onSpinWait()或简单 volatile 读写防止过度优化
System.nanoTime() 和 System.currentTimeMillis() 能否混用
绝对不能。两者基准不同、更新机制不同、用途完全不同。
-
System.currentTimeMillis()返回自 1970-01-01 UTC 的毫秒数，受系统时钟调整（NTP、手动修改）影响，可能回跳或跳跃 -
System.nanoTime()基于某个未公开起点（如 JVM 启动时刻），只保证单调性，不映射到真实时间 - 拿
System.nanoTime()减去一个System.currentTimeMillis()值毫无意义，结果单位错乱且语义失效 - 日志打点若需“带时间戳的耗时”，应分别记录
System.currentTimeMillis()（用于排序/对齐）和System.nanoTime()（用于精确差值）
在微基准测试中如何避免 System.nanoTime() 的典型误用
JMH 是首选，但若手写简易 benchmark，必须绕过几个关键陷阱：
