我已经看到并阅读了有关为什么 System.nanoTime() 在某些操作系统上比其他操作系统慢的帖子，但是我从未看到任何东西可以解释我现在看到的差异。使用 JMH，我正在运行这个基准测试。（注意：它也使用 System.nanoTime() ）
@Benchmark
public long systemNanoTime() {
return System.nanoTime();
}
在 Windows 10 上，这需要大约 25 ns。
在 Centos 7、Linux 3.10 上，它被测量为大约 10293 ns。
这是在同一台机器上，Intel(R) Core(TM) i7-7820X CPU @ 3.60GHz
是否可以选择更改 JDK 获取系统时钟的方式？
编辑：根据托德提供的链接，似乎 tsc 不可用
# more /sys/devices/system/clocksource/clocksource0/*
::::::::::::::
/sys/devices/system/clocksource/clocksource0/available_clocksource
::::::::::::::
hpet acpi_pm
::::::::::::::
/sys/devices/system/clocksource/clocksource0/current_clocksource
::::::::::::::
hpet
表演后
echo acpi_pm > /sys/devices/system/clocksource/clocksource0/current_clocksource
延迟有所改善，但仍然很差，延迟为 1,816 ns。
我试图找出是否可以将 TSC 时钟源添加到 Centos，但还没有运气。
编辑：进一步挖掘
# dmesg | grep -i tsc
[ 0.000000] tsc: Detected 3600.000 MHz processor
[ 0.058602] TSC deadline timer enabled
[ 0.065868] TSC synchronization [CPU#0 -> CPU#1]:
[ 0.065870] Measured 679995254538 cycles TSC warp between CPUs, turning off TSC clock.
[ 0.065874] tsc: Marking TSC unstable due to check_tsc_sync_source failed
[ 125.451480] Override clocksource tsc is not HRT compatible. Cannot switch while in HRT/NOHZ mode