System.currentTimeMillis()存在性能問題 （轉）

作者：LittleMagic

出處：  注意System.currentTimeMillis()潛在的性能問題
來源：簡書

 

 

　　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();
        }

        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/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()的效率沒有影響程序整體的效率時，就不必忙着做優化，這只是為極端情況准備的。