System.nanoTime()跨线程不可直接比对，因TSC同步偏差、线程迁移等导致纳秒级失真；需用Phaser/CyclicBarrier统一采样或协调线程锚定时间，并绑定CPU核心、在业务入口精确计时。
System.nanoTime() 本身不适合直接分析不同线程间的性能表现——它在单线程内可靠，跨线程比对却容易失真。真正能反映“线程间性能差异”的，不是各自记录的 start/end 差值，而是它们在统一时间坐标下的行为对齐关系。
跨线程计时必须用协调机制统一采样点
每个线程调用 System.nanoTime() 返回的数值，受 CPU 核心 TSC 同步偏差、线程迁移、缓存状态等影响，纳秒级差值不可直接对比。例如线程 A 记录耗时 120ns，线程 B 记录 95ns，不代表 B 真的更快——可能只是 B 所在核心的 TSC 偏快 30ns。
- 用 Phaser 或 CyclicBarrier 同步所有线程的“起始时刻”：所有线程到达 barrier 后，再统一执行目标逻辑并开始计时
- 由一个协调线程控制全局时间锚点：协调线程先记下 nanoTime()，再通过 volatile 变量或 LockSupport.unpark() 通知各工作线程，后者以收到信号为起点计时
- 压测中固定线程绑定 CPU：用 taskset（Linux）或 JVM 参数（如 -XX:+UseThreadPriorities 配合亲和性设置）将关键线程锁定到特定核心，减少 TSC 漂移
避免把调度延迟误判为业务耗时
线程从等待态唤醒到真正执行第一条业务代码之间，存在操作系统调度延迟（通常几十微秒）。若你在 Runnable.run() 开头就记 start，这段延迟会被计入“业务耗时”，造成严重高估。
- start 必须放在业务逻辑入口处，而非方法外层。例如：获取锁后、从队列取到任务后、完成参数校验后，再启动计时
- 对极短操作（
- 禁用在计时块内做日志、对象分配、volatile 写等易触发 GC 或内存屏障的操作
多线程延迟分析应聚焦响应分布而非单点均值
不同线程因抢占、GC、中断等原因，响应时间天然呈长尾分布。只看平均值会掩盖毛刺问题；P99、P999 或直方图更能揭示真实稳定性。
立即学习“Java免费学习笔记（深入）”；
- 每轮测量采集数百至数千次样本，用滑动窗口直方图（如HdrHistogram）统计，自动过滤瞬时尖峰
- 开启 -XX:+PrintGCDetails 并关联耗时日志，若某批高延迟样本集中出现在 GC 日志附近，大概率是 STW 导致，非代码问题
- 对比线程池中不同线程的表现时，检查是否出现“个别线程持续偏慢”——可能是该线程长期运行导致 JIT 编译退化，或被绑定到负载更高的 CPU 核心
别混淆“线程执行快慢”和“系统吞吐能力”
多个线程并行执行同一段代码，总耗时变短不等于单线程变快。真正需要分析的是：单位时间内完成的任务数（吞吐）、最慢一次响应（尾部延迟）、线程间结果一致性（如计算是否因指令重排出错）。
- 用 nanoTime() 测单线程吞吐：循环执行 N 次，总耗时除以 N，再换算成 ops/s
- 测并发延迟：统一发起请求 → 各线程处理 → 协调线程收集全部 end 时间戳 → 计算每个响应相对于统一 start 的延迟
- 禁用跨线程共享可变状态：每次测量新建对象实例，防止 cache 预热、TLB 命中等底层优化干扰对比结果
