公衆號後臺回覆“面試”,獲取精品學習資料
掃描下方海報瞭解專欄詳情
本文來源:
https://www.jianshu.com/p/d2039190b1cb
《Java工程師面試突擊(第3季)》重磅升級,由原來的70講增至160講,內容擴充一倍多,升級部分內容請參見文末
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實現。
jlong os::javaTimeMillis() {
timeval time;
int status = gettimeofday(&time, NULL);
assert(status != -1, "linux error");
return jlong(time.tv_sec) * 1000 + jlong(time.tv_usec / 1000);
}
挖源碼就到此爲止,因爲已經有國外大佬深入到了彙編的級別來探究,詳情可以參見《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()的效率沒有影響程序整體的效率時,就完全沒有必要做這種優化,這只是爲極端情況準備的。
END
《Java工程師面試突擊第三季》加餐部分大綱:(注:1-66講的大綱請掃描文末二維碼,在課程詳情頁獲取)
詳細的課程內容,大家可以掃描下方二維碼瞭解: