java算法计时应使用system.nanotime()，因其纳秒级分辨率、不受系统调时干扰、单调递增，而currenttimemillis()毫秒级精度不足且易受时间调整影响。
Java算法计时该用 System.nanoTime()，不是因为它“数字大”，而是它专为测耗时而生：纳秒级分辨率、不受系统调时干扰、单调递增不跳变。毫秒级的 currentTimeMillis() 在测微秒级算法时，经常返回 0 或跳变十几毫秒，根本无法反映真实性能。
为什么 nanoTime 是算法计时的唯一可靠选择
算法优化常聚焦在几十纳秒到几微秒的差异上，比如哈希计算、位运算或小数组排序。这时时间测量本身不能成为噪声源。
-
分辨率碾压：nanoTime 底层通常调用
CLOCK_MONOTONIC（Linux）或QueryPerformanceCounter（Windows），实际分辨率约 10–100 纳秒；而 currentTimeMillis() 在 Windows 上常卡在 15.6ms 阶梯，在 Linux 上也仅 1–4ms - 绝对抗干扰：NTP 校时、管理员改系统时间、闰秒插入……这些会让 currentTimeMillis() 差值突变为负数或失真；nanoTime 完全免疫，只随 CPU 真实流逝推进
- 无语义负担：它不关联日历、时区、夏令时——你不需要“现在几点”，只需要“这段代码跑了多久”
正确测量单次算法耗时的关键操作
直接套一层 nanoTime 就跑一次？结果基本不可信。必须控制 JVM 和硬件层面的干扰。
- 先预热：用目标算法空跑 10,000 次以上，确保 JIT 编译完成、类已加载、分支预测器就绪
- 测量时紧贴逻辑：start 和 end 调用之间不要插日志、对象创建、异常处理等无关代码
- 避免单次测量：单次调用可能被 GC 暂停、线程调度抢占、TLB miss 扭曲。应每轮执行 N 次（如 10,000 次），记录总耗时再除以 N
- 多轮采样取中位数：正式测试至少 30 轮，每轮输出单次均值，最终取这些均值的中位数——比平均值更能抵抗毛刺
对比两个算法时必须隔离的变量
你以为 A 比 B 快 20%，但可能只是 A 提前触发了 CPU 缓存预热，或者 B 的对象恰好分配在老年代免去了 Minor GC。
- 每次测量前重建全部输入数据：ArrayList、数组、Map 等都 new 一个新的，不复用引用
- 让 A 和 B 各自独立预热：不能 A 预热完立刻测 B，B 也要单独跑够万次再进正式轮次
- 控制测量粒度：若 A 单次约 50ns、B 约 200ns，建议每轮执行 ≥50,000 次，使总耗时远超计时器误差（如 >10ms），避免分辨率不足掩盖真实差异
单位转换别踩除法陷阱
得到纳秒差值 durationNs 后，怎么转成更易读的微秒或毫秒？写法不对会悄悄丢精度。
- 要微秒且保留小数：用
durationNs / 1000.0（得 double），不是durationNs / 1000（整数截断） - 做统计分析（P95、直方图）时，全程保留纳秒整数，最后统一转换单位——避免多次除法累积浮点误差
- 注意硬件限制：即使显示 “1234.567μs”，底层分辨率可能只有 15ns，所以小数后两位更多是线性映射，而非真实物理精度
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
