JVM垃圾回收方式性能研究

喬鑫 李志遠 程建軍

（浪潮電子信息產業股份有限公司 山東省濟南市 250000）

垃圾回收（Garbage Collection, GC）是Java 虛擬機（JVM）中使用的一種內存管理方案，它能夠不斷自動釋放內存中的不再被使用的對象，并按照特定的垃圾回收算法實現對于內存資源的管理。相較于C/C++手動內存管理方式，GC 的出現大大減少了開發人員在內存資源管理方面的工作，是JVM 的核心組成部分，并且對JVM 的性能有著重要的影響[1]。

隨著技術及硬件的發展，新的垃圾回收方式也在隨著JDK 版本的更新而被加入，如在JDK1.7 中正式引入了G1 回收器，JDK 11 中引入了Z 回收器等。面對如此多的垃圾回收器，如何在不同實際應用場景下中選擇最適合的是進行JVM性能優化的首要問題，解決這一問題則必須先了解不同垃圾回收方式的性能表現。以往也有相關方面的研究，但性能測試或基于SPEC JVM2008[2]又或是基于SPEC jbb2000[3-4]等一些現已不再提供支持的測試工具，已不能適應當前時代的需求，而通過一種權威且最新的基準測試工具分析不同垃圾回收器的性能表現是十分有意義的。

SPEC jbb（Java Business Benchmark）基準測試是標準性能評估組織SPEC 發布的一項用于衡量服務器Java 應用性能的測試基準。從2000 年6 月SPEC 組織發布第一版服務器Java 性能測試基準 SPEC jbb2000 至今，歷經了SPEC jbb2005（2006.1-2013.10）、SPEC jbb2013（2013.1-2014.12）多個版本的更新后，SPEC jbb2015（2015.9-至今）基于最新的Java 應用程序特性開發，支持虛擬化和云環境。現在SPEC jbb 測試已經發展成為JVM 廠商、Java 開發者，研究學者，以及相關學術機構評估Java 業務應用性能及可擴展性的一項權威基準測試標準[5]。

本文將首先從垃圾回收原理出發，分別介紹幾種垃圾回收器，然后對這幾種垃圾回收器在基準測試中的性能表現進行分析。

1 垃圾回收算法

Java 自動化的管理內存資源必須通過垃圾回收算法來確定哪些是有效的對象，哪些是無效的對象，對于無效的對象就要進行垃圾回收處理。作為垃圾回收器的實現基礎，下面先介紹常見的垃圾回收算法。

1.1 標記清除法

圖1：幾種垃圾回收器SPEC jbb2015 測試結果

圖2：幾種垃圾回收器平均停頓時間比較

在垃圾回收算法中，根是指向對象的指針的起點部分。通過根對象進行引用搜索，最終可達的對象被稱為可達對象；通過根對象進行引用搜索，最終沒有被引用的對象被稱為不可達對象。在標記階段，首先通從根節點開始標記所有的可達對象，不可達對象則為垃圾對象。在清除階段，清除所有未被標記的對象。由于清除時不考慮內存空間的連續性，因此標記清除法最大的問題是產生內存空間碎片。特別是在進行大對象內存分配時，相較于連續內存空間，內存碎片的存在會降低堆內存效率。

1.2 復制算法

復制算法將內存空間劃分為相等的兩部分，且每次只會只使用其中的一部分，當垃圾回收時，首先將使用中那部分內存里存活的對象復制到另一部分內存區，接著清除使用的內存塊中的所有對象，最后將兩個內存區進行互換，從而完成垃圾回收。復制算法在復制的過程中能夠有效避免內存空間碎片的產生，但代價是系統內存空間損失一半。

1.3 標記壓縮法

標記壓縮法是一種針對老年代的垃圾回收算法。對于老年代，由于大部分對象都是存活對象，使用復制算法代價將使內存折半，成本太高并不適用。標記壓縮法正是為了應對這種情況而產生，首先從根節點開始，對所有可達對象進行標記，然后將所有存活的對象壓縮到內存一端，再清理剩余的所有的空間。這種方法既避免了碎片的產生，又不需要將內存分為兩半，效率很高。

1.4 分區算法

分區算法將整個堆空間劃分成連續的不同小區間，每一小區間都獨立使用，獨立回收，并可以控制一次回收的小區間數量。一般來說，在相同條件下，堆空間越大，進行一次垃圾回收的所需的時間就越長，導致產生的停頓時間也越長。因此如果將堆內存分割成多個小塊，并根據目標停頓時間的要求，每次合理地控制回收部分小區間，而不是回收整個堆空間，則可以有效減小一次垃圾回收所產生的的停頓時間[6]。

2 幾種垃圾回收器

垃圾收集算法可以看作Java 虛擬機內存回收的抽象策略，而垃圾收集器則是其內存回收的具體實現。Java 虛擬機中，垃圾回收器不只一種，在不同的應用場景下如何選擇性能最佳的垃圾回收器是需要有清楚認識的，下面介紹幾種常見的垃圾回收器。

2.1 串行回收器

串行回收器是一種單線程垃圾回收器，在進行每次垃圾回收時，只有一個線程工作，Java 應用程序中的其他所有線程暫停，等待垃圾回收完成（“Stop-The-World”過程）。在實時性要求高的應用場景下，往往會造成用戶體驗不佳。串行回收器在新生代中使用復制算法，老年代中使用標記壓縮法。

2.2 并行回收器

并行回收器在串行回收器的基礎上做了改進，它使用多個線程同時進行垃圾回收，可以有效減少垃圾回收所需的時間。新生代中使用復制算法，老年代使用標記壓縮算法。并行回收器關注系統的吞吐量，可以通過-XX:MaxGCPauseMills 和-XX:GCTimeRatio 控制的垃圾回收最大停頓時間和吞吐量。但須指出的是，減少一次收集的最大停頓時間，就會同時減少系統吞吐量，增大系統吞吐量又可能會同時增加一次垃圾回收的最大停頓時間。

2.3 CMS回收器

CMS 回收器使用標記清除算法，利用多線程并行回收，主要側重于系統停頓時間。CMS 工作時首先經過初始標記與并發標記來標記出需要回收的對象、通過預清理做清理前的準備及控制停頓時間、再經過重新標記修正并發標記的數據、最后進行并發清除，以及并發重置為下次回收做準備[7]。

2.4 G1回收器

G1 回收器可以視為CMS 回收器的替代品，它使用了獨特的分區算法，相比于之前介紹的垃圾回收器將堆內存劃分為固定內存大小的年輕代、老代和永久代（JDK1.8 后被元空間取代），G1 回收器將堆分割成一組大小相等的區域，每個區域是一個連續的虛擬內存范圍，某些區域被功能與年輕代老年代相同，但是它們沒有固定的大小，這為內存使用提供了更大的靈活性。在進行垃圾回收時，G1 回收器可以只選擇部分區域，且部分垃圾回收工作能與Java 應用程序并行，提高回收效率的同時相應降低停頓時間。G1 回收器雖然也使用標記清除法，但與CMS 不同的是G1 可以有效復制移動對象，消除了潛在的內存碎片問題。此外，G1 還允許用戶自行設定所需的暫停時間[8]。

2.5 Z回收器

ZGC 是從JDK11 中引入的一種新的支持彈性伸縮的低延遲垃圾收集器，主要實現了三大目標：停頓時間不超過10ms、停頓時間不隨堆或實時設置的大小而增加、支持從8MB 到16TB 的堆內存。ZGC 的一個核心設計原則是使用讀屏障（load barrier）和著色指針（colored pointer）。在Java 中加載對象的行為會受到讀屏障的影響，而著色指針具有供讀屏障使用的信息，它使ZGC 能夠查找、標記、定位和重新映射對象，這有助于降低垃圾回收的開銷并極大降低停頓時間，且對吞吐量影響最大不超過15%[9]。作為一個并發的垃圾收集器，ZGC 所有的工作都是在Java 應用程序線程執行時完成的，這極大地減少了垃圾回收對應用程序響應時間的影響。而且Z 回收器現在還處于持續開發階段，后續的開發目標是達到垃圾回收停頓時間不超過1ms。

3 垃圾回收器性能比較

SPEC jbb2015 測試模擬了一個典型的商業應用的三層架構環境中的中間層工作，包含商業邏輯、對象操作等，目的是衡量服務器Java 應用之性能。模型建立在一個全球型連鎖超市的IT 基礎架構之上，通過線上線下購物、庫存管理、供應鏈管理、用戶購買行為的數據挖掘等業務來評估整個系統的吞吐量及響應時間隨著整個系統業務量不斷增加時的性能表現[10]。SPECjbb2015 支持多種測試運行配置、支持虛擬化以及云環境，使用戶能夠全面分析和解決可能存在于包括硬件、操作系統、JVM 和應用程序層的性能瓶頸問題。

SPEC jbb2015 測試結果包含主要包含兩個測試指標Max-jOPS和Critical-jOPS。最大性能指標Max-jOPS 是系統最大每秒鐘處理的Java 操作數，可以看做在業務響應不失敗的情況下，服務器的極限吞吐量，反映的是系統極限Java 應用性能。關鍵性能指標Critical-jOPS 是系統在5 個關鍵SLA（服務水平協議）10ms，25ms，50ms，75ms 和100ms 響應時間下平均每秒Java 操作數。 選擇這些點是為了保證不同行業使用的響應時間目標的合理分布，可以看做衡量的是在響應時間有限的情況下的系統吞吐量。

測試環境選擇使用四路服務器，配置4 顆Intel Xeon Platinum 8180 CPU，物理內存大小為1536G，操作系統為Red Hat Enterprise Linux 7.6，使用JDK 版本為Oracle Java SE 13.0.2，在此環境下分別使用-XX:+UseSerialGC（串行回收器）、-XX:+UseParallelOldGC（并行回收器）、-XX:+ UseConcMarkSweepGC（CMS 回收器）、-XX:+UseG1GC（G1 回 收 器）、-XX:+UseZGC（ZGC）， 運 行SPEC jbb2015 測試，并使用參數-XX:+PrintGCDetails、-Xlog:gc.log 輸出垃圾回收詳細日志[11]。

圖1 反映了幾種垃圾回收器在SPEC jbb2015 基準測試中的性能表現，可以看出在極限性能指標Max-jOPS 上，并行回收器ParallelOldGC 表現最好，這是由于Max-jOPS 代表系統極限吞吐量而并行回收器在所有垃圾回收器中最側重于吞吐量，因此這一指標明顯優于其他垃圾回收器。而在關鍵性能指標上，ZGC 的表現最好，證明在一些有特定響應時間要求的業務場景下，其綜合性能最好。ZGC 由于低停頓時間的特性，每次垃圾回收停頓時間不會超過10ms，這要遠遠低于其他垃圾回收方式（見圖2）。一般來說，停頓時間的減少但帶來的影響必然是吞吐量的降低，ZGC 垃圾回收處理工作都在與應用線程并發執行，同時也會不可避免地占用很多CPU 并發工作導致吞吐量降低。但如果同時考慮低響應時間與吞吐量情況下，ZGC 吞吐量降低的程度在可接受的范圍之內，但同時其停頓時間減少了一個量級，因此其綜合性能表現更好。

圖2 展示了幾種垃圾回收方式的平均停頓時間。

其中ZGC 的停頓時間最短，看到ZGC 雖然目標定位在停頓時間不超過10ms，但在實際測試時ZGC 平均停頓時間約為2ms，要遠遠低于10 毫秒的目標。串行回收器的停頓時間最長，幾乎達到秒級，這是由于串行回收器回收時只有單線程，因此停頓的時間要遠遠高于其他垃圾回收器，因此在實際業務模型中性能很差。而并行回收器、G1 回收器平均停頓時間相差不大，都在100ms 上下，CMS 回收器則平均在200ms 左右。

4 結語

本文簡述了幾種常用的JVM 垃圾回收方式及其原理，并利用業內權威的Java 應用性能測試工具SPEC jbb2015 測試了幾種垃圾回收方式的實際性能。因為SPEC jbb2015 測試模型則具有廣泛的代表性，所以對基于此項測試對垃圾回收的研究有助于開發者在實際應用中合理地對性能進行調優并解決性能問題。根據SPEC jbb2015 測試結果來看，當側重于追求最大吞吐量，如基于Java的后臺計算型應用、事務處理時，并行垃圾回收器ParallelOldGC表現更好。如追求低停頓時間，快速響應如互聯網應用、web前端等時ZGC 優勢明顯，或者也可以使用G1 垃圾回收器配合-XX:MaxGCPauseMillis 參數來限制最大垃圾回收停頓時間。且ZGC 所支持的超大內存也非常適合需要大量內存的應用程序，比如大數據應用程序。但由于實際業務性能考量標準不同，還需結合每種垃圾回收方式自身特點，合理進行選擇[12]。