并发慎用——System.currentTimeMillis()

好记忆不如烂笔头，能记下点东西，就记下点，有时间拿出来看看，也会发觉不一样的感受.

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

 1 public class CurrentTimeMillisPerfDemo {
 2     private static final int COUNT = 100;
 3
 4     public static void main(String[] args) throws Exception {
 5         long beginTime = System.nanoTime();
 6         for (int i = 0; i < COUNT; i++) {
 7             System.currentTimeMillis();
 8         }
 9
10         long elapsedTime = System.nanoTime() - beginTime;
11         System.out.println("100 System.currentTimeMillis() serial calls: " + elapsedTime + " ns");
12
13         CountDownLatch startLatch = new CountDownLatch(1);
14         CountDownLatch endLatch = new CountDownLatch(COUNT);
15         for (int i = 0; i < COUNT; i++) {
16             new Thread(() -> {
17                 try {
18                     startLatch.await();
19                     System.currentTimeMillis();
20                 } catch (InterruptedException e) {
21                     e.printStackTrace();
22                 } finally {
23                     endLatch.countDown();
24                 }
25             }).start();
26         }
27
28         beginTime = System.nanoTime();
29         startLatch.countDown();
30         endLatch.await();
31         elapsedTime = System.nanoTime() - beginTime;
32         System.out.println("100 System.currentTimeMillis() parallel calls: " + elapsedTime + " ns");
33     }
34 }

demo

执行结果如下图。

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

为什么会这样呢？来到HotSpot源码的hotspot/src/os/linux/vm/os_linux.cpp文件中，有一个javaTimeMillis()方法，这就是System.currentTimeMillis()的native实现。

1 jlong os::javaTimeMillis() {
2   timeval time;
3   int status = gettimeofday(&time, NULL);
4   assert(status != -1, "linux error");
5   return jlong(time.tv_sec) * 1000  +  jlong(time.tv_usec / 1000);
6 }

native Code

挖源码就到此为止，因为已经有国外大佬深入到了汇编的级别来探究，详情可以参见《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。

另外，可以用以下的命令查看和修改时钟源。

1 ~ cat /sys/devices/system/clocksource/clocksource0/available_clocksource
2 tsc hpet acpi_pm
3 ~ cat /sys/devices/system/clocksource/clocksource0/current_clocksource
4 tsc
5 ~ echo 'hpet' > /sys/devices/system/clocksource/clocksource0/current_clocksource

命令

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

 1 public class CurrentTimeMillisClock {
 2     private volatile long now;
 3
 4     private CurrentTimeMillisClock() {
 5         this.now = System.currentTimeMillis();
 6         scheduleTick();
 7     }
 8
 9     private void scheduleTick() {
10         new ScheduledThreadPoolExecutor(1, runnable -> {
11             Thread thread = new Thread(runnable, "current-time-millis");
12             thread.setDaemon(true);
13             return thread;
14         }).scheduleAtFixedRate(() -> {
15             now = System.currentTimeMillis();
16         }, 1, 1, TimeUnit.MILLISECONDS);
17     }
18
19     public long now() {
20         return now;
21     }
22     
23     public static CurrentTimeMillisClock getInstance() {
24         return SingletonHolder.INSTANCE;
25     }
26
27     private static class SingletonHolder {
28         private static final CurrentTimeMillisClock INSTANCE = new CurrentTimeMillisClock();
29     }
30 }

使用的时候，直接CurrentTimeMillisClock.getInstance().now()就可以了。不过，在System.currentTimeMillis()的效率没有影响程序整体的效率时，就不必忙着做优化，这只是为极端情况准备的。

其他不涉及到时间戳的方法：System.currentTimeMillis

 例如：UUID.randomUUID().toString().replace("-", "");

 

 

参考：https://blog.csdn.net/supingemail/article/details/106400422?utm_medium=distribute.pc_relevant.none-task-blog-baidujs_title-0&spm=1001.2101.3001.4242