OpenJDK微基準測試套件（OpenJDK Microbenchmark Suite，JEP 230）基於Java Microbenchmark Harness（JMH），是JDK 12版本的一個新特性。JEP 230的目標在於提供一個穩定且經過優化的基準，其中包括了近100個基準測試的初始集合（從jmh-jdk-microbenchmarks項目導入的，這是JMH基準測試的一個套件），並且還提升了編寫新基準測試和搜索已有基準測試的便利性。
微基準測試套件並不是像java、javac、jdeps和jconsole那樣的獨立JDK工具。相反，它的代碼是與JDK源碼放到一起的。如JEP 230的提案所述：
微基準測試套件的構建將會集成到常規的JDK構建系統中。它將會是一個獨立的target，在常規的JDK構建中並不會執行它，這樣的話，對微基準測試套件不感興趣的開發人員和其他人員就能保持較短的構建時間。
微基準測試，是衡量一小段Java代碼性能的藝術，如果沒有按照正確的方式實現的話，可能會導致不精確和/或誤導性的結果。要編寫正確的微基準測試，需要考慮很多的事情。在“Optimizing Java”一書的第5章，作者Ben Evans、James Gough和Chris Newland討論了編寫微基準測試所面臨的挑戰：
我們無法將正在執行的代碼與JIT編譯器、內存管理和Java運行時提供的其他子系統分離開來。同時，我們也不能忽視測試所運行的操作系統、硬件、運行時條件（如加載）等因素的影響。
甲骨文的Java語言架構師Brian Goetz在剖析有缺陷的基準測試時，這樣說到：
微基準測試的可怕之處在於，它們總能生成一個數字，即便這個數字毫無意義。它們的確測量了一些東西，只是我們並不能確定測試的是什麼。
通常，它們只度量了特定微基準測試的性能，僅此而已。但是很容易讓你相信你的基準測試度量了特定構造的性能，並錯誤地總結該構造的性能。
Aleksey Shipilëv是Red Hat的首席軟件工程師，在Twitter上是這樣迴應性能問題的：
任何脫離了反彙編/代碼生成分析的納基準測試（nanobenchmark）都是不可信的。
來自甲骨文的核心技術人員Claes Redestad與InfoQ討論了這個新的微基準測試套件。
InfoQ：創建這個微基準測試套件的最初動機是什麼？
Claes Redestad：多年以來，微基準測試就是OpenJDK開發過程的一部分，實際上微基準測試套件只是將微基準測試的使用更緊密地集成到OpenJDK開發過程中的漫長道路上的一個步驟。
作爲最初推動力的一部分，大多數（甚至可以說所有）微基準測試已經存在很長時間了，它們所依賴的 microbenchmark harness，即JMH，已經存在好多年了。唯一新鮮的事情是它們集成到了OpenJDK構建系統中和主OpenJDK倉庫中。
在構想這個JEP的時候，OpenJDK項目被分割到多個存儲庫和forest中，這使得編寫跨tree的測試(和微基準測試)非常麻煩。最初的JEP提案試圖爲這些微基準測試添加一個新的存儲庫，但這一努力最終擱淺了，部分原因在於人們對它是否值得這麼麻煩而產生了分歧。
在此之後，OpenJDK已經整合爲一個單獨的倉庫結構，很多單獨開發的測試套件也整合到了主倉庫中。該項目五年前面臨的很多障礙已經不復存在了。
最終繼續推進JEP 230提案的動機在於，將功能測試集成和整合（co-locate）到主OpenJDK倉庫的努力獲得了成功。作爲整合的測試套件，這並不意味着我們所做的所有基準測試都是基於整合的微環境（實際上，遠遠未實現）。但是，當我們要測試新的API，而這個API只在當前工作的分支上可用時，將這些測試全部集成到一個倉庫中是非常便利的。
InfoQ：爲什麼微基準測試套件不是一個單獨的工具呢（像 java、javac、jdpes和jconsole那樣）？
Redestad：實際上，JEP 230只提供了構建和運行微基準測試的方法，並將其作爲開發OpenJDK本身的一個組成部分，所以套件並沒有很自然地轉換爲適合包含到JDK交付物中的工具；這有點像我們不會把所有其他測試打包到JDK二進制下載文件中。
InfoQ：對於開發人員來說，開始使用微基準測試套件的最佳方式是什麼，比如說到哪裏去尋找源碼？
Redestad：我猜想，大多數的Java開發人員可能希望將微基準測試添加到自己的項目中，而不是貢獻給OpenJDK。因此，對他們來說，雖然微基準測試套件可能有助於尋找靈感，但我建議還是要先閱讀JMH。它提供了相當多的例子，並且很容易搭建一個項目並開始進行嘗試。Aleksey Shipilëv維持這個項目許多年了，並且提供了大量的資源。
如果你希望構建、測試OpenJDK，甚至想爲OpenJDK做出貢獻的話，那可以從https://openjdk.java.net/開始，通過http://hg.openjdk.java.net/jdk/jdk下載代碼，並閱讀http://hg.openjdk.java.net/jdk/jdk/raw-file/96d290a7e94f/doc/testing.html上的測試文檔。
InfoQ：關於微基準測試套件，你還有什麼要與我們的讀者分享的嗎？
Redestad：爲OpenJDK做出貢獻的一種方法是在你自己的CI中實際構建並運行這些微基準測試，並報告發現的迴歸結果。目前，有太多的硬件和系統配置，我們可能不會像你這樣在每次新增硬件時都運行所有可用的基準測試，所以你可能會發現我們無法檢測到的問題。
InfoQ：微基準測試套件的前景如何？
Redestad：目前，我正在尋求反饋，同時鼓勵更多的OpenJDK開發人員使用它，甚至改進它。我很高興地看到已經有新的微基準測試添加了進來，對特性集本身也有一些非常好的外部貢獻，比如添加對構建原生庫的支持（https://bugs.openjdk.java.net/browse/JDK-8219393）。
我希望我們能夠在細節上進行足夠多地改進，以便在開發新特性的時候，添加和運行微基準測試能夠像添加新的功能測試那樣簡單和自然。.
InfoQ：你目前的工作職責是什麼呢，換句話說，你日常都做些什麼？
Redestad：我的主要職責是幫助很多OpenJDK開發人員在性能方面按照正確的方式前進。對JEP 230的貢獻就是這種事情。在我們的夜間測試中進行迴歸檢測篩選則是我的另一項這樣的工作。
每天，我都會竭盡所能提供修復和改進。在過去的幾年裏，我從減少OpenJDK的啓動和內存佔用開銷中得到了很多樂趣，包括重構和改進內部lambda運行時，以獲取比JDK 8更短的引導時間。
除了微基準測試套件之外，JDK 12其他的新特性包括：體驗式的新垃圾收集器Shenandoah（JEP 189）、增強的switch語句（JEP 325）以及新的 JVM constants API（JEP 334）。
參考資源
- JMH - Java Microbenchmark Harness——來自Jenkov.com的一個教程
- Claes Redestad撰寫的JEP 230 - Microbenchmarks Suite（2018年11月16日）