高并发场景下System.currentTimeMillis()的性能问题

System.currentTimeMillis()的调用比new一个普通对象要耗时的多(具体耗时高出多少我还没测试过,有人说是100倍左右),然而该方法又是一个常用方法,有时不得不使用,比如日志,在高并发情形下怎么做才好呢?

System.currentTimeMillis()之所以慢是因为去跟系统打了一次交道,什么快?内存!如果该方法从内存直接取数,那岂不是相当快,看代码:

class MillisecondClock {
private long rate = 0;// 频率
private volatile long now = 0;// 当前时间

private MillisecondClock(long rate) {
this.rate = rate;
this.now = System.currentTimeMillis();
start();
}

private void start() {
new Thread(new Runnable() {
@Override
public void run() {
try {
Thread.sleep(rate);
} catch (InterruptedException e) {
e.printStackTrace();
}
now = System.currentTimeMillis();
}
}).start();
}

public long now() {
return now;
}

public static final MillisecondClock CLOCK = new MillisecondClock(10);
}

用的时候直接CLOCK.now()即可,你可以适当的进行变形,比如调整更新频率,开放构造函数,设置daemon线程,改为懒汉模式等等。

如下图是同时开启100个线程,每个线程并发请求一亿次的结果,可见耗时相差16倍左右(环境:JDK 1.7 win7 64位 4核 4G)。

unit test

评论