高并发场景下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

评论