system.nanotime() 返回值单位为纳秒，但实际精度受平台限制，并非真正纳秒级；linux/macos 通常支持近纳秒分辨率，windows 约100纳秒，旧系统或虚拟环境可能低至毫秒级；实测最小非零差值才反映真实分辨率。
System.nanoTime() 返回值的单位是纳秒（nanoseconds），但它的实际精度和稳定性受运行平台影响，不是所有系统都能真正达到纳秒级分辨率。
时间单位确实是纳秒，但只是“名义单位”
方法签名明确返回 long 类型数值，文档定义其单位为纳秒。但这不等于每次调用都能分辨出 1 纳秒的差异——它反映的是 JVM 所用底层时钟源的理论最小刻度，而非真实可测量的最小间隔。
- Java 规范只要求该值“单调递增”且“高分辨率”，未强制要求硬件必须支持纳秒级计时
- 返回值本身没有单位标记，开发者需自行理解它是纳秒量级差值
- 比如在某些旧 Windows 系统上，
nanoTime()实际分辨率可能只有 15 毫秒左右，此时连续两次调用差值几乎总是 0 或跳变很大
不同操作系统底层时钟源差异明显
Java 通过 JNI 调用操作系统提供的高性能计时器，具体实现取决于平台：
- Linux 通常使用
CLOCK_MONOTONIC，典型分辨率可达 1 纳秒 - macOS 使用
mach_absolute_time，同样支持接近纳秒级更新 - Windows 默认依赖
QueryPerformanceCounter，理论精度 100 纳秒，但受电源策略、虚拟化环境影响较大 - 在容器或云虚拟机中，若未启用 paravirtualized 时钟（如 KVM 的
kvm-clock），可能出现时间漂移或偷取时间（steal time）现象，导致测量失真
JVM 实现也会带来差异
同一操作系统下，不同 JVM（如 HotSpot、OpenJ9、Zing）对时钟源的封装和优化策略不同：
- HotSpot 在 x86 架构上会优先尝试读取 CPU 的 TSC（时间戳计数器），若支持恒定频率且未被禁用，则能提供极低开销、高分辨率的时间值
- 某些 JVM 配置（如启用
-XX:+UsePreciseTimer）会影响 nanoTime 的底层行为 - ARM 平台或嵌入式 JVM 可能使用更保守的系统调用，分辨率下降至微秒级
如何验证你当前环境的实际分辨率？
不能只看文档或理论值，应实测：
- 循环调用
System.nanoTime()多次，统计相邻两次差值的最小非零值，即为当前平台可观测的最小时间间隔 - 注意避开 JIT 编译期干扰：先预热代码，再采集稳定样本
- 避免在 CPU 频率动态调整（如 Intel SpeedStep）、节能模式开启时测试，否则结果波动大
