您好,登錄后才能下訂單哦!
System.currentTimeMillis()是極其常用的基礎(chǔ)Java API,廣泛地用來獲取時間戳或測量代碼執(zhí)行時長等,在我們的印象中應(yīng)該快如閃電。但實際上在并發(fā)調(diào)用或者特別頻繁調(diào)用它的情況下(比如一個業(yè)務(wù)繁忙的接口,或者吞吐量大的需要取得時間戳的流式程序),其性能表現(xiàn)會令人大跌眼鏡。
直接看代碼
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"); ?} }
執(zhí)行結(jié)果如下圖。
可見,并發(fā)調(diào)用System.currentTimeMillis()一百次,耗費的時間是單線程調(diào)用一百次的250倍。如果單線程的調(diào)用頻次增加(比如達(dá)到每毫秒數(shù)次的地步),也會觀察到類似的情況。實際上在極端情況下,System.currentTimeMillis()的耗時甚至?xí)葎?chuàng)建一個簡單的對象實例還要多,看官可以自行將上面線程中的語句換成new HashMap<>之類的試試看。
為什么會這樣?
來到HotSpot源碼的hotspot/src/os/linux/vm/os_linux.cpp文件中,有一個javaTimeMillis()方法,這就是System.currentTimeMillis()的native實現(xiàn)。
挖源碼就到此為止,因為已經(jīng)有國外大佬深入到了匯編的級別來探究,詳情可以參見《The Slow currentTimeMillis()》這篇文章。簡單來講就是:
調(diào)用gettimeofday()需要從用戶態(tài)切換到內(nèi)核態(tài);
gettimeofday()的表現(xiàn)受Linux系統(tǒng)的計時器(時鐘源)影響,在HPET計時器下性能尤其差;
系統(tǒng)只有一個全局時鐘源,高并發(fā)或頻繁訪問會造成嚴(yán)重的爭用。
HPET計時器性能較差的原因是會將所有對時間戳的請求串行執(zhí)行。TSC計時器性能較好,因為有專用的寄存器來保存時間戳。缺點是可能不穩(wěn)定,因為它是純硬件的計時器,頻率可變(與處理器的CLK信號有關(guān))。關(guān)于HPET和TSC的細(xì)節(jié)可以參見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
如何解決這個問題?
最常見的辦法是用單個調(diào)度線程來按毫秒更新時間戳,相當(dāng)于維護(hù)一個全局緩存。其他線程取時間戳?xí)r相當(dāng)于從內(nèi)存取,不會再造成時鐘資源的爭用,代價就是犧牲了一些精確度。具體代碼如下。
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()的效率沒有影響程序整體的效率時,就完全沒有必要做這種優(yōu)化,這只是為極端情況準(zhǔn)備的。
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進(jìn)行舉報,并提供相關(guān)證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權(quán)內(nèi)容。