不可靠，也不推荐。system.nanotime()虽返回纳秒级时间戳，但单次测量受jit编译、方法内联、cpu调度、gc暂停、死码消除等干扰，结果剧烈波动甚至失真，无法反映真实性能；正确做法是使用jmh进行预热、多轮采样和异常值剔除的基准测试。
用 System.nanoTime() 测量单次方法调用的耗时，**不可靠，也不推荐**。它能返回纳秒级精度的时间戳，但无法反映真实性能——因为 JVM 的即时编译（JIT）、方法内联、CPU 指令重排、缓存预热、GC 干扰等因素，会让单次测量结果剧烈波动，甚至完全失真。
为什么单次 nanoTime 测量没意义
Java 方法首次执行时通常走解释器，后续可能被 JIT 编译优化；nanoTime 本身也有微小开销（几十纳秒），在极短方法（如空方法、简单加法）上占比极高；现代 CPU 的分支预测、流水线、TLB 缓存等都会让同一次调用在不同上下文中耗时差异巨大。
- 测一个空方法，结果可能是 5ns、120ns、甚至 2000ns——全看当时是否触发了 safepoint、是否发生栈替换、是否刚做完 GC
- JIT 还可能把整个调用直接优化掉（dead code elimination），导致测出 0ns
- 操作系统调度、中断、其他进程抢占也会污染单次读数
正确做法：用 JMH 做基准测试
JMH（Java Microbenchmark Harness） 是 Oracle 官方推荐的 Java 微基准测试工具，它通过预热、多轮采样、Fork JVM、统计剔除异常值等方式，消除单次测量的噪声。
- 自动处理预热（warmup），让 JIT 充分编译目标方法
- 在独立的 JVM 进程中运行（@Fork），避免状态污染
- 支持多种模式（吞吐量、平均延时、单次调用时间分布）
- 能识别并警告常见陷阱（如循环无关变量未使用、循环被优化）
如果非要临时用 nanoTime，至少要这样写
仅限调试或粗略观察，**绝不能用于结论性判断**：
- 重复调用足够多次（比如 10 万次），取总耗时再除以次数
- 手动预热：先不计时执行几千次，再开始计时
- 确保被测逻辑不被 JIT 优化掉（例如返回结果并赋值给 volatile 变量，或打印出来）
- 关闭 GC 日志干扰，尽量在无负载机器上运行
替代方案：更轻量但更安全的观察方式
对开发阶段快速验证，可结合以下方式降低误判概率：
- 用 VisualVM 或 JProfiler 抓取方法热点（CPU Profiling），看真实调用占比和平均耗时
- 开启 JVM 参数
-XX:+PrintCompilation确认方法是否已被 JIT 编译 - 用
-XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining查看内联决策 - 对关键路径加日志（带时间戳），在生产环境低频采样（注意日志开销）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
