不敢相信?System.currentTimeMillis()存在性能问题
收藏

点击上方Java后端技术”,选择“置顶或者星标”

你关注的就是我关心的!

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


上一篇:日均5亿查询量的京东订单中心,为什么舍MySQL用ES?

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

直接看代码

  1. public class CurrentTimeMillisPerfDemo {

  2. private static final int COUNT = 100;


  3. public static void main(String[] args) throws Exception {

  4. long beginTime = System.nanoTime();

  5. for (int i = 0; i < COUNT; i++) {

  6. System.currentTimeMillis();

  7. }


  8. long elapsedTime = System.nanoTime() - beginTime;

  9. System.out.println("100 System.currentTimeMillis() serial calls: " + elapsedTime + " ns");


  10. CountDownLatch startLatch = new CountDownLatch(1);

  11. CountDownLatch endLatch = new CountDownLatch(COUNT);

  12. for (int i = 0; i < COUNT; i++) {

  13. new Thread(() -> {

  14. try {

  15. startLatch.await();

  16. System.currentTimeMillis();

  17. } catch (InterruptedException e) {

  18. e.printStackTrace();

  19. } finally {

  20. endLatch.countDown();

  21. }

  22. }).start();

  23. }


  24. beginTime = System.nanoTime();

  25. startLatch.countDown();

  26. endLatch.await();

  27. elapsedTime = System.nanoTime() - beginTime;

  28. System.out.println("100 System.currentTimeMillis() parallel calls: " + elapsedTime + " ns");

  29. }

  30. }

执行结果如下图。

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

挖源码就到此为止,因为已经有国外大佬深入到了汇编的级别来探究,详情可以参见《The Slow currentTimeMillis()》这篇文章。简单来讲就是:

  • 调用gettimeofday()需要从用户态切换到内核态;

  • gettimeofday()的表现受Linux系统的计时器(时钟源)影响,在HPET计时器下性能尤其差;

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

HPET计时器性能较差的原因是会将所有对时间戳的请求串行执行。TSC计时器性能较好,因为有专用的寄存器来保存时间戳。缺点是可能不稳定,因为它是纯硬件的计时器,频率可变(与处理器的CLK信号有关)。关于HPET和TSC的细节可以参见https://en.wikipedia.org/wiki/HighPrecisionEventTimer与https://en.wikipedia.org/wiki/TimeStamp_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. private CurrentTimeMillisClock() {

  4. this.now = System.currentTimeMillis();

  5. scheduleTick();

  6. }


  7. private void scheduleTick() {

  8. new ScheduledThreadPoolExecutor(1, runnable -> {

  9. Thread thread = new Thread(runnable, "current-time-millis");

  10. thread.setDaemon(true);

  11. return thread;

  12. }).scheduleAtFixedRate(() -> {

  13. now = System.currentTimeMillis();

  14. }, 1, 1, TimeUnit.MILLISECONDS);

  15. }


  16. public long now() {

  17. return now;

  18. }


  19. public static CurrentTimeMillisClock getInstance() {

  20. return SingletonHolder.INSTANCE;

  21. }


  22. private static class SingletonHolder {

  23. private static final CurrentTimeMillisClock INSTANCE = new CurrentTimeMillisClock();

  24. }

  25. }

使用的时候,直接 CurrentTimeMillisClock.getInstance().now()就可以了。

不过,在System.currentTimeMillis()的效率没有影响程序整体的效率时,就完全没有必要做这种优化,这只是为极端情况准备的。

热门内容:

1、历史文章分类导读列表!精选优秀博文都在这里了!

2、分布式 RPC 框架性能大比拼,Dubbo最差?

3、Code Review最佳实践

4、这可能是史上最详细的 IDEA 中使用 Debug 教程!

5、终于明白为什么要加 final 关键字了!

6、看完这篇还不清楚Netty的内存管理,那我就哭了!

7、Spring中的18个注解,你会几个?

8、祖传代码,轻则伤筋动骨,重则一命呜呼

9、整理了一些 IDEA 中比较骚的技巧,发现第一个就没用过!

10、Google 为什么把几十亿行代码放在一个库