system.nanotime()是java中测量算法执行时间最准确的内置工具，因其在单次jvm运行中对相对耗时差值具备高分辨率、强单调性与低干扰性；它基于操作系统单调时钟，不受ntp校时或系统时间跳变影响，但真实分辨率通常为10–100纳秒，单次差值低于100纳秒时多为噪声。
System.nanoTime() 是 Java 中衡量算法执行时间最准确的内置工具，但它的“准确性”不等于“绝对精确”，而是指在单次 JVM 运行中，对**相对耗时差值**的测量具备高分辨率、强单调性与低干扰性——这正是算法性能对比真正需要的。
为什么 nanoTime() 的差值比 currentTimeMillis() 可靠得多
currentTimeMillis() 返回的是系统墙钟时间，受 NTP 校时、手动改时间、闰秒等影响，可能倒流或跳变；毫秒级分辨率在测微秒级操作时经常返回 0 或相同值。nanoTime() 则完全规避这些问题：它基于操作系统单调时钟（如 Linux 的 CLOCK_MONOTONIC），起点虽任意，但两次调用的差值稳定、无漂移、不受外部时间调整干扰。
实际精度受限于硬件和运行环境，不是 Java 层能保证的
nanoTime() 名义上是“纳秒级”，但底层依赖 CPU TSC 或内核计时器，真实分辨率通常为 10–100 纳秒（x86 上常见 20–40 ns）。虚拟机、容器、频率缩放、跨核调度都会引入额外抖动。因此，单次差值低于 100 ns 时，结果大概率是噪声而非真实耗时——这不是 API 的缺陷，而是物理限制。
算法对比中，真正决定准确性的不是计时器本身，而是测量方式
- 必须预热：让目标方法被 JIT 编译、类加载完成、分支预测稳定，否则首次执行包含大量启动开销
- 必须多轮采样：每轮执行足够多次（如 10k 次），再用总耗时除以次数，降低计时器自身开销占比
- 必须隔离干扰：避免 GC、线程抢占、缓存污染；A 和 B 算法需各自独立预热、各自使用全新对象实例
- 必须合理统计：取各轮单次均值的中位数，比平均值更能抵抗毛刺（如某轮恰遇 GC 暂停）
什么情况下 nanoTime() 测出的“算法时间”会严重失真
- 用它测含 I/O、锁竞争、内存分配的操作：这些耗时远超 CPU 计算本身，nanoTime() 测到的是端到端延迟，不是纯算法逻辑成本
- 在循环体内反复调用 nanoTime()：每次调用约 10–50 ns 开销，若算法本身只花 20 ns，测量就完全被污染
- 把不同 JVM 实例、不同机器上的 nanoTime() 值直接比较：它们起点不同、硬件不同，差值不可比
- 未做单位换算就误读数值：(end - start) 是纳秒值，直接当毫秒用会导致结果放大一百万倍
