前言
在前面文章《Cobar SQL審計的設計與實現》中提了一句關於時間戳獲取效能的問題
獲取作業系統時間，在Java中直接呼叫 System.currentTimeMillis(); 就可以，但在Cobar中如果這麼獲取時間，就會導致效能損耗非常嚴重（怎麼解決？去Cobar的github倉庫上看看程式碼吧）。
這個話題展開具體說說，我們在Java中獲取時間戳的方法是System.currentTimeMillis()，返回的是毫秒級的時間戳，檢視原始碼，註釋寫的比較清楚，雖然該方法返回的是毫秒級的時間戳，但精度取決於作業系統，很多作業系統返回的精度是10毫秒。
/**
* Returns the current time in milliseconds. Note that
* while the unit of time of the return value is a millisecond,
* the granularity of the value depends on the underlying
* operating system and may be larger. For example, many
* operating systems measure time in units of tens of
* milliseconds.
*
* <p> See the description of the class <code>Date</code> for
* a discussion of slight discrepancies that may arise between
* "computer time" and coordinated universal time (UTC).
*
* @return the difference, measured in milliseconds, between
* the current time and midnight, January 1, 1970 UTC.
* @see java.util.Date
*/
public static native long currentTimeMillis();
關於為什麼System.currentTimeMillis()慢，有大佬寫了文章詳細地闡述了原因，建議仔細閱讀，非常深入和詳細，文章地址
http://pzemtsov.github.io/2017/07/23/the-slow-currenttimemillis.html
總結起來原因是System.currentTimeMillis呼叫了gettimeofday()
- 呼叫gettimeofday()需要從使用者態切換到核心態；
- gettimeofday()的表現受Linux系統的計時器（時鐘源）影響，在HPET計時器下效能尤其差；
- 系統只有一個全域性時鐘源，高併發或頻繁訪問會造成嚴重的爭用。
我們測試一下System.currentTimeMillis()在不同執行緒下的效能，這裡使用中介軟體常用的JHM來測試，測試1到128執行緒下獲取1000萬次時間戳需要的時間分別是多少，這裡給出在我的電腦上的測試資料：
Benchmark Mode Cnt Score Error Units
TimeStampTest.test1Thread avgt 0.271 s/op
TimeStampTest.test2Thread avgt 0.272 s/op
TimeStampTest.test4Thread avgt 0.278 s/op
TimeStampTest.test8Thread avgt 0.375 s/op
TimeStampTest.test16Thread avgt 0.737 s/op
TimeStampTest.test32Thread avgt 1.474 s/op
TimeStampTest.test64Thread avgt 2.907 s/op
TimeStampTest.test128Thread avgt 5.732 s/op
可以看出在1-4執行緒下比較快，8執行緒之後就是線性增長了。
測試程式碼參考：
@State(Scope.Benchmark)
public class TimeStampTest {
private static final int MAX = 10000000;
public static void main(String[] args) throws RunnerException {
Options opt = new OptionsBuilder()
.include(TimeStampTest.class.getSimpleName())
.forks(1)
.warmupIterations(1)
.measurementIterations(1)
.warmupTime(TimeValue.seconds(5))
.measurementTime(TimeValue.seconds(5))
.mode(Mode.AverageTime)
.syncIterations(false)
.build();
new Runner(opt).run();
}
@Benchmark
@Threads(1)
public void test1Thread() {
for (int i = 0; i < MAX; i++) {
currentTimeMillis();
}
}
@Benchmark
@Threads(2)
public void test2Thread() {
for (int i = 0; i < MAX; i++) {
currentTimeMillis();
}
}
@Benchmark
@Threads(4)
public void test4Thread() {
for (int i = 0; i < MAX; i++) {
currentTimeMillis();
}
}
@Benchmark
@Threads(8)
public void test8Thread() {
for (int i = 0; i < MAX; i++) {
currentTimeMillis();
}
}
@Benchmark
@Threads(16)
public void test16Thread() {
for (int i = 0; i < MAX; i++) {
currentTimeMillis();
}
}
@Benchmark
@Threads(32)
public void test32Thread() {
for (int i = 0; i < MAX; i++) {
currentTimeMillis();
}
}
@Benchmark
@Threads(64)
public void test64Thread() {
for (int i = 0; i < MAX; i++) {
currentTimeMillis();
}
}
@Benchmark
@Threads(128)
public void test128Thread() {
for (int i = 0; i < MAX; i++) {
currentTimeMillis();
}
}
private static long currentTimeMillis() {
return System.currentTimeMillis();
}
}
解法
最容易想到的方法是快取時間戳，並使用一個獨立的執行緒來更新它。這樣獲取就只是從記憶體中取一下，開銷非常小，但缺點也很明顯，更新的頻率決定了時間戳的精度。
Cobar
Cobar獲取和更新時間戳相關程式碼位於
/**
* 弱精度的計時器，考慮效能不使用同步策略。
*
* @author xianmao.hexm 2011-1-18 下午06:10:55
*/
public class TimeUtil {
private static long CURRENT_TIME = System.currentTimeMillis();
public static final long currentTimeMillis() {
return CURRENT_TIME;
}
public static final void update() {
CURRENT_TIME = System.currentTimeMillis();
}
}
定時排程程式碼位於
timer.schedule(updateTime(), 0L, TIME_UPDATE_PERIOD);
...
// 系統時間定時更新任務
private TimerTask updateTime() {
return new TimerTask() {
@Override
public void run() {
TimeUtil.update();
}
};
}
而Cobar中的更新間隔 TIME_UPDATE_PERIOD 是20毫秒
Sentinel
Sentinel也用到了快取時間戳，其程式碼位於
public final class TimeUtil {
private static volatile long currentTimeMillis;
static {
currentTimeMillis = System.currentTimeMillis();
Thread daemon = new Thread(new Runnable() {
@Override
public void run() {
while (true) {
currentTimeMillis = System.currentTimeMillis();
try {
TimeUnit.MILLISECONDS.sleep(1);
} catch (Throwable e) {
}
}
}
});
daemon.setDaemon(true);
daemon.setName("sentinel-time-tick-thread");
daemon.start();
}
public static long currentTimeMillis() {
return currentTimeMillis;
}
}
可以看到Sentinel實現的是每隔1毫秒快取一次。
我們修改一下測試程式碼測試一下Sentinel的實現方式在1-128執行緒下的效能表現
Benchmark Mode Cnt Score Error Units
TimeStampTest.test1Thread avgt ≈ 10⁻⁴ s/op
TimeStampTest.test2Thread avgt ≈ 10⁻⁴ s/op
TimeStampTest.test4Thread avgt ≈ 10⁻⁴ s/op
TimeStampTest.test8Thread avgt ≈ 10⁻³ s/op
TimeStampTest.test16Thread avgt 0.001 s/op
TimeStampTest.test32Thread avgt 0.001 s/op
TimeStampTest.test64Thread avgt 0.003 s/op
TimeStampTest.test128Thread avgt 0.006 s/op
可以和直接使用System.currentTimeMillis對比，差距非常明顯。
最後
雖然快取時間戳效能能提升很多，但這也僅限於非常高的併發系統中，一般比較適用於高併發的中介軟體，如果一般的系統來做這個優化，效果並不明顯。效能優化還是要抓住主要矛盾，解決瓶頸，切忌不可過度優化。
關於作者：專注後端的中介軟體開發，公眾號"捉蟲大師"作者，關注我，給你最純粹的技術乾貨