Java-System.currentTimeMillis() 存在性能问题

Java (3) 2024-05-07 17:12

Hi,大家好,我是编程小6,很荣幸遇见你,我把这些年在开发过程中遇到的问题或想法写出来,今天说一说Java-System.currentTimeMillis() 存在性能问题,希望能够帮助你!!!。

来源:https://dwz.cn/M1NXgypa

在之前的文章中就提到了,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();
        }

        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-System.currentTimeMillis() 存在性能问题_https://bianchenghao6.com/blog_Java_第1张

可见,并发调用 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);
}


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

  • 调用 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() 的效率没有影响程序整体的效率时,就不必忙着做优化,这只是为极端情况准备的。

今天的分享到此就结束了,感谢您的阅读,如果确实帮到您,您可以动动手指转发给其他人。

下一篇

已是最新文章

发表回复