有時候我們需要寫一些簡單的性能測試代碼，恰好在stackoverflow上看到一篇經驗之談，https://stackoverflow.com/questions/504103/how do i write a correct micro benchmark in java， 怎樣寫基準測試來儘量屏 ...
有時候我們需要寫一些簡單的性能測試代碼，恰好在stackoverflow上看到一篇經驗之談，https://stackoverflow.com/questions/504103/how-do-i-write-a-correct-micro-benchmark-in-java， 怎樣寫基準測試來儘量屏蔽掉環境的影響。
翻譯出來貼在這兒：
來自Java HotSpot作者的撰寫微基準的提示：
規則0：閱讀有關JVM和微型基準測試的好論文。比如https://www.ibm.com/developerworks/java/library/j-jtp02225/。不要對這種測試有太高的期望;它們對JVM性能的測試僅能起到有限效果。
規則1：始終包含一個預熱階段，它一直運行，直到觸發所有的初始化和編譯。 （預熱階段的迭代次數可以減少，經驗法則是幾萬次迴圈。）
規則2：始終使用-XX：+ PrintCompilation，-verbose：gc等參數來運行，這樣可以確定編譯階段和JVM的其他部分在計時時是否進行了一些意外的工作。
規則2.1：在計時和預熱階段的開始和結束列印消息，這樣可以確定計時時是否有規則2的輸出。
規則3：瞭解-client與-server之間的區別，還有OSR和常規彙編之間的區別。 -server優於-client, 常規編譯優於OSR
規則4：註意初始化的影響，第一次計時不要列印結果，除非是在測試類載入的過程，規則2是你對抗這種效果的第一道防線。
規則5：註意編譯器優化和重新編譯的效果。計時時不要使用任何代碼路徑，因為編譯器可能會基於一些樂觀假設進行優化，導致根本不會使用該路徑，從而可以對代碼進行垃圾和重新編譯。規則2是你對抗這種效果的第一道防線。
規則6：使用適當的工具讀取編譯器的工作過程，並對它產生一些令人驚訝的代碼做好。在形成關於什麼使事情更快或更慢的理論之前自己檢查代碼。
規則7：減少測量中的噪音。在一臺安靜的機器上運行基準測試，並運行幾次，拋棄異常值。使用-Xbatch將編譯器與應用程式串列化，並考慮設置 -XX：CICompilerCount = 1以防止編譯器與其自身並行運行。
規則8：使用一些庫用來做基準測試，因為它可能更有效率。比如JMH，Caliper，UCSD Benchmarks for Java等。
