System.currentTimeMillis()会慢吗
Posted 幻影
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了System.currentTimeMillis()会慢吗相关的知识,希望对你有一定的参考价值。
最近看一份代码的时候,发现有个打印程序执行耗时的地方,特意写了个类去获取时间。
那为啥不直接用System.currentTimeMillis()呢?好吧,以前没注意这个细节。如果你也不知道,请继续往下看。
现象
先来个demo看看现象
public class CurrentTimeMillisDemo {
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");
final CountDownLatch startLatch = new CountDownLatch(1);
final CountDownLatch endLatch = new CountDownLatch(COUNT);
for (int i = 0; i < COUNT; i++) {
new Thread(new Runnable() {
@Override
public void run() {
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");
}
}
跑一下,输出结果:
100 System.currentTimeMillis() serial calls: 5300 ns
100 System.currentTimeMillis() parallel calls: 14874400 ns
相差居然这么大,100个并发条件下,耗时是单线程的N倍!
原因
为什么相差这么大?(我也不知道)这就是一句简单的获取时间呢
百度谷歌之后,才大概知道原因了。
hotspot/src/os/linux/vm/os_linux.cpp文件中,有一个javaTimeMillis()方法,它里面又调用了gettimeofday(),这个是System.currentTimeMillis()的native实现。这个方法里边有3点值得注意的地方:
- 调用gettimeofday()需要从用户态切换到内核态;
- gettimeofday()的表现受Linux系统计时器(时钟源)影响,在HPET计时器下性能尤其差;
- 系统只有一个全局时钟源,高并发或频繁访问会造成严重的争用。
看起来挺有道理的,用户态切换到内核态/原子时钟....那怎么解决呢?
解决
用单个调度线程来按毫秒更新时间戳,相当于维护一个全局缓存。其他线程取时间戳时相当于从内存取,不会再造成时钟资源的争用,代价就是牺牲了一些精确度。源码如下:
public class Clock {
private final long period;
private final AtomicLong now;
private Clock(long period) {
this.period = period;
this.now = new AtomicLong(System.currentTimeMillis());
scheduleClockUpdating();
}
public static Clock instance() {
return InstanceHolder.INSTANCE;
}
// 核心是这里,定时去更新时间
private void scheduleClockUpdating() {
ScheduledExecutorService scheduler = Executors.newSingleThreadScheduledExecutor(new ThreadFactory() {
@Override
public Thread newThread(Runnable runnable) {
Thread thread = new Thread(runnable, "System Clock");
thread.setDaemon(true);
return thread;
}
});
scheduler.scheduleAtFixedRate(new Runnable() {
@Override
public void run() {
now.set(System.currentTimeMillis());
}
}, period, period, TimeUnit.MILLISECONDS);
}
public long currentTimeMillis() {
return now.get();
}
private static class InstanceHolder {
public static final Clock INSTANCE = new Clock(1);
}
}
这样写性能差多少呢? 我的机器上跑了下,差不多省了四分之三
以上是关于System.currentTimeMillis()会慢吗的主要内容,如果未能解决你的问题,请参考以下文章
System.currentTimeMillis() 是不是返回 UTC 时间?
给定日期的 System.currentTimeMillis()? [复制]
System.nanoTime()和System.currentTimeMillis()性能问题
System.currentTimeMillis() uptimeMillis() elapsedRealtime() 区别