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

来源：互联网发布：vb中shell函数编辑：程序博客网时间：2024/04/29 17:17

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() {@Overridepublic 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）。

0 0