不敢相信？System.currentTimeMillis()存在性能問題

System.currentTimeMillis()是極其常用的基礎Java API，廣泛地用來獲取時間戳或測量代碼執行時長等，在我們的印象中應該快如閃電。但實際上在并發調用或者特別頻繁調用它的情況下（比如一個業務繁忙的接口，或者吞吐量大的需要取得時間戳的流式程序），其性能表現會令人大跌眼鏡。

直接看代碼

public?class?CurrentTimeMillisPerfDemo?{
?private?static?final?int?COUNT?=?100;
?public?static?void?main(String[]?args)?throws?Exception?{
?long?beginTime?=?System.nanoTime();
?for?(int?i?=?0;?i?<?COUNT;?i++)?{
?System.currentTimeMillis();
?}
?long?elapsedTime?=?System.nanoTime()?-?beginTime;
?System.out.println("100?System.currentTimeMillis()?serial?calls:?"?+?elapsedTime?+?"?ns");
?CountDownLatch?startLatch?=?new?CountDownLatch(1);
?CountDownLatch?endLatch?=?new?CountDownLatch(COUNT);
?for?(int?i?=?0;?i?<?COUNT;?i++)?{
?new?Thread(()?->?{?
?try?{
?startLatch.await();
?System.currentTimeMillis();
?}?catch?(InterruptedException?e)?{
?e.printStackTrace();
?}?finally?{
?endLatch.countDown();
?}
?}).start();
?}
?beginTime?=?System.nanoTime();
?startLatch.countDown();
?endLatch.await();
?elapsedTime?=System.nanoTime()?-?beginTime;
?System.out.println("100?System.currentTimeMillis()?parallel?calls:?"?+elapsedTime?+?"?ns");
?}
}

執行結果如下圖。

可見，并發調用System.currentTimeMillis()一百次，耗費的時間是單線程調用一百次的250倍。如果單線程的調用頻次增加（比如達到每毫秒數次的地步），也會觀察到類似的情況。實際上在極端情況下，System.currentTimeMillis()的耗時甚至會比創建一個簡單的對象實例還要多，看官可以自行將上面線程中的語句換成new HashMap<>之類的試試看。

為什么會這樣？

來到HotSpot源碼的hotspot/src/os/linux/vm/os_linux.cpp文件中，有一個javaTimeMillis()方法，這就是System.currentTimeMillis()的native實現。

挖源碼就到此為止，因為已經有國外大佬深入到了匯編的級別來探究，詳情可以參見《The Slow currentTimeMillis()》這篇文章。簡單來講就是：

• 調用gettimeofday()需要從用戶態切換到內核態；

• gettimeofday()的表現受Linux系統的計時器（時鐘源）影響，在HPET計時器下性能尤其差；

• 系統只有一個全局時鐘源，高并發或頻繁訪問會造成嚴重的爭用。

HPET計時器性能較差的原因是會將所有對時間戳的請求串行執行。TSC計時器性能較好，因為有專用的寄存器來保存時間戳。缺點是可能不穩定，因為它是純硬件的計時器，頻率可變（與處理器的CLK信號有關）。關于HPET和TSC的細節可以參見https://en.wikipedia.org/wiki/HighPrecisionEventTimer與https://en.wikipedia.org/wiki/TimeStamp_Counter。

另外，可以用以下的命令查看和修改時鐘源。

~?cat?/sys/devices/system/clocksource/clocksource0/available_clocksource
tsc?hpet?acpi_pm
~?cat?/sys/devices/system/clocksource/clocksource0/current_clocksource
tsc
~?echo?'hpet'?>?/sys/devices/system/clocksource/clocksource0/current_clocksource

如何解決這個問題？

最常見的辦法是用單個調度線程來按毫秒更新時間戳，相當于維護一個全局緩存。其他線程取時間戳時相當于從內存取，不會再造成時鐘資源的爭用，代價就是犧牲了一些精確度。具體代碼如下。

public?class?CurrentTimeMillisClock?{
?private?volatile?long?now;
?private?CurrentTimeMillisClock()?{
?this.now?=?System.currentTimeMillis();
?scheduleTick();
?}
?private?void?scheduleTick()?{
?new?ScheduledThreadPoolExecutor(1,?runnable?->?{
?Thread?thread?=?new?Thread(runnable,?"current-time-millis");
?thread.setDaemon(true);
?return?thread;
?}).scheduleAtFixedRate(()?->?{
?now?=?System.currentTimeMillis();
?},?1,?1,?TimeUnit.MILLISECONDS);
?}
?public?long?now()?{
?return?now;
?}
?public?static?CurrentTimeMillisClock?getInstance()?{
?return?SingletonHolder.INSTANCE;
?}
?private?static?class?SingletonHolder?{
?private?static?final?CurrentTimeMillisClock?INSTANCE?=?new?
CurrentTimeMillisClock();
?}
}

使用的時候，直接 CurrentTimeMillisClock.getInstance().now()就可以了。

不過，在System.currentTimeMillis()的效率沒有影響程序整體的效率時，就完全沒有必要做這種優化，這只是為極端情況準備的。