System.currentTimeMillis的性能如何

一、背景

撸代码时发现System.currentTimeMillis的调用都被封装成了cache类型，代码如下:

 那么System.currentTimeMillis真的有这么这么差吗，如果差的话又是什么原因造成的？什么情况下可以直接调用原生方法，什么情况下需要使用缓存呢？

二、测试

先问会不会，再问为什么。那么System.currentTimeMillis的性能是否真的有这么差，很多大佬给出了自己的测试case并总结出下面两个结论

1）在高并发场景下System.currentTimeMillis()并发问题严重，甚至比创建一个普通对象要耗时的多

2）单线程执行System.currentTimeMillis();比多线程并发执行System.currentTimeMillis();快了许多倍

2.1 单线程场景

大家都在讨论多线程场景下的表现，那么单线程场景下它的表现如何，测试代码如下：

 分别跑System.currentTimeMillis 和new 简单对象1k,1w,10w次，测试结果如下：

amazing了，System.currentTimeMillis 竟然在单线程下的性能也比new一个对象差那么多

2.2 多线程场景

看起来线程数和平均耗费时间成正比例，串行处理

三、原理

参考：http://pzemtsov.github.io/2017/07/23/the-slow-currenttimemillis.html

挖源码就到此为止，因为已经有国外大佬深入到了汇编的级别来探究，简单来讲就是：

• 调用gettimeofday()需要从用户态切换到内核态；
• gettimeofday()的表现受Linux系统的计时器（时钟源）影响，在HPET计时器下性能尤其差；

• 系统只有一个全局时钟源，高并发或频繁访问会造成严重的争用。

所以在调用次数少的时候是可以忍受的，效率不会太慢。调用次数多的时候产生竞争才会造成耗时变长。

nanoTime也并不能解决问题。

查看linux系统使用的数据源：

四、解决方法

1）如开头，缓存时钟

2）更改时钟源