JVM GC垃圾回收算法

垃圾回收算法（GC Algorithms）

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

標記-清除（Mark-Sweep）

此算法執行分兩階段。第一階段從引用根節點開始標記所有被引用的對象，第二階段遍歷整個堆，把未標記的對象清除。
流程??：標記所有存活對象 → 清除未標記對象。
??優點??：簡單、無對象移動開銷。
??缺點??：內存碎片化、效率較低（需遍歷兩次堆）。
在這里插入圖片描述

復制算法（Copying）

此算法把內存空間劃為兩個相等的區域，每次只使用其中一個區域。垃圾回收時，遍歷當前使用區域，把正在使用中的對象復制到另外一個區域中。此算法每次只處理正在使用中的對象，因此復制成本比較小，同時復制過去以后還能進行相應的內存整理，不會出現“碎片”問題。當然，此算法的缺點也是很明顯的，就是需要兩倍內存空間。
?流程??：將存活對象復制到另一塊內存區域 → 清空原區域。
??優點??：無碎片、效率高（適用于存活率低的對象，如新生代）。
??缺點??：內存利用率低（需預留一半空間）。
在這里插入圖片描述

??標記-整理（Mark-Compact）

此算法結合了“標記-清除”和“復制”兩個算法的優點。也是分兩階段，第一階段從根節點開始標記所有被引用對象，第二階段遍歷整個堆，把清除未標記對象并且把存活對象“壓縮”到堆的其中一塊，按順序排放。此算法避免了“標記-清除”的碎片問題，同時也避免了“復制”算法的空間問題。
流程??：標記存活對象 → 移動對象到內存一端 → 清理邊界外內存。
??優點??：無碎片、內存利用率高。
??缺點??：對象移動開銷大（適用于老年代）。
在這里插入圖片描述

分代收集（Generational Collection）

核心思想??：根據對象存活時間劃分內存區域（新生代、老年代）。
??新生代??：存活率低 → 使用復制算法（如 Serial、ParNew）。
?? 老年代??：存活率高 → 使用標記-清除或標記-整理算法（如 CMS、G1）。

可達性算法（Reachability Analysis）

可達性算法（??Reachability Analysis??）是 JVM 垃圾回收的核心機制，用于判斷對象是否存活。其核心思想是：??從一組根對象（GC Roots）出發，遍歷所有引用鏈，未被引用的對象視為可回收垃圾??。以下是其詳細原理、流程和應用場景：
在這里插入圖片描述

可達性算法的基本流程?

1.??確定 GC Roots??
JVM 枚舉所有根對象（如棧幀中的局部變量、靜態變量等），作為遍歷起點。
2.遍歷引用鏈??
從 GC Roots 出發，遞歸遍歷所有直接或間接引用的對象，形成??對象圖（Object Graph）??。
3.??標記存活對象??
所有被遍歷到的對象標記為存活（如使用三色標記法中的黑色或灰色狀態）。
4.??回收不可達對象??
未被遍歷到的對象（白色對象）視為垃圾，由具體 GC 算法回收（如標記-清除、復制等）。

GC Roots 的具體類型?

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

虛擬機棧中的引用??

當前執行方法的局部變量、方法參數（如 public void foo(Object param)）。
當前線程的調用棧中所有方法的局部變量。

本地方法棧中的引用??

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

方法區的靜態變量和常量??

類的靜態變量（static 修飾）。
字符串常量池中的引用（如 String s = “abc”）。

同步鎖持有的對象??

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

JVM 內部對象??

系統類加載器（ClassLoader）加載的類。
異常對象（如 OutOfMemoryError）、線程對象等。

跨代引用記錄對象??

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

引用類型對可達性的影響?

引用類型	強引用（Strong）	軟引用（Soft）	弱引用（Weak）	虛引用（Phantom）
定義?	默認引用（Object obj = new Object()）	內存不足時回收（SoftReference）	下次 GC 必回收（WeakReference）	僅用于跟蹤對象回收（PhantomReference）
??可達性影響?	強可達	軟可達	弱可達	不可達
??回收條件?	不可達時回收	內存不足時回收	無論內存是否充足均回收	對象回收后入隊通知

示例：

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

三色標記（Tri-color Marking）

定義

用三種顏色抽象對象的狀態：
??白色（White）??
??初始狀態??：對象未被訪問（未標記）。
??最終回收??：標記完成后仍為白色的對象視為可回收垃圾。
??灰色（Gray）??
??中間狀態??：對象被標記為存活，但其子引用（成員變量、數組元素等）尚未被遍歷。
??黑色（Black）??
??最終存活狀態??：對象被標記為存活，且所有子引用已被遍歷完成。

標記流程（基本步驟）?

??初始階段

所有對象設為白色。
將 GC Roots 直接引用的對象標記為灰色（放入灰色隊列）。

標記階段（并發）

從灰色隊列中取出對象：
—遍歷該對象的所有子引用，將子引用指向的白色對象標記為灰色。
—將當前對象標記為黑色。
重復上述過程，直到灰色隊列為空。

??最終階段

所有存活對象應為黑色，白色對象視為垃圾。

并發標記的兩種問題?

因用戶線程與 GC 線程并發運行，對象引用可能發生變化，導致兩種風險：

漏標（對象丟失）

場景??：

黑色對象（已標記完成）被用戶線程寫入了一個新的白色對象引用。
用戶線程刪除了灰色對象到某個白色對象的引用。

結果??：

白色對象未被標記為存活，導致被錯誤回收。
例??：

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

解決

增量更新（Incremental Update）??
??原理??：記錄新插入的引用，重新標記。
??實現??：當用戶線程將黑色對象插入對白色對象的引用時，通過??寫屏障（Write Barrier）?? 將黑色對象重新標記為灰色。
??示例 GC??：CMS（Concurrent Mark-Sweep）。
??2. 原始快照（SATB, Snapshot At The Beginning）??
??原理??：基于標記開始時存在的對象引用關系快照（即假設這些對象是存活的）。
??實現??：當用戶線程修改引用關系（如刪除一個引用），通過寫屏障將舊引用的目標對象標記為灰色。
??示例 GC??：G1、ZGC、Shenandoah。

錯標（浮動垃圾）

場景??：

對象實際已死亡，但在標記階段被標記為存活。

解決：

??可容忍??：僅導致少量內存未及時釋放，下次 GC 可清理。

OopMap（Ordinary Object Pointer Map）

OopMap 記錄了棧上本地變量到堆上對象的引用關系。其作用是：垃圾收集時，收集線程會對棧上的內存進行掃描，看看哪些位置存儲了 Reference 類型。如果發現某個位置確實存的是 Reference 類型，就意味著它所引用的對象這一次不能被回收。但問題是，棧上的本地變量表里面只有一部分數據是 Reference 類型的（它們是我們所需要的），那些非 Reference 類型的數據對我們而言毫無用處，但我們還是不得不對整個棧全部掃描一遍，這是對時間和資源的一種浪費。
一個很自然的想法是，能不能用空間換時間，在某個時候把棧上代表引用的位置全部記錄下來，這樣到真正 gc 的時候就可以直接讀取，而不用再一點一點的掃描了。事實上，大部分主流的虛擬機也正是這么做的，比如 HotSpot ，它使用一種叫做 OopMap 的數據結構來記錄這類信息。
我們知道，一個線程意味著一個棧，一個棧由多個棧幀組成，一個棧幀對應著一個方法，一個方法里面可能有多個安全點。 gc 發生時，程序首先運行到最近的一個安全點停下來，然后更新自己的 OopMap ，記下棧上哪些位置代表著引用。枚舉根節點時，遞歸遍歷每個棧幀的 OopMap ，通過棧中記錄的被引用對象的內存地址，即可找到這些對象（ GC Roots ）。

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

OopMap 的生成時機?

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

方法編譯時（JIT 階段）?

??即時編譯（JIT）??：
當方法被 JIT 編譯器編譯為本地機器碼時，編譯器會分析方法的棧幀布局，并生成對應的 OopMap。
??記錄內容??：
棧幀中哪些位置（偏移量）存儲了對象引用（Oop，Ordinary Object Pointer）。如：局部變量表、方法參數、this 指針等。
??示例??：
若方法的局部變量表第 3 個槽位是 Object obj，則 OopMap 會記錄該槽位的偏移量。

安全點（Safe Point）?

??安全點觸發??：當 JVM 需要執行 GC、代碼反優化等操作時，所有用戶線程必須暫停在安全點。
??安全點位置??：通常插入在方法調用、循環回邊（如 for 循環）、異常拋出等位置（避免長時間不進入安全點）。
??OopMap 更新??：在安全點處，JVM 會生成或更新當前線程的 OopMap，確保準確記錄此時棧幀和寄存器中的引用。

GC 僅是觸發安全點的一種場景，其他操作（如偏向鎖撤銷）也會觸發安全點。
??并非所有 OopMap 都在 GC 前生成??，但 GC 前必須依賴安全點更新 OopMap。

特定指令插入?

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

OopMap 如何協助 JVM 獲取 GC Roots?

GC Roots 是垃圾回收的起點，包括??棧幀中的局部變量、靜態變量、JNI 引用等??。OopMap 的作用是快速枚舉這些根引用，避免全棧掃描。

快速定位引用位置?

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

結合安全點減少 STW 時間?

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

與卡表（Card Table）協作?

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

OopMap 與 GC 流程的協作?

以 ??Young GC?? 為例，流程如下：
1.??觸發 GC??：新生代空間不足，需回收。
??2.進入安全點??：所有用戶線程暫停，生成 OopMap。
3.??枚舉 GC Roots??：
—根據 OopMap 遍歷所有線程的棧幀和寄存器，收集指向新生代的引用（如局部變量 obj）。
—結合卡表，找到老年代中指向新生代的對象。
4.??標記存活對象??：從 GC Roots 出發，標記所有可達對象。
5.??恢復線程??：完成 GC 后，線程繼續執行。