注意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();}//单线程执行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多倍

注意System.currentTimeMillis()潜在的性能问题相关推荐

疑惑，System.currentTimeMillis真有性能问题？
点击关注公众号,Java干货及时送达 System.currentTimeMillis的性能真有如此不堪吗? 最近我在研究一款中间件的源代码时,发现它获取当前时间不是通过System.currentT ...
System.currentTimeMillis()竟然存在性能问题，这我能信？
点击上方"方志朋",选择"设为星标" 做积极的人,而不是积极废人来源:https://dwz.cn/M1NXgypa 在之前的文章中就提到了,System.c ...
System.currentTimeMillis的性能真有如此不堪吗？
推荐大家关注一个公众号点击上方 "编程技术圈"关注, 星标或置顶一起成长后台回复"大礼包"有惊喜礼包! 每日英文 Two things always to ...
System.currentTimeMillis的性能，真有如此不堪吗？
以下文章来源方志朋的博客,回复"666"获面试宝典 # 疑惑,System.currentTimeMillis真有性能问题? 最近我在研究一款中间件的源代码时,发现它获取当前时间不 ...
Bullsh*t，System. currentTimeMillis大胆用起来，我说的！
以下文章来源方志朋的博客,回复"666"获面试宝典 # 疑惑,System.currentTimeMillis真有性能问题? 最近我在研究一款中间件的源代码时,发现它获取当前时间不 ...
不敢相信？System.currentTimeMillis()存在性能问题
点击蓝色"程序猿DD"关注我回复"资源"获取独家整理的学习资料! 推荐一个免费的写博神器:openwrite.cn.Markdown一次编写,轻松发布到CSD ...
System.currentTimeMillis()存在性能问题
System.currentTimeMillis()是极其常用的基础Java API,广泛地用来获取时间戳或测量代码执行时长等,在我们的印象中应该快如闪电.但实际上在并发调用或者特别频繁调用它的情况下 ...
Java的System.currentTimeMillis()的性能问题
System.currentTimeMillis()是极其常用的基础Java API,广泛地用来获取时间戳或测量代码执行时长等,在我们的印象中应该快如闪电.但实际上在并发调用或者特别频繁调用它的情况下 ...
java currenttimemillis 效率_高并发场景下System.currentTimeMillis()的性能问题的优化
前言 System.currentTimeMillis()的调用比new一个普通对象要耗时的多(具体耗时高出多少我也不知道,不过听说在100倍左右),然而该方法又是一个常用方法,有时不得不使用,比如生 ...

注意System.currentTimeMillis()潜在的性能问题

补充说明:

注意System.currentTimeMillis()潜在的性能问题相关推荐

最新文章

热门文章