注意了！System.currentTimeMillis() 有性能问题…-

沙海

3180
文章

2
评论

2021年6月10日02:46:14Java评论73字数 4241阅读14分8秒阅读模式

摘要

智能摘要

智能摘要文章源自JAVA秀-https://www.javaxiu.com/30943.html

实际上在并发调用或者特别频繁调用它的情况下(比如一个业务繁忙的接口，或者吞吐量大的需要取得时间戳的流式程序)，其性能表现会令人大跌眼镜。如果单线程的调用频次增加(比如达到每毫秒数次的地步)，也会观察到类似的情况。TSC计时器性能较好，因为有专用的寄存器来保存时间戳。最常见的办法是用单个调度线程来按毫秒更新时间戳，相当于维护一个全局缓存。其他线程取时间戳时相当于从内存取，不会再造成时钟资源的争用，代价就是牺牲了一些精确度。文章源自JAVA秀-https://www.javaxiu.com/30943.html

原文约 1609 字 | 图片 1 张 | 建议阅读 4 分钟 | 评价反馈文章源自JAVA秀-https://www.javaxiu.com/30943.html

注意了！System.currentTimeMillis() 有性能问题...

架构师专栏文章源自JAVA秀-https://www.javaxiu.com/30943.html

收录于话题文章源自JAVA秀-https://www.javaxiu.com/30943.html

#架构进阶114文章源自JAVA秀-https://www.javaxiu.com/30943.html

#Java进阶45文章源自JAVA秀-https://www.javaxiu.com/30943.html

#历史专栏252文章源自JAVA秀-https://www.javaxiu.com/30943.html

大家好，我是磊哥。文章源自JAVA秀-https://www.javaxiu.com/30943.html

System.currentTimeMillis()是极其常用的基础Java API，广泛地用来获取时间戳或测量代码执行时长等，在我们的印象中应该快如闪电。但实际上在并发调用或者特别频繁调用它的情况下（比如一个业务繁忙的接口，或者吞吐量大的需要取得时间戳的流式程序），其性能表现会令人大跌眼镜。直接看下面的Demo。文章源自JAVA秀-https://www.javaxiu.com/30943.html

注意文章源自JAVA秀-https://www.javaxiu.com/30943.html

文末有：3625页互联网大厂面试题 文章源自JAVA秀-https://www.javaxiu.com/30943.html

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

执行结果如下图。文章源自JAVA秀-https://www.javaxiu.com/30943.html

注意了！System.currentTimeMillis() 有性能问题… 文章源自JAVA秀-https://www.javaxiu.com/30943.html

可见，并发调用System.currentTimeMillis()一百次，耗费的时间是单线程调用一百次的250倍。如果单线程的调用频次增加（比如达到每毫秒数次的地步），也会观察到类似的情况。实际上在极端情况下，System.currentTimeMillis()的耗时甚至会比创建一个简单的对象实例还要多，看官可以自行将上面线程中的语句换成new HashMap<>之类的试试看。文章源自JAVA秀-https://www.javaxiu.com/30943.html

为什么会这样呢？来到HotSpot源码的hotspot/src/os/linux/vm/os_linux.cpp文件中，有一个javaTimeMillis()方法，这就是System.currentTimeMillis()的native实现。文章源自JAVA秀-https://www.javaxiu.com/30943.html

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

挖源码就到此为止，因为已经有国外大佬深入到了汇编的级别来探究文章源自JAVA秀-https://www.javaxiu.com/30943.html

简单来讲就是：

调用gettimeofday()需要从用户态切换到内核态；文章源自JAVA秀-https://www.javaxiu.com/30943.html
gettimeofday()的表现受Linux系统的计时器（时钟源）影响，在HPET计时器下性能尤其差；文章源自JAVA秀-https://www.javaxiu.com/30943.html
系统只有一个全局时钟源，高并发或频繁访问会造成严重的争用。文章源自JAVA秀-https://www.javaxiu.com/30943.html

HPET计时器性能较差的原因是会将所有对时间戳的请求串行执行。TSC计时器性能较好，因为有专用的寄存器来保存时间戳。缺点是可能不稳定，因为它是纯硬件的计时器，频率可变（与处理器的CLK信号有关）。关于HPET和TSC的细节可以文章源自JAVA秀-https://www.javaxiu.com/30943.html

参见文章源自JAVA秀-https://www.javaxiu.com/30943.html

https://en.wikipedia.org/wiki/High_Precision_Event_Timer文章源自JAVA秀-https://www.javaxiu.com/30943.html

与文章源自JAVA秀-https://www.javaxiu.com/30943.html

https://en.wikipedia.org/wiki/Time_Stamp_Counter文章源自JAVA秀-https://www.javaxiu.com/30943.html

另外，可以用以下的命令查看和修改时钟源。文章源自JAVA秀-https://www.javaxiu.com/30943.html

~ cat /sys/devices/system/clocksource/clocksource0/available_clocksourcetsc hpet acpi_pm~ cat /sys/devices/system/clocksource/clocksource0/current_clocksourcetsc~ echo 'hpet' > /sys/devices/system/clocksource/clocksource0/current_clocksource

如何解决这个问题？最常见的办法是用单个调度线程来按毫秒更新时间戳，相当于维护一个全局缓存。其他线程取时间戳时相当于从内存取，不会再造成时钟资源的争用，代价就是牺牲了一些精确度。具体代码如下。文章源自JAVA秀-https://www.javaxiu.com/30943.html

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()的效率没有影响程序整体的效率时，就不必忙着做优化，这只是为极端情况准备的。文章源自JAVA秀-https://www.javaxiu.com/30943.html

作者：LittleMagicjianshu.com/p/d2039190b1cb文章源自JAVA秀-https://www.javaxiu.com/30943.html

近期技术热文文章源自JAVA秀-https://www.javaxiu.com/30943.html

文章源自JAVA秀-https://www.javaxiu.com/30943.html

爽！！一个注解，搞定 SpringBoot 操作日志文章源自JAVA秀-https://www.javaxiu.com/30943.html

文章源自JAVA秀-https://www.javaxiu.com/30943.html

Spring 最常用的 7 大类注解，史上最强整理！文章源自JAVA秀-https://www.javaxiu.com/30943.html

文章源自JAVA秀-https://www.javaxiu.com/30943.html

RabbitMQ 延迟队列，太实用了！文章源自JAVA秀-https://www.javaxiu.com/30943.html

文章源自JAVA秀-https://www.javaxiu.com/30943.html

面试难题：String长度有限制吗？是多少？文章源自JAVA秀-https://www.javaxiu.com/30943.html

文章源自JAVA秀-https://www.javaxiu.com/30943.html

第3版：互联网大厂面试题文章源自JAVA秀-https://www.javaxiu.com/30943.html