### [微基準測試](https://lingcoder.gitee.io/onjava8/#/book/16-Validating-Your-Code?id=%e5%be%ae%e5%9f%ba%e5%87%86%e6%b5%8b%e8%af%95) 寫一個計時工具類從而比較不同代碼塊的執行速度是具有吸引力的。看上去這會產生一些有用的數據。比如，這里有一個簡單的**Timer**類，可以用以下兩種方式使用它： 1. 創建一個**Timer**對象，執行一些操作然后調用**Timer**的**duration()**方法產生以毫秒為單位的運行時間。 2. 向靜態的**duration()**方法中傳入**Runnable**。任何符合**Runnable**接口的類都有一個函數式方法 \*\*run()\*\*，該方法沒有入參，且沒有返回。 ~~~ // onjava/Timer.java package onjava; import static java.util.concurrent.TimeUnit.*; public class Timer { private long start = System.nanoTime(); public long duration() { return NANOSECONDS.toMillis(System.nanoTime() - start); } public static long duration(Runnable test) { Timer timer = new Timer(); test.run(); return timer.duration(); } } ~~~ 這是一個很直接的計時方式。難道我們不能只運行一些代碼然后看它的運行時長嗎？ 有許多因素會影響你的結果，即使是生成提示符也會造成計時的混亂。這里舉一個看上去天真的例子，它使用了 標準的 Java**Arrays**庫（后面會詳細介紹）： ~~~ // validating/BadMicroBenchmark.java // {ExcludeFromTravisCI} import java.util.*; import onjava.Timer; public class BadMicroBenchmark { static final int SIZE = 250_000_000; public static void main(String[] args) { try { // For machines with insufficient memory long[] la = new long[SIZE]; System.out.println("setAll: " + Timer.duration(() -> Arrays.setAll(la, n -> n))); System.out.println("parallelSetAll: " + Timer.duration(() -> Arrays.parallelSetAll(la, n -> n))); } catch (OutOfMemoryError e) { System.out.println("Insufficient memory"); System.exit(0); } } } /* Output setAll: 272 parallelSetAll: 301 ~~~ **main()**方法的主體包含在**try**語句塊中，因為一臺機器用光內存后會導致構建停止。 對于一個長度為 250,000,000 的**long**型（僅僅差一點就會讓大部分機器內存溢出）數組，我們比較了**Arrays.setAll()**和**Arrays.parallelSetAll()**的性能。這個并行的版本會嘗試使用多個處理器加快完成任務（盡管我在這一節談到了一些并行的概念，但是在[并發編程](https://lingcoder.gitee.io/onjava8/#/./24-Concurrent-Programming)章節我們才會詳細討論這些 ）。然而非并行的版本似乎運行得更快，盡管在不同的機器上結果可能不同。 **BadMicroBenchmark.java**中的每一步操作都是獨立的，但是如果你的操作依賴于同一資源，那么并行版本運行的速度會驟降，因為不同的進程會競爭相同的那個資源。 ~~~ // validating/BadMicroBenchmark2.java // Relying on a common resource import java.util.*; import onjava.Timer; public class BadMicroBenchmark2 { static final int SIZE = 5_000_000; public static void main(String[] args) { long[] la = new long[SIZE]; Random r = new Random(); System.out.println("parallelSetAll: " + Timer.duration(() -> Arrays.parallelSetAll(la, n -> r.nextLong()))); System.out.println("setAll: " + Timer.duration(() -> Arrays.setAll(la, n -> r.nextLong()))); SplittableRandom sr = new SplittableRandom(); System.out.println("parallelSetAll: " + Timer.duration(() -> Arrays.parallelSetAll(la, n -> sr.nextLong()))); System.out.println("setAll: " + Timer.duration(() -> Arrays.setAll(la, n -> sr.nextLong()))); } } /* Output parallelSetAll: 1147 setAll: 174 parallelSetAll: 86 setAll: 39 ~~~ **SplittableRandom**是為并行算法設計的，它當然看起來比普通的**Random**在**parallelSetAll()**中運行得更快。 但是看上去還是比非并發的**setAll()**運行時間更長，有點難以置信（也許是真的，但我們不能通過一個壞的微基準測試得到這個結論）。 這只考慮了微基準測試的問題。Java 虛擬機 Hotspot 也非常影響性能。如果你在測試前沒有通過運行代碼給 JVM 預熱，那么你就會得到“冷”的結果，不能反映出代碼在 JVM 預熱之后的運行速度（假如你運行的應用沒有在預熱的 JVM 上運行，你就可能得不到所預期的性能，甚至可能減緩速度）。 優化器有時可以檢測出你創建了沒有使用的東西，或者是部分代碼的運行結果對程序沒有影響。如果它優化掉你的測試，那么你可能得到不好的結果。 一個良好的微基準測試系統能自動地彌補像這樣的問題（和很多其他的問題）從而產生合理的結果，但是創建這么一套系統是非常棘手，需要深入的知識。