當前使用量最大的 Java 版本是 8，所以測試者用 Java 8 與 Java 11 進行對比測試。

GC 是影響 Java 性能的關鍵因素，所以測試自然也基於 GC，在 G1 GC 和並行 GC 下分別進行了測試，結果如下：

Java 8 vs. Java 11

使用 G1 GC

G1 GC 下每秒分值：

Java 11 在幾乎所有測試數據集上都有速度上的提升。

平均而言，僅通過切換到 Java 11 就有 16％ 的改進，這種改進可能是因為 Java 10 中引入了 JEP 307: Parallel Full GC for G1。

使用並行 GC

並行 GC 下每秒分值：

使用並行 GC，結果不如 G1，某些數據集上有所改進，但其它數據集保持不變甚至出現性能下降。平均而言，Java 11 的性能提升了 4％ 以上。

測試者還在 Java 11 上對並行 GC 與 G1 GC 進行對比：

Java 11 上並行 GC vs. G1 GC

結果表明 G1 GC 整體上不如並行 GC。

OptaPlanner 表示，從 Java 8 到 Java 11，G1 GC 的平均速度改進為 16.1％，並行 GC 為 4.5％。

此外雖然並行 GC 面向吞吐量，而 G1 則側重於低延遲 GC，但是 Java 11 中帶來的 G1 顯著改進，使得將兩者進行直接比較是有意義的。

此外，基於基準測試中的大多數數據集來看，並行 GC 還是更適合 OptaPlanner 的，因為吞吐量對於解決 OptaPlanner 的優化問題更為重要。

拓展

關於OptaPlanner介紹

<code>它本來是一個名叫Geoffrey De Smet的大牛自己寫的，
後來他就把它貢獻給了JBoss基金會(這裡省去了N年的曲折離奇, N >= 10)，
併成為KIE項目組中OptaPlanner項目的負責人。所以OptaPlanner是基於Apache2.0開源協議的，
對商業友好，就是說你想用就儘管用，有問題還可以在他們的討論組上求助。
/<code>

<code>作用
　　OptaPlanner用官方的描述就是可以幫你規劃出一個用更少的資源做更多更好事情的規劃引擎。
  如下圖列出它可以做的工作領域（這僅僅是OptaPalnner的Example裡有的示例，
  其實所有關於規則的問題，屬於NPC的問題，只要你能把它抽象並建模成OptaPlanner可識別的模型，
  你就可以用OptaPlanner來解決）：車輛調度、工作排程、設備排程，Bin Packing(就是用袋子裝
  石頭那個問題啦)及員工排班。/<code>

構架和應用兼容性

<code>原理
　　那麼OptaPlanner是通過什麼方法，高效地幫我們在儘量短的時間內，
  找到更佳的方案呢？還記得上一任篇老農提到，我們做排程的時候，通常有兩種約束條件，
  分別是不可違反的硬約束，如果一個計劃違反了硬約束，那這個計劃就是不可行的，
  例如：生產計劃中，把產品固定工序的加工次序調亂了，又或者把產品分配到錯誤的機臺上生產
  (這些約束條件都是業務上你們自己定義的)，那麼OptaPlanner就把它定義為違反了硬約束。
  另一類就是軟約束，就是那種可以違反，但違反得越多，就會影響越大（影響包括成本、效率、質量等），
  所得結果方案的質量越差；違反這種約束，OptaPlanner就把它定義為違反了軟約束。
  OptaPlanner就是對這兩類約束進行打分，硬約束對應的是硬分數，軟約束對應的是軟分數。
  那麼得分越高，就表示對應方案的質量越高。在計算這些約束分數的過程中，OptaPlanner會保持優先
  優化硬分數、然後在硬分數最優的基礎上，再去優化軟分數的原則，來尋找最佳方案。 

  例如：兩個方案A、B對比，方案A的硬分數比方案B的硬分數高1分，方案B的軟分數比方案A的軟高出
  10萬分。那麼OptaPlanner最後還是認為方案A更佳。也就相當於我們寫SQL腳本時，
  order by子句中前後兩個字段的關係了，靠前的字段排序比靠後的字段更優先。
/<code>

這裡有篇文章講：https://www.oschina.net/news/75942/a-decade-of-optaplanner

閱讀更多 達升笑聊IT 的文章

關鍵字: 使用量 效率 腳本語言