垃圾回收算法（GC Algorithms）

JVM 根據(jù)對象生命周期特性（分代假設(shè)）采用不同的回收算法，核心算法包括：

標(biāo)記-清除（Mark-Sweep）

此算法執(zhí)行分兩階段。第一階段從引用根節(jié)點(diǎn)開始標(biāo)記所有被引用的對象，第二階段遍歷整個堆，把未標(biāo)記的對象清除。

• 流程??：標(biāo)記所有存活對象 → 清除未標(biāo)記對象。
• ??優(yōu)點(diǎn)??：簡單、無對象移動開銷。
• ??缺點(diǎn)??：內(nèi)存碎片化、效率較低（需遍歷兩次堆）。

復(fù)制算法（Copying）

此算法把內(nèi)存空間劃為兩個相等的區(qū)域，每次只使用其中一個區(qū)域。垃圾回收時，遍歷當(dāng)前使用區(qū)域，把正在使用中的對象復(fù)制到另外一個區(qū)域中。此算法每次只處理正在使用中的對象，因此復(fù)制成本比較小， 同時復(fù)制過去以后還能進(jìn)行相應(yīng)的內(nèi)存整理，不會出現(xiàn)“碎片”問題。當(dāng)然，此算法的缺點(diǎn)也是很明顯的，就是需要兩倍內(nèi)存空間。

• ?流程??：將存活對象復(fù)制到另一塊內(nèi)存區(qū)域 → 清空原區(qū)域。
• ??優(yōu)點(diǎn)??：無碎片、效率高（適用于存活率低的對象，如新生代）。
• ??缺點(diǎn)??：內(nèi)存利用率低（需預(yù)留一半空間）。

??標(biāo)記-整理（Mark-Compact）

此算法結(jié)合了“標(biāo)記-清除”和“復(fù)制”兩個算法的優(yōu)點(diǎn)。也是分兩階段，第一階段從根節(jié)點(diǎn)開始標(biāo)記所有被引用對象，第二階段遍歷整個堆，把清除未標(biāo)記對象并且把存活對象“壓縮”到堆的其中一塊，按順序排放。此算法避免了“標(biāo)記-清除”的碎片問題，同時也避免了“復(fù)制”算法的空間問題。

• 流程??：標(biāo)記存活對象 → 移動對象到內(nèi)存一端 → 清理邊界外內(nèi)存。
• ??優(yōu)點(diǎn)??：無碎片、內(nèi)存利用率高。
• ??缺點(diǎn)??：對象移動開銷大（適用于老年代）。

分代收集（Generational Collection）

• 核心思想??：根據(jù)對象存活時間劃分內(nèi)存區(qū)域（新生代、老年代）。
• ??新生代??：存活率低 → 使用復(fù)制算法（如 Serial、ParNew）。
• 老年代??：存活率高 → 使用標(biāo)記-清除或標(biāo)記-整理算法（如 CMS、G1）。

可達(dá)性算法（Reachability Analysis）

可達(dá)性算法（??Reachability Analysis??）是 JVM 垃圾回收的核心機(jī)制，用于判斷對象是否存活。

其核心思想是：??從一組根對象（GC Roots）出發(fā)，遍歷所有引用鏈，未被引用的對象視為可回收垃圾??。以下是其詳細(xì)原理、流程和應(yīng)用場景：

可達(dá)性算法的基本流程?

1.??確定 GC Roots??

JVM 枚舉所有根對象（如棧幀中的局部變量、靜態(tài)變量等），作為遍歷起點(diǎn)。

2.遍歷引用鏈??

從 GC Roots 出發(fā)，遞歸遍歷所有直接或間接引用的對象，形成??對象圖（Object Graph）??。

3.??標(biāo)記存活對象??

所有被遍歷到的對象標(biāo)記為存活（如使用三色標(biāo)記法中的黑色或灰色狀態(tài)）。

4.??回收不可達(dá)對象??

未被遍歷到的對象（白色對象）視為垃圾，由具體 GC 算法回收（如標(biāo)記-清除、復(fù)制等）。

GC Roots 的具體類型?

以下對象被定義為 GC Roots，不會被回收：

虛擬機(jī)棧中的引用??

當(dāng)前執(zhí)行方法的局部變量、方法參數(shù)（如 public void foo(Object param)）。

當(dāng)前線程的調(diào)用棧中所有方法的局部變量。

本地方法棧中的引用??

JNI（Java Native Interface）方法中的對象引用（如通過 JNIEnv 調(diào)用的對象）。

方法區(qū)的靜態(tài)變量和常量??

類的靜態(tài)變量（static 修飾）。

字符串常量池中的引用（如 String s = “abc”）。

同步鎖持有的對象??

通過 synchronized 關(guān)鍵字鎖定的對象（如 synchronized(obj) 中的 obj）。

JVM 內(nèi)部對象??

系統(tǒng)類加載器（ClassLoader）加載的類。

異常對象（如 OutOfMemoryError）、線程對象等。

跨代引用記錄對象??

卡表（Card Table）中記錄的老年代對新生代的引用（需特殊處理）。

引用類型對可達(dá)性的影響?

示例：

Object strongRef = new Object();          // 強(qiáng)引用
SoftReference<Object> softRef = new SoftReference<>(new Object());
WeakReference<Object> weakRef = new WeakReference<>(new Object());
PhantomReference<Object> phantomRef = new PhantomReference<>(new Object(), new ReferenceQueue<>());

三色標(biāo)記（Tri-color Marking）

定義

用三種顏色抽象對象的狀態(tài)：

??白色（White）??

• ??初始狀態(tài)??：對象未被訪問（未標(biāo)記）。
• ??最終回收??：標(biāo)記完成后仍為白色的對象視為可回收垃圾。

??灰色（Gray）??

• ??中間狀態(tài)??：對象被標(biāo)記為存活，但其子引用（成員變量、數(shù)組元素等）尚未被遍歷。

??黑色（Black）??

• ??最終存活狀態(tài)??：對象被標(biāo)記為存活，且所有子引用已被遍歷完成。

標(biāo)記流程（基本步驟）?

??初始階段

• 所有對象設(shè)為白色。
• 將 GC Roots 直接引用的對象標(biāo)記為灰色（放入灰色隊列）。

標(biāo)記階段（并發(fā)）

從灰色隊列中取出對象：

• —遍歷該對象的所有子引用，將子引用指向的白色對象標(biāo)記為灰色。
• —將當(dāng)前對象標(biāo)記為黑色。
• 重復(fù)上述過程，直到灰色隊列為空。

??最終階段

所有存活對象應(yīng)為黑色，白色對象視為垃圾。

并發(fā)標(biāo)記的兩種問題?

因用戶線程與 GC 線程并發(fā)運(yùn)行，對象引用可能發(fā)生變化，導(dǎo)致兩種風(fēng)險：

漏標(biāo)（對象丟失）

場景??：

黑色對象（已標(biāo)記完成）被用戶線程寫入了一個新的白色對象引用。

用戶線程刪除了灰色對象到某個白色對象的引用。

結(jié)果??：

白色對象未被標(biāo)記為存活，導(dǎo)致被錯誤回收。

例??：

初始：黑(A) → 灰(B) → 白(C) → 白(D)
B 即將處理，但此時用戶線程執(zhí)行：
1. A.field = D   // 黑對象引用了白對象
2. B.field = null // 斷開灰對象到C的引用
最終：C未標(biāo)記（白色），D未標(biāo)記（白色），會被誤回收。

解決

1. 增量更新（Incremental Update）??

• ??原理??：記錄新插入的引用，重新標(biāo)記。
• ??實(shí)現(xiàn)??：當(dāng)用戶線程將黑色對象插入對白色對象的引用時，通過??寫屏障（Write Barrier）?? 將黑色對象重新標(biāo)記為灰色。
• ??示例 GC??：CMS（Concurrent Mark-Sweep）。

??2. 原始快照（SATB, Snapshot At The Beginning）??

• ??原理??：基于標(biāo)記開始時存在的對象引用關(guān)系快照（即假設(shè)這些對象是存活的）。
• ??實(shí)現(xiàn)??：當(dāng)用戶線程修改引用關(guān)系（如刪除一個引用），通過寫屏障將舊引用的目標(biāo)對象標(biāo)記為灰色。
• ??示例 GC??：G1、ZGC、Shenandoah。

錯標(biāo)（浮動垃圾）

場景??：

對象實(shí)際已死亡，但在標(biāo)記階段被標(biāo)記為存活。

解決：

??可容忍??：僅導(dǎo)致少量內(nèi)存未及時釋放，下次 GC 可清理。

OopMap（Ordinary Object Pointer Map）

OopMap 記錄了棧上本地變量到堆上對象的引用關(guān)系。其作用是：垃圾收集時，收集線程會對棧上的內(nèi)存進(jìn)行掃描，看看哪些位置存儲了 Reference 類型。如果發(fā)現(xiàn)某個位置確實(shí)存的是 Reference 類型，就意味著它所引用的對象這一次不能被回收。但問題是，棧上的本地變量表里面只有一部分?jǐn)?shù)據(jù)是 Reference 類型的（它們是我們所需要的），那些非 Reference 類型的數(shù)據(jù)對我們而言毫無用處，但我們還是不得不對整個棧全部掃描一遍，這是對時間和資源的一種浪費(fèi)。

一個很自然的想法是，能不能用空間換時間，在某個時候把棧上代表引用的位置全部記錄下來，這樣到真正 gc 的時候就可以直接讀取，而不用再一點(diǎn)一點(diǎn)的掃描了。事實(shí)上，大部分主流的虛擬機(jī)也正是這么做的，比如 HotSpot ，它使用一種叫做 OopMap 的數(shù)據(jù)結(jié)構(gòu)來記錄這類信息。

我們知道，一個線程意味著一個棧，一個棧由多個棧幀組成，一個棧幀對應(yīng)著一個方法，一個方法里面可能有多個安全點(diǎn)。 gc 發(fā)生時，程序首先運(yùn)行到最近的一個安全點(diǎn)停下來，然后更新自己的 OopMap ，記下棧上哪些位置代表著引用。枚舉根節(jié)點(diǎn)時，遞歸遍歷每個棧幀的 OopMap ，通過棧中記錄的被引用對象的內(nèi)存地址，即可找到這些對象（ GC Roots ）。

OopMap（Ordinary Object Pointer Map）是 JVM 用于??快速定位 GC Roots?? 的關(guān)鍵數(shù)據(jù)結(jié)構(gòu)，通過記錄棧幀和寄存器中的對象引用位置，顯著減少垃圾回收時的停頓時間（Stop-The-World, STW）。以下是其生成時機(jī)及作用機(jī)制的詳細(xì)解析：

OopMap 的生成時機(jī)?

OopMap 的生成與 ??JIT 編譯器?? 和 ??安全點(diǎn)（Safe Point）?? 密切相關(guān)，主要發(fā)生在以下場景：

方法編譯時（JIT 階段）?

??即時編譯（JIT）??：

當(dāng)方法被 JIT 編譯器編譯為本地機(jī)器碼時，編譯器會分析方法的棧幀布局，并生成對應(yīng)的 OopMap。

??記錄內(nèi)容??：

棧幀中哪些位置（偏移量）存儲了對象引用（Oop，Ordinary Object Pointer）。如：局部變量表、方法參數(shù)、this 指針等。

??示例??：

若方法的局部變量表第 3 個槽位是 Object obj，則 OopMap 會記錄該槽位的偏移量。

安全點(diǎn)（Safe Point）?

• ??安全點(diǎn)觸發(fā)??：當(dāng) JVM 需要執(zhí)行 GC、代碼反優(yōu)化等操作時，所有用戶線程必須暫停在安全點(diǎn)。
• ??安全點(diǎn)位置??：通常插入在方法調(diào)用、循環(huán)回邊（如 for 循環(huán)）、異常拋出等位置（避免長時間不進(jìn)入安全點(diǎn)）。
• ??OopMap 更新??：在安全點(diǎn)處，JVM 會生成或更新當(dāng)前線程的 OopMap，確保準(zhǔn)確記錄此時棧幀和寄存器中的引用。

GC 僅是觸發(fā)安全點(diǎn)的一種場景，其他操作（如偏向鎖撤銷）也會觸發(fā)安全點(diǎn)。

??并非所有 OopMap 都在 GC 前生成??，但 GC 前必須依賴安全點(diǎn)更新 OopMap。

特定指令插入?

顯式生成指令??：JIT 編譯器會在生成的機(jī)器碼中插入特殊指令（如 test 指令），用于檢查是否需要進(jìn)入安全點(diǎn)并生成 OopMap。

OopMap 如何協(xié)助 JVM 獲取 GC Roots?

GC Roots 是垃圾回收的起點(diǎn)，包括??棧幀中的局部變量、靜態(tài)變量、JNI 引用等??。

OopMap 的作用是快速枚舉這些根引用，避免全棧掃描。

快速定位引用位置?

• 直接映射??：OopMap 明確記錄了棧幀中哪些位置存儲了對象引用（如局部變量、方法參數(shù)）。
• ??寄存器記錄??：部分引用可能存儲在寄存器中（如 this 指針），OopMap 也會記錄這些寄存器的名稱。

結(jié)合安全點(diǎn)減少 STW 時間?

• ??暫停線程??：當(dāng) GC 觸發(fā)時，所有線程需快速暫停在安全點(diǎn)。
• ??遍歷 OopMap??：GC 線程直接讀取各線程的 OopMap，遍歷記錄的引用位置，收集所有 GC Roots。
• ??無需全棧掃描??：避免逐字節(jié)檢查整個棧內(nèi)存，極大縮短暫停時間。

與卡表（Card Table）協(xié)作?

• 維護(hù)跨代引用??：卡表用于記錄老年代到新生代的引用，OopMap 幫助快速定位這些引用所在的棧或寄存器位置。
• ??寫屏障支持??：當(dāng)用戶線程修改對象引用時，寫屏障會更新卡表，而 OopMap 確保這些修改在 GC 時被正確識別。

OopMap 與 GC 流程的協(xié)作?

以 ??Young GC?? 為例，流程如下：

1.??觸發(fā) GC??：新生代空間不足，需回收。

??2.進(jìn)入安全點(diǎn)??：所有用戶線程暫停，生成 OopMap。

3.??枚舉 GC Roots??：

• —根據(jù) OopMap 遍歷所有線程的棧幀和寄存器，收集指向新生代的引用（如局部變量 obj）。
• —結(jié)合卡表，找到老年代中指向新生代的對象。

4.??標(biāo)記存活對象??：從 GC Roots 出發(fā)，標(biāo)記所有可達(dá)對象。

5.??恢復(fù)線程??：完成 GC 后，線程繼續(xù)執(zhí)行。

總結(jié)

以上為個人經(jīng)驗(yàn)，希望能給大家一個參考，也希望大家多多支持腳本之家。

最新評論