System.nanoTime() 是 Java 中唯一适合高精度性能度量的原生工具，它只用于同一 JVM 内计算时间差，必须紧贴业务逻辑边界精准包裹目标代码段（如数据库查询、JSON 反序列化），排除调度、I/O、GC 等干扰；测量前需预热，避免日志、对象创建等额外开销，并合理换算单位与封装计时逻辑。
System.nanoTime() 是 Java 中唯一适合高精度性能度量的原生工具，它不提供绝对时间，只用于计算同一 JVM 内的时间差。真正决定测量是否有效，不是调用它本身，而是你把它“扣”在哪儿——必须紧贴真实业务逻辑的边界，排除调度、I/O、GC 等非计算开销。
精准包裹目标代码段
耗时测量失真的最常见原因，是把 nanoTime() 放在 run() 方法头尾，结果测的是整个线程生命周期，而非业务本身。
- ✅ 正确做法：start 和 end 必须严格夹住你要评估的那段逻辑，比如一次数据库查询、一个 JSON 反序列化、一段排序算法
- ❌ 错误写法：在 Runnable.run() 开头记 start，结尾记 end，中间混入日志打印、参数校验、锁等待等非核心操作
- 示例中 doBusinessWork() 才是被测主体，它的前后才是 nanoTime() 的合理位置
避开干扰源，还原纯计算耗时
纳秒级数值再准，若被外部因素污染，就失去了性能分析意义。关键不是“能不能测”，而是“测到的到底是什么”。
- 网络请求、磁盘读写、synchronized 阻塞、Thread.sleep() —— 这些属于等待耗时，不应计入算法或 CPU 密集型逻辑的性能评估
- JIT 编译和类加载仅发生在首次执行，建议预热（如空跑 100–1000 次）后再采集有效样本
- 避免在测量块内创建对象、拼接字符串或触发日志输出，这些可能引发 GC 或额外开销
单位换算与结果表达要清晰
nanoTime() 返回值单位是纳秒，但直接展示纳秒易读性差；转换需兼顾精度与用途，不盲目截断。
立即学习“Java免费学习笔记（深入）”；
- 转微秒：除以 1000（ns / 1000 → μs），适合算法微基准测试
- 转毫秒：除以 1_000_000（ns / 1_000_000 → ms），适合接口响应、业务流程统计
- 如需保留小数精度，用 double 运算：costNs / 1_000_000.0；如只需整数毫秒，可用 Math.round() 四舍五入
封装计时逻辑提升可维护性
重复手写 start/end 容易漏掉 end 或错位，简单封装能减少出错概率，也便于统一处理统计逻辑。
- 用 try-with-resources 自动管理：定义 NanoTimer 实现 AutoCloseable，在 close() 中自动记录耗时并可选打点
- 批量压测时，建议保留原始纳秒值入库，后续按需转换单位，避免多次浮点运算引入误差
- 对关键路径，可结合 ThreadLocal 存储耗时数组，做 P95/P99 分位统计，比平均值更能反映真实延迟分布
