如果你想寫自己的Benchmark框架
阿新 • • 發佈：2020-07-11
[toc]
# 簡介
使用過JMH的同學一定會驚歎它的神奇。JMH作為一個優秀的Benchmark框架帶給了我們無數的歡樂。作為一個有極客精神的程式設計師，那麼有沒有想過去自己實現一個Benchmark框架呢？
在實現Benchmark框架的時候有需要注意些什麼問題呢？快來一起看看吧。
# 八條軍規
這裡叫軍規實際上不合適，只是借用一下軍規的來彰顯一下氣勢！大家不要太介意。
## 第一條軍規
工欲善其事，必先利其器。想寫好一個JMH當然需要深入瞭解JVM的執行原理，包括JIT，C1，C2編譯器和他們的分層編譯原理，JIT執行時的編譯優化，包括Loop unrolling, Inlining, Dead Code Elimination,
Escape analysis, Intrinsics, Branch prediction等等。
當然，最好是參考一下大牛們寫過的JMH框架，找點靈感。
最後大家要了解，Benchmark框架不是萬能的。它只是在特定的環境中JVM的表現。
因為在Benchmark中我們肯定是要做迴圈的，一般來說就是某某方法執行多少次，這種比較簡單的迴圈。實際上，JVM執行的程式碼是非常複雜的。Benchmark遠遠不能代表JVM的全部。
但是，見微知著，使用Benchmark還是可以一窺JVM的祕密的。
## 第二條軍規
在JMH中，我們一般需要設定warmup和measurement的次數：
~~~java
@Warmup(iterations = 10, time = 1, timeUnit = TimeUnit.SECONDS)
@Measurement(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
~~~
這是為什麼呢？我們知道JIT中的程式碼是動態編譯成為機器碼的，並且是需要一定的時間的。
只有JIT檢測到你這是熱點程式碼，才會對其進行優化。
我們檢測程式碼的效能，一般是指程式碼在穩定執行的環境中的情形。而不是指第一次或者前幾次執行的時候，因為這個時候，這些程式碼可能並沒有被編譯成機器碼。這樣的出來的結果往往是和實際不相符的。
## 第三條軍規
在編寫Benchmark的同時，一定要開啟JVM的日誌。例如： -XX:+PrintCompilation, -verbose:gc等。
為什麼呢？
大家想想benchmark是做什麼的呢？就是統計時間的。
我們希望在執行benchmark的時候，JVM不要做任何不屬於執行程式碼的任何事情，否則就可能會影響到benchmark的準確性。
所以開啟JVM的日誌就是為了做校驗。不要在做benchmark的時候有其他操作。
## 第四條軍規
注意JIT的分層編譯。
因為Client VM和Server VM的出現，所以在JIT中出現了兩種不同的編譯器，C1 for Client VM， C2 for Server VM。
因為javac的編譯只能做少量的優化，其實大量的動態優化是在JIT中做的。C2相對於C1，其優化的程度更深，更加激進。
為了更好的提升編譯效率，JVM在JDK7中引入了分層編譯Tiered compilation的概念。
對於JIT本身來說，動態編譯是需要佔用使用者記憶體空間的，有可能會造成較高的延遲。
對於Server伺服器來說，因為程式碼要服務很多個client，所以磨刀不誤砍柴工，短暫的延遲帶來永久的收益，聽起來是可以接受的。
Server端的JIT編譯也不是立馬進行的，它可能需要收集到足夠多的資訊之後，才進行編譯。
而對於Client來說，延遲帶來的效能影響就需要進行考慮了。和Server相比，它只進行了簡單的機器碼的編譯。
為了滿足不同層次的編譯需求，於是引入了分層編譯的概念。
大概來說分層編譯可以分為三層：
1. 第一層就是禁用C1和C2編譯器，這個時候沒有JIT進行。
2. 第二層就是隻開啟C1編譯器，因為C1編譯器只會進行一些簡單的JIT優化，所以這個可以應對常規情況。
3. 第三層就是同時開啟C1和C2編譯器。
在JDK7中，你可以使用下面的命令來開啟分層編譯：
~~~java
-XX:+TieredCompilation
~~~
而在JDK8之後，恭喜你，分層編譯已經是預設的選項了，不用再手動開啟。
Client編譯和Server編譯，甚至是OSR都是不同的。大家在寫Benchmark的時候一定要注意。
## 第五條軍規
注意初始化對效能的影響。
如果需要載入類，一定要在warmup的階段進行載入，除非你是想去測試載入的時間。否則會對測試結果有影響。
同時也不要計算第一次print的時間，因為print也會載入和初始化一些類。
## 第六條軍規
要注意反優化和重編譯的影響。
JIT在下面的幾個特殊的情況下，需要對程式碼進行返優化：
有些特殊的情況下面，確實是需要進行反優化的。
下面是比較常見的情況：
1. 需要除錯的情況
如果程式碼正在進行單個步驟的除錯，那麼之前被編譯成為機器碼的程式碼需要反優化回來，從而能夠除錯。
2. 程式碼廢棄的情況
當一個被編譯過的方法，因為種種原因不可用了，這個時候就需要將其反優化。
3. 優化之前編譯的程式碼
有可能出現之前優化過的程式碼可能不夠完美，需要重新優化的情況，這種情況下同樣也需要進行反優化。
重編譯是指JIT可能會重新優化程式碼，導致重新編譯。
所以這條規則要求我們warmup的時間要儘可能的長。以便讓JIT充分優化。
## 第七條軍規
在使用benchMark得出結論之前，一定要去認真的理解JVM的底層程式碼（Assembly code），找到其現象的本質。
千萬不要衝動的下結論。最好是使用視覺化的工具來分析。比如說jitwatch。
## 最後一條軍規
在測試的時候一定要避免其他程式的影響 。
比如說兩次測試，第一次測試是單機執行，第二次測試是在有其他服務正在執行的情況下進行的。
很顯然這兩次的結果是不能做比較的。我們需要多執行，剔除噪音結果。
# 總結
掌握上面幾條規則，相信大家也能夠寫出屬於自己的Benchmarks。
> 本文連結：[http://www.flydean.com/how-to-write-benchmarks/](http://www.flydean.com/how-to-write-benchmarks/)
>
> 最通俗的解讀，最深刻的乾貨，最簡潔的教程，眾多你不知道的小技巧等你來發現！
>
> 歡迎關注我的公眾號:「程式那些事」,懂技術，更懂你！
