system.nanotime()测延迟需规避调度延迟、tsc偏差、gc干扰等隐性误差：计时点须紧贴业务逻辑，跨线程比对需统一协调，禁用其作时间戳或跨jvm传输。
在多线程环境下用 System.nanoTime() 测量任务延迟，不是“调用两次取差值”那么简单。真正影响结果可信度的，是线程调度、JVM行为和硬件底层的一系列隐性干扰。
计时起点不等于执行起点
你写 long start = System.nanoTime(); doWork(); long end = System.nanoTime();，但 doWork() 实际开始执行的时间，可能远晚于 start 记录时刻——尤其当线程刚被唤醒、或刚从阻塞态恢复时，存在不可忽略的调度延迟。这个延迟会被错误计入“任务耗时”。
- 避免在临界区外直接计时：若
doWork()前需获取锁、等待信号量或从队列取任务，应把start放在真正业务逻辑入口处，而非方法最外层 - 对关键路径做“紧邻计时”：
start和end应尽可能贴近待测代码，中间不穿插日志、条件判断等非目标操作 - 考虑用
Thread.onSpinWait()或 volatile 读辅助对齐（适用于极短操作，防止编译器过度优化掉空循环）
跨线程/跨核时间不可比
System.nanoTime() 在单个 JVM 内单调，但不同线程调用它，返回值未必能精确对齐——尤其在线程迁移到不同 CPU 核心时，TSC（时间戳计数器）同步可能存在微小偏差（纳秒级），导致测量出的“并发延迟”失真。
- 若需对比多个线程的响应时间（如请求处理耗时），不要直接比各线程独立记录的
end - start，而应统一由一个协调线程采集时间戳（例如用Phaser或CountDownLatch同步起始点） - 生产环境可绑定线程到固定 CPU 核心（
taskset或 JVM 参数-XX:+UseThreadPriorities配合pthread_setaffinity_np），减少 TSC 不一致风险 - 对延迟敏感服务（如金融行情推送），建议用
CLOCK_MONOTONIC_RAW（Linux）替代默认 TSC，绕过频率缩放干扰
GC 和线程抢占会污染结果
一次 Full GC 可暂停所有应用线程数百毫秒，而 nanoTime() 照常走时——这时测出的“耗时”其实是 GC 时间 + 业务时间，完全失真。同样，高优先级线程抢占、中断处理、页缺失等也会叠加进测量值。
- 压测期间开启
-XX:+PrintGCDetails，确认无 GC 发生；或使用 ZGC/Shenandoah 等低停顿收集器 - 统计时剔除明显离群值（如 P99.9 以上），或改用环形缓冲区 + 滑动窗口直方图（Histogram），自动过滤尖峰
- 避免在
finally块中做耗时操作（如远程上报），否则会拉长end时间，放大误差
别把 nanoTime 当时间戳用
System.nanoTime() 返回的是相对偏移量，不是真实时间。它不能用于排序日志、生成 ID、计算超时截止点，也不跨 JVM 可比。
- 需要“带时间语义的耗时”，应同时记录：
System.currentTimeMillis()（用于对齐、排序） +System.nanoTime()（用于精确差值） - 超时控制务必用
Lock.tryLock(timeout, unit)、Future.get(timeout, unit)等封装好的 API，它们内部已正确处理nanoTime()与系统时钟的关系 - 禁止将
nanoTime()值存入数据库或网络传输——它在另一台机器上毫无意义
