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

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();}//單線程執行100次耗時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);//多線程并發執行100次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.await();導致100個線程都阻塞在哪里,直到countDown才開始調用系統時間戳方法,模擬并發場景startLatch.countDown();//直到100個線程調用系統時間戳完畢,再向下執行統計耗時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/High_Precision_Event_Timer
與https://en.wikipedia.org/wiki/Time_Stamp_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()的效率沒有影響程序整體的效率時，就不必忙著做優化，這只是為極端情況準備的。

轉載自LittleMagic的博客
原文鏈接：https://www.jianshu.com/p/d2039190b1cb

補充說明:

我實際測試的時候，執行100次，并發的耗時大概是單線程的2-3倍，執行一千次的時候大概差了30多倍，執行1萬次則差了2000多倍

超強干貨來襲 云風專訪：近40年碼齡，通宵達旦的技術人生

總結

以上是生活随笔為你收集整理的注意System.currentTimeMillis()潜在的性能问题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。