Java线程最小挂起时长取决于操作系统调度还是CPU？

测试背景 #

我正在使用LockSupport.parkNanos(long)研究亚毫秒级线程暂停现象，分别在两台设备（搭载Intel Core i7处理器的MacOS设备、搭载Intel Core i5处理器的Linux设备）上运行了如下JMH基准测试：

@State(Scope.Thread)
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
public class ParkNanosBenchmark {

  @Param({"10", "100", "1000", "10000", "1000000"})
  long delay;

  @Benchmark
  public void parkNanos() {
    LockSupport.parkNanos(delay);
  }
}

测试结果 #

Linux

Benchmark                         (delay)  Mode  Cnt        Score      Error  Units
ParkNanosBenchmark.parkNanos           10  avgt   40    57713.345 ±  165.827  ns/op
ParkNanosBenchmark.parkNanos          100  avgt   40    57672.554 ±  444.892  ns/op
ParkNanosBenchmark.parkNanos         1000  avgt   40    58646.654 ±  120.040  ns/op
ParkNanosBenchmark.parkNanos        10000  avgt   40    68222.650 ±  115.751  ns/op
ParkNanosBenchmark.parkNanos      1000000  avgt   40  1103499.893 ± 7793.704  ns/op

MacOS

Benchmark                         (delay)  Mode  Cnt        Score       Error  Units
ParkNanosBenchmark.parkNanos           10  avgt   40    11395,046 ±   250,512  ns/op
ParkNanosBenchmark.parkNanos          100  avgt   40     9171,332 ±  1117,377  ns/op
ParkNanosBenchmark.parkNanos         1000  avgt   40     4781,591 ±    82,799  ns/op
ParkNanosBenchmark.parkNanos        10000  avgt   40    17750,419 ±   256,214  ns/op
ParkNanosBenchmark.parkNanos      1000000  avgt   40  1403117,216 ± 42218,338  ns/op

Java 11与Java 17版本下的测试结果基本一致，基于上述结果提出两个问题：

1. Linux与MacOS的测试结果差异是由操作系统调度器粒度决定，还是主要与CPU硬件相关？
2. 为何MacOS环境下delay参数取值为10~1000区间时，测试结果的误差范围大、离散度极高？

问题解答 #

问题1：跨平台结果差异的核心原因 #

差异核心来自操作系统的定时器与调度实现，和测试用到的i5/i7 CPU硬件差异几乎无关：

• 现代Linux内核在x86平台用futex实现park/unpark原语，默认开启的高精度定时器（hrtimer）最小唤醒粒度稳定在50_{60微秒区间，这和测到的Linux下delay小于10000ns时实际暂停时间稳定在}58微秒的结果完全匹配：所有小于调度最小粒度的park请求，都至少要等一个hrtimer周期或者调度tick才会被重新唤醒。测试中1ms（1000000ns）delay时实际延迟约1.1ms，也完全符合Linux定时器的常规偏移范围。
• MacOS的XNU内核底层等待机制和Linux逻辑完全不同，基于mach端口的等待原语默认基础唤醒粒度比Linux更细，普遍在10微秒以内，这就是MacOS下短delay平均暂停时间远低于Linux的核心原因。
• 只要测试用的i5、i7是同代x86架构，硬件定时器（比如TSC）的精度差在纳秒级，根本不可能造成几十微秒的结果差距，硬件不是核心影响因素。

问题2：MacOS下短delay高离散度的原因 #

这个现象本质是MacOS对短等待场景做了自适应策略分流：

• 当传入的park等待时长小于内核配置的定时器阈值（默认是几微秒级别），XNU不会直接走高精度定时器阻塞路径，而是先进入短时间自旋等待。自旋过程中只要碰到任何触发事件——比如硬件中断、其他高优先级线程抢占、CPU频率动态切换，就会直接退出park；如果自旋期间没有触发事件，才会转入定时器阻塞流程。
• 自旋等待的时长完全没有固定值，受系统实时负载、CPU电源管理策略、中断触发频率影响极大：比如CPU刚好跑在高频、无中断的状态下，可能几纳秒就退出park；如果刚好碰到时钟中断、其他内核任务抢占，可能要等十几微秒才能重新调度回测试线程。10~1000ns这个区间的等待时长本身远小于内核定时器的最小粒度，所有请求都会走到自旋分支，最终就表现为结果误差大、离散度极高。
• 当delay参数到10000ns（10微秒）以上时，内核会直接跳过自旋分支，走稳定的高精度定时器阻塞路径，结果的离散度就会明显下降，和测试中10000ns以上误差收窄的结果完全吻合。

补充验证方式：可以把两台设备的CPU电源管理都调到高性能模式、关闭睿频，Linux侧可以把内核tick配置为1000Hz、关闭NO_HZ动态调整，再重跑测试，会看到Linux的最小等待粒度进一步降低，MacOS的短等待离散度也会明显收窄，也能侧面证明差异核心来自操作系统层的调度与定时器实现。

内容的提问来源于stack exchange，提问作者Sergey Tsypanov