system.nanotime()仅提供高精度时间差，关键路径耗时分析需精准打点、预热采样、抗干扰聚合及合理单位换算。
System.nanoTime() 本身不分析耗时，它只提供高精度时间差；真正“分析关键路径耗时”，靠的是你如何用它包裹代码、控制变量、过滤噪声、聚合数据。
必须紧贴业务逻辑边界打点
关键路径不是整个方法，而是其中真正影响性能的子环节——比如一次数据库查询、一段 JSON 反序列化、一个核心算法计算。start 和 end 必须严格夹住这部分，不能放在 Runnable.run() 头尾或 Controller 方法入口出口。
- ✅ 正确：在 doDbQuery() 前后调用 nanoTime()
- ❌ 错误：在 service 方法开头记 start，结尾记 end，中间混入日志、参数校验、锁等待
- 避免在测量块内创建对象、拼字符串、打日志——这些可能触发 GC 或额外开销
预热 + 多轮批量采样，绕过 JIT 干扰
JVM 首次执行会经历类加载、解释执行、JIT 编译，前几次耗时远高于稳定态。不预热就测，A 路径测的是“冷启动+编译”，B 路径测的是“已优化”，对比完全失真。
- 先空跑目标逻辑至少 10,000 次，确保 C2 编译完成
- 正式测量每轮执行 1,000–10,000 次目标逻辑（摊薄计时器开销占比）
- 每轮记录总纳秒耗时，再除以次数得单次均值；最终取所有轮次均值的中位数（比平均值抗 GC/中断毛刺）
生产环境要识别并标记污染样本
在真实服务中，nanoTime 差值可能被 GC 暂停、线程抢占、CPU 频率跳变等污染。直接取平均会严重失真。
- 每次 flush 前检查 GarbageCollectorMXBeans，若 collectionCount 变化，整批样本标记为 gc-contaminated
- 用 ThreadLocal
做无锁环形缓冲（建议 4096 元素），索引用 AtomicInteger 自增取模 - 聚合时不依赖简单均值，改用截尾均值（trim mean）：去掉最高 5% 和最低 5% 样本，再求平均
- P99/P999 等长尾指标必须走独立直方图路径，不能从均值推导
单位换算与输出要兼顾精度和可读性
nanos 是原始单位，但直接展示纳秒易读性差；换算需按场景选策略，且注意整数截断风险。
- 微基准测试（如算法）→ 除以 1000 得微秒（μs），保留整数或一位小数
- 接口级监控 → 除以 1_000_000.0 得毫秒（ms），用 double 运算避免整数截断
- 不要把 nanoTime() 绝对值当时间戳用，也不和 currentTimeMillis() 混用或相减
- 原始 nanos 值应原样存入缓冲区，单位转换留到聚合层统一处理
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
