OpenJDK 8 有多種 GC（Garbage Collector）算法，如 Parallel GC、CMS 和 G1。哪一個(gè)才是最快的呢？如果在 Java 9 中將 Java 8 默認(rèn)的 GC 從 Parallel GC 改為 G1 （目前只是建議）將會怎么樣呢？讓我們對此進(jìn)行基準(zhǔn)測試。

基準(zhǔn)測試方法

運(yùn)行相同的代碼六次，每次使用不同的VM參數(shù)（-XX:+UseSerialGC, -XX:+UseParallelGC, -XX:+UseConcMarkSweepGC, -XX:ParallelCMSThreads=2, -XX:ParallelCMSThreads=4, -XX:+UseG1GC）。

每次運(yùn)行大概花費(fèi)55分鐘。

其它VM參數(shù)：-Xmx2048M -server

OpenJDK版本：1.8.0_51（當(dāng)前***的版本）

軟件：Linux version 4.0.4-301.fc22.x86_64

硬件：Intel? Core? i7-4790 CPU @ 3.60GHz

每次運(yùn)行13個(gè)?OptaPlanner?規(guī)劃問題方案。每次運(yùn)行時(shí)間為5分鐘。前30秒用于JVM預(yù)熱，不計(jì)算在內(nèi)。

解決規(guī)劃問題不涉及 IO （除了啟動時(shí)需要幾毫秒來加載輸入信息）。單個(gè) CPU 使用完全飽和。通常會創(chuàng)建許多存活時(shí)間很短的對象，GC 之后就會回收這些對象。

衡量標(biāo)準(zhǔn)可以是計(jì)算每毫秒的得分，越高越好。計(jì)算一個(gè)擬議規(guī)劃解決方案是一個(gè)不可小覷的問題：涉及到大量的計(jì)算，包括每個(gè)實(shí)體與其他所有實(shí)體的沖突檢測。

為了能在本地重復(fù)運(yùn)行這些基準(zhǔn)測試，可以從源碼進(jìn)行構(gòu)建，然后運(yùn)行主類 GeneralOptaPlannerBenchmarkApp。

基準(zhǔn)測試結(jié)果

執(zhí)行結(jié)果

為了方便查看，我已經(jīng)對每種 GC 與 Java 8 默認(rèn) GC（Parallel GC）進(jìn)行了比較。

結(jié)果非常清楚：默認(rèn)（Parallel GC）是最快的。

原始基準(zhǔn)測試數(shù)據(jù)

相對基準(zhǔn)測試數(shù)據(jù)

Java 9 默認(rèn)應(yīng)該為 G1 嗎？

有一種提議是在 OpenJDK9 的服務(wù)器端使用 G1 作為默認(rèn) GC。我***反應(yīng)就是拒絕該提議：

G1 的平均值要慢17.60%

G1 在每個(gè)數(shù)據(jù)集用例下都比較慢。

在***數(shù)據(jù)集（Machine Reassignment B10）下，表現(xiàn)比其它數(shù)據(jù)集都要差，G1 慢了34.07%。

如果在開發(fā)機(jī)和服務(wù)器之間采用不同的默認(rèn) GC，則開發(fā)者基準(zhǔn)測試的可信度就會下降。

另一方面，存在幾個(gè)需要注意的細(xì)節(jié)：

G1 關(guān)注是 GC 暫停的問題，而不是吞吐量。對于這些用例（計(jì)算量比較大），GC 暫停時(shí)長基本沒影響。

這是一個(gè)（基本是）單線程的基準(zhǔn)測試。并行解決多個(gè)問題或采用多線程解決的基準(zhǔn)測試，結(jié)果可能不同。

G1 推薦的堆內(nèi)存至少是 6GB。而這次基準(zhǔn)測試的堆內(nèi)存是 2GB，即使在***數(shù)據(jù)集（Machine Reassignment B10）也只需要這么多內(nèi)存。

海量計(jì)算只是 OpenJDK 的諸多功能中的一個(gè)：這是在社區(qū)廣泛爭論的一個(gè)問題。如果有其他方面（如網(wǎng)站服務(wù)）的證明，可能值得改變默認(rèn)GC。但是，請首先向我展示你實(shí)際項(xiàng)目的基準(zhǔn)測試。

結(jié)論

在 Java 8 中，對 OptaPlanner 用例來說，默認(rèn) GC（Parallel GC）通常情況是***的選擇。