system.nanotime() 不保证跨核时间同步，仅提供单线程内单调高精度计时；其偏差源于tsc硬件差异，现代系统已缓解但未根除；正确用法限于同线程内测量或配合线程绑定与同步机制。
System.nanoTime() 本身不解决多核时间同步问题，它只是提供一个高精度、单调递增的相对时钟；真正影响跨核时间可比性的，是底层硬件和操作系统对计时源的处理方式。
为什么 nanoTime 在多核下可能“不同步”
System.nanoTime() 通常基于 CPU 的 TSC（Time Stamp Counter）。在早期 x86 系统中，每个核心的 TSC 是独立运行的，起始值和频率可能略有差异。当线程从一个核迁移到另一个核时，两次 nanoTime 调用可能读取不同核心的 TSC，导致差值异常——甚至出现负数。
- 现代 JVM（Java 8u212+）和主流 OS（Linux 2.6.32+、Windows 7+）已默认启用“invariant TSC”或内核级同步机制，大幅缓解该问题
- 但若 BIOS 关闭了 TSC 同步、或运行在老旧虚拟化环境（如某些 KVM 配置），仍可能出现微秒级偏差
- 这种偏差不是 nanoTime 的 bug，而是它忠实地反映了底层硬件时钟的物理现实
关键：nanoTime 只保证单线程内单调，不保证跨线程/跨核对齐
你不能直接拿线程 A 记录的 startA 和线程 B 记录的 endB 做减法来算“跨线程延迟”。因为：
Miller CSV TSV JSON 数据处理器
下载
Miller (mlr) 是一个命令行工具，用于查询、整形和重新格式化名称索引数据，如 CSV、TSV、JSON 和 JSON Lines。它将 awk、sed、cut、join 和 sort 的功能整合到一个专为结构化数据处理而构建的单一工具中。
- A 和 B 可能在不同核上执行，TSC 值不可直接比对
- 线程调度延迟、上下文切换开销会被错误计入测量结果
- 即使两个值都正确，它们的“零点”也不一致（nanoTime 不定义全局起点）
真正可行的应对方式
要让多核环境下的时间测量可信，需配合系统级与应用级协同：
-
绑定线程到固定 CPU 核心：用 Linux 的
taskset或 JVM 参数（如-XX:+UseThreadPriorities配合 cgroups），避免线程迁移 -
统一协调时间采集：用
Phaser或CountDownLatch同步多个线程的起始时刻，由同一个线程调用 nanoTime 记录基准点 -
选用更稳定的时钟源：Linux 下可配置 JVM 使用
CLOCK_MONOTONIC_RAW（通过 JVM 参数或 JNI 封装），绕过 TSC 频率缩放干扰 -
压测时关闭干扰源：禁用动态调频（
cpupower frequency-set -g performance）、停用无关服务、确认无 Full GC
什么场景下可以放心用 nanoTime
只要满足“同一线程内、紧贴业务逻辑、不跨核迁移”，nanoTime 就非常可靠：
- 单线程内测量一段代码的真实耗时（如算法 benchmark）
- 实现超时控制（如 socket read timeout），完全不受系统时间回拨影响
- 构建滑动窗口直方图、记录 P99 延迟，所有时间戳均来自同一上下文
