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

System.currentTimeMillis()的调用比new一个普通对象要耗时的多（具体耗时高出多少我还没测试过，有人说是100倍左右），然而该方法又是一个常用方法，有时不得不使用，比如日志，在高并发情形下怎么做才好呢？ 
System.currentTimeMillis()之所以慢是因为去跟系统打了一次交道，什么快？内存！如果该方法从内存直接取数，那岂不是相当快，看代码： 

Java代码  

1. class MillisecondClock {  
2.     private long rate = 0;// 频率  
3.     private volatile long now = 0;// 当前时间  
4.   
5.     private MillisecondClock(long rate) {  
6.         this.rate = rate;  
7.         this.now = System.currentTimeMillis();  
8.         start();  
9.     }  
10.   
11.     private void start() {  
12.         new Thread(new Runnable() {  
13.             @Override  
14.             public void run() {  
15.                 try {  
16.                     Thread.sleep(rate);  
17.                 } catch (InterruptedException e) {  
18.                     e.printStackTrace();  
19.                 }  
20.                 now = System.currentTimeMillis();  
21.             }  
22.         }).start();  
23.     }  
24.   
25.     public long now() {  
26.         return now;  
27.     }  
28.   
29.     public static final MillisecondClock CLOCK = new MillisecondClock(10);  
30. }  

用的时候直接CLOCK.now()即可，你可以适当的进行变形，比如调整更新频率，开放构造函数，设置daemon线程，改为懒汉模式等等。 
如下图是同时开启100个线程，每个线程并发请求一亿次的结果，可见耗时相差16倍左右（环境：JDK 1.7 win7 64位 4核 4G）。 

转载：http://buru.iteye.com/blog/1779991