我看过并读过关于为什么 System.nanoTime() 在某些操作系统上比其他操作系统慢的文章，但是我从未见过任何东西可以解释我现在看到的差异。我正在使用 JMH 运行这个基准测试。 （注意：它也使用 System.nanoTime()）
@Benchmark
public long systemNanoTime() {
return System.nanoTime();
}
在 Windows 10 上，这大约需要 25 纳秒。
在 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
