不敢相信？System.currentTimeMillis() 居然存在性能问题

绝地灬酷狼 2021-07-31 19:00 520阅读 0赞

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

执行结果如下图。

![640?wx\_fmt=other][640_wx_fmt_other]可见，并发调用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()的效率没有影响程序整体的效率时，就完全没有必要做这种优化，这只是为极端情况准备的。

来源： www.jianshu.com/p/d2039190b1cb

作者： LittleMagic

如果喜欢本篇文章，欢迎转发、点赞。关注订阅号「Web项目聚集地」，回复「进群」即可进入无广告技术交流。

--------------------

**推荐阅读**

***1.***

***2. ***

***3.***

***4. ***

***5.***

***6.***

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg]

**喜欢文章，点个** **在看** ** ** ![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 1]

[640_wx_fmt_other]: /images/20210731/8ad147c67594483bbcf5456d93c830cf.png?wx_fmt=other
[640_wx_fmt_jpeg]: /images/20210731/598e2938ed764fe19d03eb44a3fb7ac8.png?wx_fmt=jpeg
[640_wx_fmt_jpeg 1]: /images/20210731/89b911736de5419abd8a0941d8d8cd5e.png?wx_fmt=jpeg