[[326097]]

在 Java 8 中，HotSpot 虛擬機(jī)的默認(rèn)垃圾回收器是 ParallelOld。在 Java 11 中，默認(rèn)回收器變成了 G1。

注意：從技術(shù)上講，回收器的切換是在 Java 9 中進(jìn)行的，但 G1 的主要增強(qiáng)是在 Java 10 和 11 中完成的。但實際上，很少有公司使用 Java LTS 以外的版本。

在本文中，我們將討論垃圾回收理論的一些基礎(chǔ)知識，以及這些理論在 HotSpot 中是如何實現(xiàn)的。這也將解釋為什么要切換 Java 的默認(rèn)垃圾回收器，以及 Java 垃圾回收方法在近來發(fā)生的一些變化。

1. 基本概念

垃圾回收是系統(tǒng)的一種“清理”活動，獨立于應(yīng)用程序的主處理線程，試圖找出不再被使用的內(nèi)存并將其釋放以便可以繼續(xù)重用。

Dijkstra 對垃圾回收的定義清晰地指出，引用計數(shù)是自動內(nèi)存管理的一種形式，但不屬于垃圾回收。

引用計數(shù)會在程序運行時更新每個對象的元數(shù)據(jù)（例如，在對一個引用類型對象的某個字段賦值時）。元數(shù)據(jù)的更新需要在應(yīng)用程序線程上進(jìn)行，因此不能清晰地將其劃分為獨立的活動。

回收算法從 root（一組已知是存活對象）開始，通過跟蹤指針來確定存活對象。

這些跟蹤回收器實現(xiàn)了圖算法，將堆內(nèi)存劃分為存活的和可回收的。

在現(xiàn)代垃圾回收文獻(xiàn)中，并發(fā)（Concurrent）和并行（Parallel）都被用來描述回收算法。它們聽起來像是同義詞，但實際上有著完全不同的含義：

• 并發(fā)——回收線程獨立于應(yīng)用程序線程運行；
• 并行——使用多個線程來執(zhí)行垃圾回收算法。

它們可以被看成是另外兩個術(shù)語的對立面——并發(fā)是 stop-the-world（STW）的對立面，并行是 single-thread（單線程）的對立面。

實際的垃圾回收器分為多個階段，每個階段還可能具備多種特征。

例如，某個階段可能是單線程并發(fā)，或者是并行 STW。

注意：并發(fā)回收器比 STW 回收器要復(fù)雜得多。它們在計算開銷方面要大得多，而且它們的行為還有需要注意的地方。

其他你應(yīng)該知道的垃圾回收術(shù)語：

• Exact——Exact 回收器擁有足夠的類型信息，能夠區(qū)分 int 和指針之間的區(qū)別。
• 驅(qū)逐（Evacuate）——移動（驅(qū)逐）存活對象到內(nèi)存的另一個區(qū)域。在回收周期結(jié)束時，源內(nèi)存區(qū)域變成空的，可以被重用。
• 壓縮（Compact）——在回收周期結(jié)束時，存活的對象被連續(xù)地放在內(nèi)存的前部區(qū)域，剩下的區(qū)域可被重用。

Exact 是一種保守模式，缺乏精確的信息，因此通常會造成更大的內(nèi)存浪費。

一些資料還提到了移動回收器——包括壓縮和驅(qū)逐算法。但這兩種類型之間的差異太大，把它們組合在一起通常用處不大。

非移動回收器被稱為就地回收器。這些算法需要知道可用內(nèi)存塊的列表才能夠處理內(nèi)存碎片以及合并可用的內(nèi)存塊。

2. HotSpot 中的一些設(shè)計考慮

我們從定義開始，先來考慮一些基本的事實：

• 移動回收器分配的對象在其生命周期期間沒有穩(wěn)定的內(nèi)存地址。
• 壓縮回收器可用避免出現(xiàn)內(nèi)存碎片。
• 驅(qū)逐回收器也可以避免內(nèi)存碎片化，并可以實現(xiàn)對存活對象進(jìn)行部分壓縮。
• 如果堆只由一個內(nèi)存池組成，則無法使用驅(qū)逐算法回收。

分代假設(shè)基于對面向?qū)ο笙到y(tǒng)運行時行為的觀察，它大致將對象分為兩類：短期的臨時對象和用于執(zhí)行程序任務(wù)的長期對象。

注意：分代回收器并不一定總是比非分代回收器更高效，但幾乎所有的應(yīng)用程序都會從分代回收器中獲得好處。

回收算法的 mark-sweep-compact（根據(jù) Blackburn 和 McKinley）是這樣定義的：

• 標(biāo)記（Mark）：通過跟蹤對象圖來識別存活的對象。
• 清掃（Sweep）：讓存活對象留在原地，同時識別出可釋放的空間。
• 驅(qū)逐（Evacuate）：將存活對象轉(zhuǎn)移到另一個內(nèi)存池，以此來釋放空間。
• 壓縮（Compact）：通過移動同一內(nèi)存池中的存活對象來釋放空間。

在分代回收算法中，年輕代回收器和老年代回收器通常使用的是完全不同的算法。

這導(dǎo)致我們很難準(zhǔn)確地對不同階段采用不同算法的回收器進(jìn)行歸類。例如，在 CMS 中，年輕代是通過驅(qū)逐算法那進(jìn)行回收的，而老年代是通過標(biāo)記清除算法進(jìn)行回收的，如果并發(fā)回收失敗（例如由于碎片），則退回到標(biāo)記壓縮算法。

3. HotSpot 中的年輕代垃圾回收

在 HotSpot 中，傳統(tǒng)的回收器將內(nèi)存劃分為 4 個內(nèi)存池，分別是 Eden、Survivor 0、Survivor 1 和 Tenured。前三個被統(tǒng)稱為年輕代，Tenured 是老年代。

年輕代空間是在年輕代回收周期中進(jìn)行回收的，使用了并行 STW 驅(qū)逐算法, 將存活的對象轉(zhuǎn)移到一個空間。

回收算法在當(dāng)前活動的內(nèi)存池中標(biāo)記存活的對象，然后將其撤到非活動的內(nèi)存池中。在回收結(jié)束時，兩個空間被顛倒過來——活動的內(nèi)存池變?yōu)榉腔顒拥模礊榭眨腔顒拥淖優(yōu)榛顒拥摹Ｓ袝r候這也被叫作“半球”（hemispehric）回收。

半球回收可能會浪費內(nèi)存。單遍算法無法預(yù)先知道正在回收的內(nèi)存區(qū)域中有多少對象是存活的。這意味著用于存放驅(qū)逐對象的區(qū)域必須和被清理的區(qū)域一樣大——因此算法需要兩倍于實際存活對象大小的內(nèi)存空間。

它還意味著不管在什么時候都有一半的空間是空的。這些特點導(dǎo)致它不適用于現(xiàn)代工作負(fù)載的老年代垃圾回收，因為這些老年代的對象集合可能很大：實際上，在生產(chǎn)環(huán)境中，HotSpot 回收器不會使用半球回收算法。

半球回收算法被用于回收年輕代。它非常適用于符合分代假設(shè)的工作負(fù)載——即內(nèi)存區(qū)域里大部分都是垃圾對象。回收器受益于這樣的一個事實：存活對象總是從年輕代被提升到老年代。

驅(qū)逐回收器的另一個主要優(yōu)點是它們處理空閑空間的方式。最簡單的方法是使用指向空閑空間的指針，當(dāng)存活對象被驅(qū)逐時，很“自然”地被壓縮。

驅(qū)逐算法是 OpenJDK 年輕代回收器的典型算法，它使用了對象跟蹤。不過，回收只在一個階段中進(jìn)行，沒有單獨的標(biāo)記、清除或壓縮階段。

4. 分代假設(shè)的后果

對象的生存期通常是未知的，而且在實際應(yīng)用程序中會動態(tài)發(fā)生變化。因此，追蹤對象的實際生存周期是不可行的。

相反，HotSpot 記錄了對象在垃圾回收過程中存活下來的次數(shù)，只需要在對象頭部的元數(shù)據(jù)里添加幾個比特的信息，在對象經(jīng)歷了足夠多的垃圾回收之后，它就會被移動（提升）到更老的一代，由不同的垃圾回收器來管理。

這種機(jī)制與應(yīng)用程序的內(nèi)存分配速度存在一種有趣的交互。如果分配速度加快，那么年輕代將更快被填滿——但“短命對象”的預(yù)期壽命（以毫秒為單位）保持不變。

這可能會導(dǎo)致更多對象在回收周期中存活下來，從而導(dǎo)致年輕代空間充滿了還沒有資格提升到老年代的對象。在這種情況下，JVM 別無選擇，只能提前提升一些對象——這導(dǎo)致了“過早提升”。

很多這樣的對象實際上都是短命的，在進(jìn)入老年代后很快就會消失。可惜的是，JVM 沒有回收它們的機(jī)制，要等到老年代空間的下一個回收周期才能回收它們。

5. 垃圾回收算法的復(fù)雜性

開發(fā)人員經(jīng)常對垃圾回收算法進(jìn)行復(fù)雜性分析（有時候也叫作“大 O”）。然而，在實踐當(dāng)中，這種做法實際上并不是很令人滿意。

他們可能天真地認(rèn)為標(biāo)記和壓縮階段的時間復(fù)雜度與活動對象集合的大小成線性關(guān)系，而清除階段與整個堆大小成線性關(guān)系。

然而，即使不考慮在實際實現(xiàn)當(dāng)中可能無法清晰地進(jìn)行階段隔離（如上面討論的 HotSpot 年輕代回收器），仍然存在一個更深層次的問題。

垃圾回收本質(zhì)上是一種通用算法。這意味著大 O 分析中的固有假設(shè)——當(dāng)數(shù)據(jù)集增大時，起作用的是限制性行為——是不正確的。

生產(chǎn)環(huán)境中的算法需要在面對所有可能的輸入和工作負(fù)載表現(xiàn)出可接受的行為。它們的漸近性行為與整體性能是不匹配的。

換句話說，活動對象集合和堆大小本質(zhì)上是獨立變化的（例如，不同的對象圖拓?fù)?。這意味著對于不同的工作負(fù)載，縮放因子會產(chǎn)生非常不一樣的效果。

例如，壓縮時需要復(fù)制字節(jié)，因此，盡管壓縮階段在活動對象集合的大小上是呈線性的，但其他因素可能與要移動的對象大小有關(guān)。對于包含大量元素的大數(shù)組，這種說法就更加站不住腳。

對于各種不同形式的回收算法，還存在一些眾所周知的二級效應(yīng)。例如，在對只有少量存活對象的內(nèi)存區(qū)域（“稀疏堆”）執(zhí)行壓縮時，活動的對象將被合并到更密集的區(qū)域。如果對象的生命周期很長，那么這個區(qū)域?qū)τ诤罄m(xù)的回收周期來說就不那么稀疏了。

我們可以看到，與 CMS 之類的就地回收器相比，在程序的整個生命周期中，長壽對象將保持稀疏分布。事實上，隨著時間的推移，空閑空間將變得越來越碎片化，空閑內(nèi)存塊列表的管理將變得越來越昂貴。

總的來說，不同回收方法的時間和空間成本模型是不同的，簡單的算法復(fù)雜度分析也不是很管用。在 HotSpot 中，如果沒有足夠的連續(xù)空間，就地回收器最終會退回到壓縮回收器。

6. 總結(jié)

我們討論了 Java 虛擬機(jī)的垃圾回收機(jī)制。垃圾回收是計算機(jī)科學(xué)的一個成熟的領(lǐng)域，HotSpot 的垃圾回收器經(jīng)過了良好的測試，可以很好地處理大堆工作負(fù)載。大多數(shù) Java 應(yīng)用程序不需要過多地?fù)?dān)心垃圾回收行為。

如果對垃圾回收行為較為敏感，那么深入了解垃圾回收的原則（以及它在 JVM 中是如何實現(xiàn)的）對于開發(fā)人員來說會很有幫助。

在最近的 Java 版本中，垃圾回收子系統(tǒng)的改進(jìn)再次成為關(guān)注的熱點。要完全理解這些變化，就要很好地掌握這些基礎(chǔ)知識。后續(xù)的文章將詳細(xì)討論這些更新，例如，為什么改變了默認(rèn)回收器、這對升級到 Java 11 的團(tuán)隊意味著什么。