.NET Core GC 清掃與壓縮篇章07-源碼深度-.NET Core GC |閱讀時間約 45 分鐘一、引言標記階段識別了存活對象后GC 進入回收階段——清掃死亡對象、壓縮存活對象。清掃和壓縮是 GC 中內存效率的決定性因素清掃決定了多少死亡內存被真正釋放壓縮決定了碎片是否累積到影響分配的程度。但清掃和壓縮的代價也不容忽視。一次全堆壓縮可能耗時數十到數百毫秒直接反映在應用的暫停時間上。所以 .NET Core GC 的核心設計哲學是能不清壓就不清壓必須清壓時盡量并行化。這個哲學貫穿了從計劃決策到清掃實現、從壓縮策略到 LOH 特殊處理的每一個環(huán)節(jié)。在展開之前先把本章的定位說清楚。07-03 標記篇已經講完了哪些對象活著本章接著講活著的東西怎么擺回去、死的東西怎么收走。后臺 GC 的并發(fā)編排見 07-05分配路徑見 07-02堆結構與分代布局的背景見 07-01。二、計劃階段Plan Phase2.1 清掃前的決策GC 在執(zhí)行任何清掃動作之前必須先制定計劃。這個計劃決定了哪些代需要清掃、哪些代需要壓縮、LOH 是否需要特殊處理、是否啟用并行清掃。// gc.h - GCPlan 結構體簡化示意不含全部字段 struct GCPlan { bool compact_gen2; // Gen 2 是否需要壓縮 bool compact_loh; // LOH 是否需要壓縮 int sweep_gen0_segments; // Gen 0 需要清掃的段數 int sweep_gen1_segments; // Gen 1 需要清掃的段數 int sweep_gen2_segments; // Gen 2 需要清掃的段數 bool concurrent_sweep; // 是否并發(fā)清掃后臺 GC 時 bool parallel_sweep; // 是否并行清掃多核時 float fragmentation_ratio_gen2; // Gen 2 碎片率 float fragmentation_ratio_loh; // LOH 碎片率 };計劃階段的核心輸入是碎片率。碎片率定義為碎片率 1.0 - (最大連續(xù)空閑塊大小 / 總空閑內存)換句話說碎片率衡量的是空閑內存被分散到了多小的塊里。碎片率為 0 表示所有空閑內存連成一塊碎片率為 1 表示每個空閑塊都只有 1 字節(jié)極端情況。2.2 壓縮觸發(fā)條件壓縮不是每次 GC 都做的——它只在碎片率超過閾值時才觸發(fā)。.NET Core GC 的默認閾值因代而異代壓縮觸發(fā)閾值原因Gen 0不壓縮Gen 0 每次 GC 都重建天然無碎片Gen 1不壓縮Gen 1 是 Gen 0 的緩沖區(qū)本身不獨立管理Gen 2~50%大堆碎片累積快壓縮收益高LOH~70%手動LOH 不使用 bump pointer碎片率天然較低注意 Gen 0 和 Gen 1從不壓縮。這是因為 Gen 0 在每次 GC 時都會重建——所有存活對象晉升到 Gen 1Gen 0 的段被完全清空并重新使用。這種全量晉升 段復用的機制天然消除了 Gen 0 的碎片不需要壓縮。Gen 1 也不壓縮因為它不是一個獨立的內存區(qū)域——它和 Gen 2 共享同一組段。對 Gen 2 的壓縮同時就是對 Gen 1 的壓縮。2.3 計劃決策的時序標記階段完成 │ ▼ 統(tǒng)計各代碎片率 │ ├─ Gen 2 碎片率 50%? │ └─ Yes → compact_gen2 true │ ├─ LOH 手動觸發(fā)壓縮? │ └─ Yes → compact_loh true │ ├─ 并發(fā) GC 且 Gen 2 需要清掃? │ └─ Yes → concurrent_sweep true │ └─ CPU 核數 1 且需要清掃? └─ Yes → parallel_sweep true計劃階段本身非?？焱ǔＶ恍鑾装傥⒚?。它的輸出GCPlan會被傳遞給清掃階段和壓縮階段指導后續(xù)的所有操作。三、清掃階段Sweep Phase3.1 清掃的基本原理清掃是 GC 回收階段的第一步。它的任務很簡單遍歷段中的所有對象把死亡對象的內存標記為可用。但實現起來并不簡單。清掃需要處理以下問題對象遍歷如何高效地遍歷段中的所有對象死亡檢測如何判斷一個對象是否死亡空閑管理如何管理回收后的空閑內存3.1.1 對象遍歷清掃遍歷段的方式與標記遍歷對象圖的方式不同。標記是從根出發(fā)沿著引用字段下鉆而清掃是順序遍歷段中的每個對象按對象大小步進。// SweepSegment 核心邏輯簡化示意 void SweepSegment(heap_segment* seg) { uint8_t* current seg-start; uint8_t* end seg-allocated; while (current end) { Object* obj (Object*)current; // 檢查對象是否被標記 if (!obj-IsMarked()) { // 死亡對象回收其內存 size_t size obj-GetSize(); AddToFreeList(current, size); } else { // 存活對象清除標記位準備下一輪 obj-ClearMark(); } // 按對象大小步進到下一個對象 current obj-GetSize(); } }這個遍歷是順序的對內存的訪問模式非常友好——CPU 預取器可以很好地工作緩存命中率極高。這也是為什么清掃階段通常只占 GC 暫停時間的 10% 左右。3.1.2 死亡檢測死亡檢測通過檢查對象的標記位mark bit實現。標記階段會為每個存活對象設置標記位清掃階段只需檢查這個位標記位為 1存活對象清除標記位繼續(xù)下一個標記位為 0死亡對象回收內存標記位通常存儲在對象頭的某個比特位中訪問速度極快一條位操作指令。3.1.3 空閑管理回收后的空閑內存需要被管理以便后續(xù)分配能夠快速找到可用空間。.NET Core GC 使用按大小分類的空閑列表size-class free list空閑列表結構 ┌─────────────────────────────────────────────────┐ │ FreeList[0] (8-15 字節(jié)) ──? [塊A] ──? [塊B] │ │ FreeList[1] (16-31 字節(jié)) ──? [塊C] ──? NULL │ │ FreeList[2] (32-63 字節(jié)) ──? [塊D] │ │ ... │ │ FreeList[N] (8KB) ──? [塊E] ──? [塊F] │ └─────────────────────────────────────────────────┘空閑列表按大小分類的好處是分配時可以根據請求大小直接定位到對應的鏈表避免全表搜索。這與 slab 分配器的思想類似——將相近大小的空閑塊歸為一類每類維護一個獨立鏈表。3.2 清掃的零分配保證清掃階段有一個重要的設計原則不分配任何新對象。所有需要的臨時數據結構空閑鏈表節(jié)點等都從已回收的對象本身借用內存。這是經典的intrusive list侵入式鏈表技術被回收的對象內存直接作為鏈表節(jié)點使用不需要額外分配內存來維護空閑列表。具體來說死亡對象的第一個字段原本存儲方法表指針之后的位置被覆寫為下一個空閑塊的指針。死亡對象回收前的內存布局 ┌────────────────────────────────────────────┐ │ 方法表指針 (8B) │ 同步塊 (8B) │ 字段數據... │ └────────────────────────────────────────────┘ │ ▼ 回收后方法表指針之后的內存被覆寫 ┌────────────────────────────────────────────┐ │ 方法表指針 (8B) │ 空閑鏈表指針 ?────────────┘ │ (保持不變GC 不再需要) │ └────────────────────────────────────────────┘這種設計的優(yōu)勢零額外內存不需要為空閑鏈表分配任何額外內存。零額外分配不需要在清掃過程中調用malloc或new。零額外開銷空閑鏈表的插入操作只是修改一個指針。不清零被回收的對象不需要清零因為它的內存即將被重新分配使用。3.3 并發(fā)清掃在后臺 GCBackground GC模式下清掃可以與應用線程并發(fā)執(zhí)行。這是 .NET Core 3.0 的重要優(yōu)化時間線示意 應用線程: [Alloc][Alloc][Alloc][Alloc][Alloc][Alloc]... │ │ GC線程: ──[標記 Gen2]──[清掃 Gen2]──────[壓縮 Gen2]── │ │ │ │ ├─ 并發(fā)清掃應用線程繼續(xù)分配 │ └─ 壓縮時需要 STW并發(fā)清掃的關鍵技術是標記-清掃并發(fā)標記階段在后臺線程中并行執(zhí)行清掃階段在標記完成后立即開始不需要等待應用線程全部掛起。只有壓縮階段需要 STWStop-The-World。并發(fā)清掃的實現依賴于以下機制標記位的原子操作標記階段設置標記位使用原子操作清掃階段讀取標記位不需要加鎖。段級鎖清掃器獲取段的鎖后其他線程不能修改該段的內容。段級鎖的粒度比全局鎖小得多減少了競爭。卡片表補償并發(fā)期間應用線程可能創(chuàng)建新的引用這些引用通過卡片表記錄清掃完成后由 GC 進行補償掃描。3.4 并行清掃在多核機器上清掃可以并行化。不同清掃器線程負責不同的段互不干擾段 0 ──? 清掃器線程 0 段 1 ──? 清掃器線程 1 段 2 ──? 清掃器線程 2 段 3 ──? 清掃器線程 3并行清掃的加速比接近線性——4 核機器上清掃 4 個段的耗時約等于清掃 1 個段的 4 倍。但并行清掃也有開銷任務分發(fā)需要將段分配給清掃器線程這本身有同步開銷?？臻e列表合并各線程回收的空閑塊需要合并到全局空閑列表中。緩存競爭多個線程同時寫入空閑列表可能導致緩存行失效。因此并行清掃在段數較多時收益明顯段數較少時可能得不償失。.NET Core GC 會根據段數和 CPU 核數自動決定是否啟用并行清掃。四、壓縮階段Compact Phase4.1 為什么需要壓縮清掃雖然回收了死亡對象的內存但它留下的空閑塊是分散的。如果死亡對象和存活對象交替出現空閑塊也會交替出現清掃前的段布局 ┌──────┬────────┬──────┬────────┬──────┬────────┬──────┐ │ 存活 │ 死亡 │ 存活 │ 死亡 │ 存活 │ 死亡 │ 存活 │ │ ObjA │ ObjX │ ObjB │ ObjY │ ObjC │ ObjZ │ ObjD │ └──────┴────────┴──────┴────────┴──────┴────────┴──────┘ 空閑塊: [ObjX] [ObjY] [ObjZ] 分散在存活對象之間 清掃后未壓縮 ┌──────┬────────┬──────┬────────┬──────┬────────┬──────┬──────┐ │ 存活 │ 死亡 │ 存活 │ 死亡 │ 存活 │ 死亡 │ 存活 │ 空閑 │ │ ObjA │ ObjX │ ObjB │ ObjY │ ObjC │ ObjZ │ ObjD │ │ └──────┴────────┴──────┴────────┴──────┴────────┴──────┴──────┘ 空閑塊分散在 ObjA/ObjB/ObjC/ObjD 之間 → 碎片化 壓縮后 ┌──────┬──────┬──────┬──────┬──────────────────────────────┐ │ 存活 │ 存活 │ 存活 │ 存活 │ 連續(xù)空閑空間 │ │ ObjA │ ObjB │ ObjC │ ObjD │ (可分配區(qū)域) │ └──────┴──────┴──────┴──────┴──────────────────────────────┘ 所有存活對象移到段開頭空閑空間集中在段尾 → 無碎片壓縮的核心價值是將分散的空閑塊合并為連續(xù)的可用空間。沒有壓縮碎片會逐步累積最終導致即使總空閑內存足夠也無法分配大塊對象因為找不到足夠大的連續(xù)空間。4.2 壓縮的三個步驟壓縮是 GC 中最復雜的操作涉及三個緊密耦合的步驟步驟 1計算新地址// ComputeNewAddresses簡化示意 void ComputeNewAddresses(int generation) { uint8_t* write_ptr segment-start; // 寫入指針從段頭開始 for (uint8_t* current segment-start; current segment-allocated; current obj-GetSize()) { Object* obj (Object*)current; if (obj-IsMarked()) { // 存活對象記錄新地址 obj-SetNewAddress(write_ptr); write_ptr obj-GetSize(); } // 死亡對象跳過不分配新地址 } segment-allocated write_ptr; // 更新段的分配上限 }這一步是純讀取 順序寫入對內存的訪問模式非常友好。每個存活對象只被訪問一次按順序從段頭掃到段尾。關鍵細節(jié)新地址單調遞增存活對象按原順序排列新地址嚴格遞增。這意味著壓縮不會改變對象的相對順序有利于緩存局部性。死亡對象被跳過死亡對象不占用新地址空間相當于在計算新地址的同時完成了收縮。對象大小不變壓縮不改變對象大小只改變對象的起始地址。步驟 2修復引用Fix References// FixReferences簡化示意 void FixReferences(int generation) { // 修復棧上的引用 for (Thread* thread : suspended_threads) { for (RefLocation ref : thread-stack_references) { if (ref.target segment_start ref.target segment_end) { *ref.location ref.target-GetNewAddress(); } } } // 修復堆上的引用存活對象中的引用字段 for (uint8_t* obj segment-start; obj segment-allocated; ) { if (obj-IsMarked()) { obj-FixReferences(); // 對象內部的引用字段全部更新 obj obj-GetSize(); } } // 修復靜態(tài)字段 for (StaticRef ref : static_references) { if (ref.target segment_start ref.target segment_end) { *ref.location ref.target-GetNewAddress(); } } // 修復句柄表 for (HandleEntry entry : handle_table) { if (entry.target segment_start entry.target segment_end) { entry.target entry.target-GetNewAddress(); } } }引用修復是壓縮中最復雜、最耗時的部分。需要修復的引用來源包括棧引用各線程棧幀中指向壓縮段的對象引用。堆引用存活對象內部的引用字段指向同一段或其他段中的對象。靜態(tài)字段類靜態(tài)變量中指向壓縮段的引用。句柄表GCHandle 中指向壓縮段的引用。GC 內部結構如卡片表、根表等。引用修復的關鍵約束必須在復制之前完成。因為復制會移動對象如果先復制再修復引用修復時找不到舊地址。步驟 3復制對象數據// CopyObjects簡化示意 void CopyObjects(int generation) { for (uint8_t* current segment-start; current segment-old_allocated; current obj-GetSize()) { Object* obj (Object*)current; if (obj-IsMarked()) { uint8_t* new_addr obj-GetNewAddress(); if (current ! new_addr) { // 對象需要移動復制數據 size_t size obj-GetSize(); MemMove(new_addr, current, size); } } } }復制階段使用MemMove批量移動對象數據。由于對象是按順序處理的且新地址也是順序遞增的MemMove的調用可以很好地利用 CPU 的 DMA 緩存行預取和 SIMD 指令。關鍵優(yōu)化原地跳過如果對象的新地址等于舊地址通常發(fā)生在段尾部的存活對象直接跳過不復制。批量復制MemMove內部使用 SIMD 指令如 AVX2一次復制 32 或 64 字節(jié)比逐字節(jié)復制快數倍。寫合并多個小對象的復制可以合并為一次MemMove調用減少函數調用開銷。4.3 壓縮的代價壓縮涉及大量內存復制和引用更新是 GC 中最耗時的操作。以下是一個典型場景的耗時分解100MB Gen 2 堆碎片率 60%一次全量壓縮 步驟 耗時 占比 ───────────────────────────────────── 計算新地址 5-10ms ~15% 修復引用 20-80ms ~60% ← 最耗時 復制對象數據 5-10ms ~15% 清理段元數據 1-2ms ~5% ───────────────────────────────────── 合計 30-100ms 100%各步驟的耗時特征計算新地址O(n) 順序遍歷緩存友好耗時與存活對象數成正比。修復引用O(n r)n 為存活對象數r 為引用字段總數。引用字段越多耗時越長。棧引用和句柄表引用的修復需要逐個處理無法批量優(yōu)化。復制對象數據O(n)但MemMove的常數極小實際耗時通常低于引用修復。清理段元數據O(1) 或 O(段數)耗時可忽略。4.4 壓縮的并發(fā)化.NET Core GC 在 .NET 6 中引入了并發(fā)壓縮的部分優(yōu)化。核心思想是將壓縮拆分為多個階段其中計算新地址和修復引用可以在后臺線程中并行執(zhí)行只有最后的復制 最終引用修復需要 STW。傳統(tǒng)壓縮全 STW [計算新地址][修復引用][復制對象][最終修復] ← 全部 STW 并發(fā)壓縮.NET 6 [計算新地址]──[修復引用] ← 后臺線程并行執(zhí)行 │ ▼ STW 切換點 [復制對象][最終修復] ← 短 STW這種設計的優(yōu)勢是將 STW 時間從幾十毫秒降低到幾毫秒。后臺階段雖然也消耗 CPU 和內存帶寬但不影響應用線程只有最后的 STW 階段會暫停應用。五、LOH 清掃與壓縮5.1 LOH 為什么不同LOH大對象堆的清掃和壓縮與 SOH小對象堆有本質區(qū)別原因在 07-02 中已經提到過不使用 bump pointerLOH 使用空閑列表管理天然不存在清掃后合并空閑塊的需求。對象生命周期長LOH 對象通常存活整個應用生命周期碎片率增長緩慢。壓縮代價極高LOH 對象可能從 85KB 到幾 GB復制一個大對象的代價相當于復制成千上萬個小對象。5.2 LOH 清掃LOH 的清掃與 SOH 類似也是遍歷死亡對象并回收內存。但由于 LOH 對象數量遠少于 SOH 對象LOH 清掃的耗時通?？梢院雎圆挥?。// LOH Sweep簡化示意 void SweepLOH() { for (auto entry : loh_free_list) { if (!entry.obj-IsMarked()) { // 死亡 LOH 對象回收 AddToLOHFreeList(entry.obj, entry.size); } else { // 存活 LOH 對象清除標記 entry.obj-ClearMark(); } } }5.3 LOH 壓縮LOH 壓縮是一個手動觸發(fā)的操作默認不自動執(zhí)行。這是因為 LOH 壓縮的代價極高——它需要移動所有存活的大對象并更新所有指向它們的引用。// 手動觸發(fā) LOH 壓縮 GCSettings.LargeObjectHeapCompactionMode GCLargeObjectHeapCompactionMode.CompactOnce; // 下一次 GC.Collect() 會壓縮 LOH GC.Collect();LOH 壓縮的觸發(fā)條件觸發(fā)方式條件說明手動觸發(fā)GCSettings.LargeObjectHeapCompactionMode CompactOnce下一次 GC.Collect() 觸發(fā)永久模式GCSettings.LargeObjectHeapCompactionMode CompactEveryTime每次 GC.Collect() 都觸發(fā)不推薦自動觸發(fā)無.NET Core 默認不自動壓縮 LOHLOH 壓縮的代價內存復制所有存活 LOH 對象需要被移動復制量可能達到數 GB。引用更新所有指向 LOH 對象的引用需要更新包括棧引用、堆引用、靜態(tài)字段、句柄表。STW 時間長LOH 壓縮通常需要 STW 數百毫秒到數秒取決于 LOH 大小和存活對象數。因此LOH 壓縮應該謹慎使用只在確實存在嚴重碎片問題且影響分配時才觸發(fā)。5.4 LOH 碎片問題與緩解LOH 碎片是 .NET 中一個經典問題。當頻繁分配和釋放大小不一的 LOH 對象時空閑列表會逐漸碎片化最終導致即使總空閑內存足夠也無法分配新的大對象。緩解 LOH 碎片的策略避免頻繁分配/釋放 LOH 對象使用對象池復用 LOH 對象?？刂茖ο蟠笮”M量使對象大小低于 85,000 字節(jié)閾值使其走 SOH 路徑。定期手動壓縮在低峰期手動觸發(fā) LOH 壓縮。使用ArrayPoolT對于數組類型的 LOH 對象使用數組池復用。六、壓縮的代價與觸發(fā)策略6.1 壓縮耗時分解一次完整的 Gen 2 壓縮100MB 堆的耗時構成Full GC 耗時分解100MB 堆碎片率 60% 標記: ████████████████████████ 60% (15-30ms) ← 后臺GC改造目標 清掃: ████ 10% (2-5ms) 壓縮: ██████ 30% (10-50ms) ← 最慢但僅在碎片率超閾值時觸發(fā) ───────────────────────────────────────────────── 合計: 100% (27-85ms)關鍵觀察標記占大頭標記是耗時最長的階段也是后臺 GC 優(yōu)化的主要目標。清掃最穩(wěn)定清掃耗時波動最小因為它只依賴存活對象數與碎片率無關。壓縮最可變壓縮耗時波動最大從幾毫秒低碎片到數百毫秒高碎片 大堆。6.2 壓縮觸發(fā)策略.NET Core GC 的壓縮觸發(fā)策略可以概括為保守觸發(fā)按需壓縮。是否壓縮的決策邏輯 1. Gen 0? → 不壓縮每次 GC 都重建 2. Gen 1? → 不壓縮與 Gen 2 共享段隨 Gen 2 一起壓縮 3. Gen 2? ├─ 碎片率 50%? → Yes → 壓縮 └─ No → 不壓縮 4. LOH? ├─ 手動觸發(fā)? → Yes → 壓縮 └─ No → 不壓縮即使碎片率很高這個策略的核心考量壓縮的代價高壓縮需要移動對象、更新引用耗時可能遠超清掃。碎片不是最緊急的問題只要還有足夠大的連續(xù)空閑塊碎片不會導致分配失敗。預算機制優(yōu)先通過 budget 機制控制 GC 頻率比通過壓縮控制碎片更經濟。6.3 壓縮的替代方案在某些場景下壓縮不是最優(yōu)選擇。.NET Core GC 提供了以下替代方案段復用回收的段不還給操作系統(tǒng)留給下輪復用。這避免了還了再要的系統(tǒng)調用開銷?？臻e列表優(yōu)化通過按大小分類的空閑列表提高小塊的分配命中率減少對新段的需求。晉升策略調優(yōu)調整對象晉升策略讓短命對象更快離開 Gen 0減少 Gen 0 的碎片累積。七、GC 耗時分解與優(yōu)化方向7.1 一次 Full GC 的完整耗時一次 Full GC100MB Gen 2 堆碎片率 40%的耗時構成 階段 耗時 是否 STW 可并發(fā) ───────────────────────────────────────────────── 掛起線程 1-5ms Yes 否 根掃描 1-3ms Yes 否 標記 Gen 0/1 5-10ms 部分 是后臺 標記 Gen 2 10-20ms 部分 是后臺 清掃 Gen 0 1-2ms 部分 是并發(fā) 清掃 Gen 1/2 2-5ms 部分 是并發(fā) 壓縮 Gen 2 10-30ms Yes 否 修復引用 5-20ms Yes 部分 恢復線程 1-3ms Yes 否 ───────────────────────────────────────────────── 總 STW 時間 20-60ms 總耗時含并發(fā) 30-100ms7.2 優(yōu)化方向基于耗時分解GC 優(yōu)化的優(yōu)先級如下減少標記耗時后臺 GC 已經將標記移到后臺進一步優(yōu)化空間有限。減少壓縮觸發(fā)通過 budget 自適應和晉升策略降低碎片率減少壓縮觸發(fā)頻率。減少 STW 時間并發(fā)壓縮.NET 6將大部分壓縮工作移到后臺進一步降低 STW 時間。減少清掃耗時清掃已經很快10%優(yōu)化空間有限。八、清掃和壓縮的時機選擇8.1 何時壓縮.NET Core GC 根據以下因素決定是否壓縮碎片率空閑空間分散度超過閾值時觸發(fā)壓縮。Gen 2 默認閾值約 50%LOH 默認不自動壓縮。最近一次壓縮的時間間隔避免頻繁壓縮。如果剛做過壓縮即使碎片率略有上升也不會立即再次壓縮。堆大小大堆壓縮的收益更大——碎片浪費的絕對空間更多壓縮后釋放的連續(xù)空間也更可觀。內存壓力當操作系統(tǒng)通知內存緊張時GC 可能降低壓縮閾值更積極地壓縮以釋放空間。8.2 實際項目中的觀察在實際項目中大多數 GC 只需要清掃不需要壓縮。壓縮通常只在以下場景觸發(fā)長運行服務運行時間越長碎片累積越多壓縮觸發(fā)越頻繁。對象生命周期差異大如果同時存在短命對象和長命對象長命對象之間的空洞會逐步累積為碎片。LOH 頻繁分配雖然 LOH 不自動壓縮但 LOH 碎片會影響 Gen 2 的碎片率間接觸發(fā) Gen 2 壓縮。九、清掃的零分配保證9.1 Intrusive List 技術清掃階段有一個重要的設計原則不分配任何新對象。所有需要的臨時數據空閑鏈表節(jié)點等從已回收的對象本身借用內存。這是經典的intrusive list侵入式鏈表技術。具體來說被回收的死亡對象的內存被直接用作空閑鏈表的節(jié)點。死亡對象的第一個字段原本存儲方法表指針之后的位置被覆寫為下一個空閑塊的指針。這樣空閑鏈表不需要任何額外的內存分配——它寄生在已回收的對象內存上。死亡對象回收前的內存布局 ┌──────────────────────────────────────────────────────┐ │ 方法表指針 (8B) │ 同步塊 (8B) │ 字段數據 (N 字節(jié)) │ │ ← 對象頭 ← 對象數據 │ └──────────────────────────────────────────────────────┘ │ ▼ 回收后方法表指針之后的內存被覆寫為鏈表指針 ┌──────────────────────────────────────────────────────┐ │ 方法表指針 (8B) │ 空閑鏈表下一個節(jié)點指針 (8B) │ ... │ │ (GC 不再需要方法表指針) │ └──────────────────────────────────────────────────────┘ │ ▼ 插入空閑鏈表 FreeList[size_class] ──? [此塊] ──? [下一個空閑塊] ──? ...9.2 零分配的優(yōu)勢這種設計的優(yōu)勢是多方面的零額外內存不需要為空閑鏈表分配任何額外內存?？臻e鏈表的節(jié)點就是死亡對象本身。零額外分配不需要在清掃過程中調用malloc或new避免了在 GC 過程中觸發(fā)遞歸 GC 的風險。零額外開銷空閑鏈表的插入操作只是修改一個指針時間復雜度 O(1)。不清零被回收的對象不需要清零。因為它的內存即將被重新分配使用清零是浪費。緩存友好空閑鏈表節(jié)點與對象數據在同一塊內存中訪問局部性好。9.3 與 Java GC 的對比Java 的 OpenJDK GC如 G1使用獨立的空閑列表結構每個空閑塊需要額外的元數據來記錄大小和下一個節(jié)點。這意味著清掃階段需要為每個死亡塊分配一個空閑節(jié)點。.NET 的 intrusive list 技術避免了這一開銷是零分配保證的關鍵。十、與 Unity GC 的對比10.1 Unity (SGen) 的清掃與壓縮Unity 的 GC 基于 Mono 的 SGenScavenge-Sweep Garbage Collector與 .NET Core GC 有顯著差異特性.NET Core GCUnity (SGen)清掃方式順序遍歷 intrusive list標記-清掃 獨立空閑列表壓縮策略Gen 2 按需壓縮分代壓縮Scavenge 階段LOH 壓縮手動觸發(fā)無專門 LOH并發(fā)清掃.NET 3.0 支持增量清掃可配置零分配保證清掃階段不分配部分支持壓縮暫停時間30-100ms100MB10-50ms100MBUnity 的增量清掃是應對移動設備資源限制的特殊設計——將清掃拆分成多個小片段避免單次清掃暫停過長。而 .NET Core GC 更傾向于一次性完成通過后臺 GC 和并發(fā)壓縮來降低單次暫停的代價。10.2 為什么 Unity 的壓縮暫停更短Unity SGen 的壓縮暫停通常比 .NET Core GC 短原因有三堆更小移動設備的堆通常只有幾十 MB而 .NET 服務端應用的堆可能達到數 GB。壓縮耗時與堆大小成正比。壓縮策略更保守SGen 只在必要時壓縮小代不壓縮整個堆。對象更小移動應用的對象通常較小復制代價更低。但這些差異也反映了平臺約束移動設備內存有限不能像服務端那樣使用大堆和 LOH。十一、量化數據的口徑說明11.1 數據性質本文給出的所有量化數據耗時、百分比、閾值等均為典型估算或示例量級非實測常數。實際數值取決于以下因素堆大小100MB 堆與 10GB 堆的耗時相差兩個數量級。碎片率碎片率從 10% 上升到 80%壓縮耗時可能增加 5-10 倍。CPU 核數并行清掃和壓縮的加速比接近線性但受內存帶寬限制。對象大小分布大對象多的堆壓縮耗時更長。引用密度引用字段多的對象修復耗時更長。11.2 典型場景參考以下數據基于 16 核 64GB 服務端場景的典型估算非實測場景Gen 0 耗時Gen 2 耗時是否壓縮低碎片 (20%)0.5-2ms10-30ms否中碎片 (20-50%)0.5-2ms20-60ms否高碎片 (50%)0.5-2ms50-150ms是LOH 壓縮N/A100-500ms是手動十二、總結與實踐建議12.1 核心要點回顧清掃和壓縮是 GC 回收階段的核心它們的設計體現了按需觸發(fā)、零分配保證、并發(fā)優(yōu)化的思想清掃回收死亡對象通過 intrusive list 技術實現零分配耗時僅占 GC 的 10%。壓縮消除碎片將分散的空閑塊合并為連續(xù)空間但代價高30% 的 GC 耗時。按需觸發(fā)壓縮只在碎片率超過閾值時觸發(fā)大多數 GC 只需清掃。并發(fā)優(yōu)化后臺 GC 將清掃移到后臺.NET 6 將壓縮的部分工作移到后臺。LOH 特殊處理LOH 不自動壓縮需要手動觸發(fā)代價極高。12.2 實踐建議基于對清掃和壓縮的理解以下是針對 C# 開發(fā)者的實踐建議理解壓縮觸發(fā)條件壓縮只在碎片率超過閾值時觸發(fā)。如果你的應用碎片率始終很低壓縮幾乎不會成為性能瓶頸。謹慎使用 LOH 壓縮GCSettings.LargeObjectHeapCompactionMode CompactOnce是核武器級別的操只在確實存在嚴重 LOH 碎片且影響分配時才使用。關注 Gen 2 堆大小Gen 2 堆越大壓縮耗時越長。通過減少長命對象的數量和大小可以降低壓縮耗時。避免對象生命周期混疊短命對象和長命對象混在一起會導致碎片快速累積?？梢酝ㄟ^分層設計將短命和長命對象放在不同的類中來減少碎片。監(jiān)控碎片率使用 PerfView 或 ETW 事件監(jiān)控 GC 碎片率發(fā)現異常上升趨勢。理解零分配保證清掃階段不分配新對象所以不會觸發(fā)遞歸 GC。這意味著清掃的耗時是確定性的不會因 GC 嵌套而膨脹。12.3 清掃與壓縮的決策樹GC 回收階段 │ ├─ 標記階段完成 │ │ │ ├─ Gen 0? │ │ └─ 清掃重建段天然無碎片 │ │ │ ├─ Gen 1? │ │ └─ 清掃隨 Gen 2 一起處理 │ │ │ ├─ Gen 2? │ │ ├─ 碎片率 50%? │ │ │ ├─ Yes → 清掃 → 壓縮 │ │ │ └─ No → 清掃不壓縮 │ │ └─ 并發(fā)清掃? │ │ ├─ Yes → 后臺清掃 │ │ └─ No → STW 清掃 │ │ │ └─ LOH? │ ├─ 手動壓縮? │ │ ├─ Yes → 清掃 → 壓縮STW耗時高 │ │ └─ No → 清掃不壓縮 │ └─ 碎片率 70%? │ └─ 仍不自動壓縮LOH 壓縮代價過高十三、深入壓縮的引用修復細節(jié)13.1 引用修復的挑戰(zhàn)引用修復是壓縮階段最復雜的部分面臨以下挑戰(zhàn)引用來源多樣棧引用、堆引用、靜態(tài)字段、句柄表、GC 內部結構每種來源的修復方式不同。引用目標可能移動被引用的對象可能在同一段需要修復、在不同段不需要修復因為 GC 內部結構已經處理了跨段引用。修復順序必須先修復所有引用再移動對象數據。否則修復時找不到舊地址。13.2 棧引用的修復棧引用的修復是最直接的部分。在壓縮開始前所有應用線程被掛起GC 可以安全地掃描每個線程的棧幀// 棧引用修復簡化示意 void FixStackReferences(Thread* thread) { for (StackFrame* frame : thread-frames) { for (RefLocation ref : frame-local_variables) { if (ref.is_gc_ref ref.target_in_compressed_segment) { // 更新引用為新地址 *ref.location ref.target-GetNewAddress(); } } for (RefLocation ref : frame-parameters) { if (ref.is_gc_ref ref.target_in_compressed_segment) { *ref.location ref.target-GetNewAddress(); } } } }棧引用修復的關鍵點線程必須掛起修復棧引用時應用線程不能運行否則棧內容可能被改寫。寄存器也需要修復除了棧引用掛起時保存的寄存器快照中的引用也需要修復。修復是原地進行的直接修改棧幀中的引用值不需要移動棧本身。13.3 堆引用的修復堆引用的修復比棧引用復雜得多。存活對象內部的引用字段可能指向同一段中的任何對象也可能指向其他段。只有指向同一段的引用需要修復// 堆引用修復簡化示意 void FixHeapReferences(heap_segment* segment) { for (uint8_t* obj segment-start; obj segment-old_allocated; ) { if (obj-IsMarked()) { // 遍歷對象的引用字段 MethodTable* mt obj-GetMethodTable(); for (RefField* field : mt-reference_fields) { uint8_t* ref_addr obj field-offset; Object* target *(Object**)ref_addr; // 只修復指向同一段的引用 if (target segment-start target segment-end) { *(Object**)ref_addr target-GetNewAddress(); } } obj obj-GetSize(); } else { obj obj-GetSize(); // 死亡對象跳過 } } }堆引用修復的耗時取決于引用字段的數量。一個包含 10 個引用字段的對象修復時需要檢查 10 次、最多更新 10 次。對于引用字段多的對象如字典、列表修復耗時可能顯著高于簡單對象。13.4 句柄表的修復句柄表的修復相對簡單因為句柄表是一個集中管理的數據結構// 句柄表修復簡化示意 void FixHandleTable(heap_segment* segment) { for (HandleEntry entry : handle_table) { if (entry.target segment-start entry.target segment-end) { entry.target entry.target-GetNewAddress(); } } }句柄表的大小通常遠小于堆修復耗時可以忽略不計。但需要注意固定句柄pinned handle——固定句柄指向的對象在壓縮時不能被移動壓縮算法需要跳過這些對象。十四、深入壓縮算法的變體14.1 傳統(tǒng)壓縮移動對象前面描述的壓縮方式是移動對象將存活對象從舊地址復制到新地址。這是最常見的壓縮方式優(yōu)點是實現簡單、碎片消除徹底。但移動對象有一個問題指針不變性。如果外部代碼持有對象的原始指針如通過GCHandle的固定句柄移動對象會導致指針失效。這就是為什么固定句柄指向的對象不能被移動。14.2 間接壓縮更新指針另一種壓縮方式是不移動對象只更新引用。具體來說不移動任何對象數據。為每個對象維護一個轉發(fā)指針forwarding pointer指向壓縮后的邏輯位置。所有引用指向轉發(fā)指針而不是直接指向對象。傳統(tǒng)壓縮移動對象 舊地址: [ObjA][ObjB][ObjC] → 新地址: [ObjA][ObjB][ObjC][空閑] 引用 → ObjA 引用 → ObjA (新地址) 間接壓縮更新指針 舊地址: [ObjA][ObjB][ObjC] → 邏輯地址: [ObjA][ObjB][ObjC][空閑] 引用 → ObjA 引用 → 轉發(fā)指針 → ObjA (邏輯地址)間接壓縮的優(yōu)點是不需要移動對象數據缺點是引入了額外的間接尋址每次引用都需要多一次內存訪問。這在性能敏感的場景中是不可接受的所以 .NET Core GC 不使用這種方式。14.3 部分壓縮只壓縮熱點段還有一種優(yōu)化思路是只壓縮熱點段即分配最頻繁的段而不是壓縮整個代。這種部分壓縮的策略是識別熱點段分配最頻繁的段。只壓縮熱點段非熱點段保持原樣。非熱點段中的引用指向熱點段時通過 GC 內部結構進行間接尋址。這種方式的優(yōu)點是壓縮范圍小、耗時短缺點是實現復雜、間接尋址有性能開銷。.NET Core GC 目前不使用這種方式但在 .NET 7 中引入了更細粒度的段級壓縮優(yōu)化。十五、結語清掃和壓縮是 GC 回收階段的兩個核心操作它們共同決定了 GC 的內存效率和暫停時間。清掃通過 intrusive list 技術實現了零分配耗時穩(wěn)定且可預測壓縮通過移動對象和修復引用消除了碎片但代價較高。.NET Core GC 的設計哲學是能不清壓就不清壓必須清壓時盡量并行化。通過碎片率閾值、budget 自適應、后臺 GC、并發(fā)壓縮等技術.NET Core GC 在大多數場景下將壓縮的 STW 時間控制在幾毫秒到幾十毫秒之間。理解清掃和壓縮的機制有助于開發(fā)者寫出更友好的對象生命周期模式——減少碎片累積、降低壓縮觸發(fā)頻率、避免 LOH 碎片問題。在下一章中我們將深入后臺 GC 的實現07-05看看 .NET Core GC 如何將清掃和壓縮的耗時進一步攤薄到應用線程的分配間隙中。 07-04-源碼-.NET Core GC清掃與壓縮
.NET Core GC 清掃與壓縮篇章07-源碼深度-.NET Core GC |閱讀時間約 45 分鐘一、引言標記階段識別了存活對象后GC 進入回收階段——清掃死亡對象、壓縮存活對象。清掃和壓縮是 GC 中內存效率的決定性因素清掃決定了多少死亡內存被真正釋放壓縮決定了碎片是否累積到影響分配的程度。但清掃和壓縮的代價也不容忽視。一次全堆壓縮可能耗時數十到數百毫秒直接反映在應用的暫停時間上。所以 .NET Core GC 的核心設計哲學是能不清壓就不清壓必須清壓時盡量并行化。這個哲學貫穿了從計劃決策到清掃實現、從壓縮策略到 LOH 特殊處理的每一個環(huán)節(jié)。在展開之前先把本章的定位說清楚。07-03 標記篇已經講完了哪些對象活著本章接著講活著的東西怎么擺回去、死的東西怎么收走。后臺 GC 的并發(fā)編排見 07-05分配路徑見 07-02堆結構與分代布局的背景見 07-01。二、計劃階段Plan Phase2.1 清掃前的決策GC 在執(zhí)行任何清掃動作之前必須先制定計劃。這個計劃決定了哪些代需要清掃、哪些代需要壓縮、LOH 是否需要特殊處理、是否啟用并行清掃。// gc.h - GCPlan 結構體簡化示意不含全部字段 struct GCPlan { bool compact_gen2; // Gen 2 是否需要壓縮 bool compact_loh; // LOH 是否需要壓縮 int sweep_gen0_segments; // Gen 0 需要清掃的段數 int sweep_gen1_segments; // Gen 1 需要清掃的段數 int sweep_gen2_segments; // Gen 2 需要清掃的段數 bool concurrent_sweep; // 是否并發(fā)清掃后臺 GC 時 bool parallel_sweep; // 是否并行清掃多核時 float fragmentation_ratio_gen2; // Gen 2 碎片率 float fragmentation_ratio_loh; // LOH 碎片率 };計劃階段的核心輸入是碎片率。碎片率定義為碎片率 1.0 - (最大連續(xù)空閑塊大小 / 總空閑內存)換句話說碎片率衡量的是空閑內存被分散到了多小的塊里。碎片率為 0 表示所有空閑內存連成一塊碎片率為 1 表示每個空閑塊都只有 1 字節(jié)極端情況。2.2 壓縮觸發(fā)條件壓縮不是每次 GC 都做的——它只在碎片率超過閾值時才觸發(fā)。.NET Core GC 的默認閾值因代而異代壓縮觸發(fā)閾值原因Gen 0不壓縮Gen 0 每次 GC 都重建天然無碎片Gen 1不壓縮Gen 1 是 Gen 0 的緩沖區(qū)本身不獨立管理Gen 2~50%大堆碎片累積快壓縮收益高LOH~70%手動LOH 不使用 bump pointer碎片率天然較低注意 Gen 0 和 Gen 1從不壓縮。這是因為 Gen 0 在每次 GC 時都會重建——所有存活對象晉升到 Gen 1Gen 0 的段被完全清空并重新使用。這種全量晉升 段復用的機制天然消除了 Gen 0 的碎片不需要壓縮。Gen 1 也不壓縮因為它不是一個獨立的內存區(qū)域——它和 Gen 2 共享同一組段。對 Gen 2 的壓縮同時就是對 Gen 1 的壓縮。2.3 計劃決策的時序標記階段完成 │ ▼ 統(tǒng)計各代碎片率 │ ├─ Gen 2 碎片率 50%? │ └─ Yes → compact_gen2 true │ ├─ LOH 手動觸發(fā)壓縮? │ └─ Yes → compact_loh true │ ├─ 并發(fā) GC 且 Gen 2 需要清掃? │ └─ Yes → concurrent_sweep true │ └─ CPU 核數 1 且需要清掃? └─ Yes → parallel_sweep true計劃階段本身非?？焱ǔＶ恍鑾装傥⒚?。它的輸出GCPlan會被傳遞給清掃階段和壓縮階段指導后續(xù)的所有操作。三、清掃階段Sweep Phase3.1 清掃的基本原理清掃是 GC 回收階段的第一步。它的任務很簡單遍歷段中的所有對象把死亡對象的內存標記為可用。但實現起來并不簡單。清掃需要處理以下問題對象遍歷如何高效地遍歷段中的所有對象死亡檢測如何判斷一個對象是否死亡空閑管理如何管理回收后的空閑內存3.1.1 對象遍歷清掃遍歷段的方式與標記遍歷對象圖的方式不同。標記是從根出發(fā)沿著引用字段下鉆而清掃是順序遍歷段中的每個對象按對象大小步進。// SweepSegment 核心邏輯簡化示意 void SweepSegment(heap_segment* seg) { uint8_t* current seg-start; uint8_t* end seg-allocated; while (current end) { Object* obj (Object*)current; // 檢查對象是否被標記 if (!obj-IsMarked()) { // 死亡對象回收其內存 size_t size obj-GetSize(); AddToFreeList(current, size); } else { // 存活對象清除標記位準備下一輪 obj-ClearMark(); } // 按對象大小步進到下一個對象 current obj-GetSize(); } }這個遍歷是順序的對內存的訪問模式非常友好——CPU 預取器可以很好地工作緩存命中率極高。這也是為什么清掃階段通常只占 GC 暫停時間的 10% 左右。3.1.2 死亡檢測死亡檢測通過檢查對象的標記位mark bit實現。標記階段會為每個存活對象設置標記位清掃階段只需檢查這個位標記位為 1存活對象清除標記位繼續(xù)下一個標記位為 0死亡對象回收內存標記位通常存儲在對象頭的某個比特位中訪問速度極快一條位操作指令。3.1.3 空閑管理回收后的空閑內存需要被管理以便后續(xù)分配能夠快速找到可用空間。.NET Core GC 使用按大小分類的空閑列表size-class free list空閑列表結構 ┌─────────────────────────────────────────────────┐ │ FreeList[0] (8-15 字節(jié)) ──? [塊A] ──? [塊B] │ │ FreeList[1] (16-31 字節(jié)) ──? [塊C] ──? NULL │ │ FreeList[2] (32-63 字節(jié)) ──? [塊D] │ │ ... │ │ FreeList[N] (8KB) ──? [塊E] ──? [塊F] │ └─────────────────────────────────────────────────┘空閑列表按大小分類的好處是分配時可以根據請求大小直接定位到對應的鏈表避免全表搜索。這與 slab 分配器的思想類似——將相近大小的空閑塊歸為一類每類維護一個獨立鏈表。3.2 清掃的零分配保證清掃階段有一個重要的設計原則不分配任何新對象。所有需要的臨時數據結構空閑鏈表節(jié)點等都從已回收的對象本身借用內存。這是經典的intrusive list侵入式鏈表技術被回收的對象內存直接作為鏈表節(jié)點使用不需要額外分配內存來維護空閑列表。具體來說死亡對象的第一個字段原本存儲方法表指針之后的位置被覆寫為下一個空閑塊的指針。死亡對象回收前的內存布局 ┌────────────────────────────────────────────┐ │ 方法表指針 (8B) │ 同步塊 (8B) │ 字段數據... │ └────────────────────────────────────────────┘ │ ▼ 回收后方法表指針之后的內存被覆寫 ┌────────────────────────────────────────────┐ │ 方法表指針 (8B) │ 空閑鏈表指針 ?────────────┘ │ (保持不變GC 不再需要) │ └────────────────────────────────────────────┘這種設計的優(yōu)勢零額外內存不需要為空閑鏈表分配任何額外內存。零額外分配不需要在清掃過程中調用malloc或new。零額外開銷空閑鏈表的插入操作只是修改一個指針。不清零被回收的對象不需要清零因為它的內存即將被重新分配使用。3.3 并發(fā)清掃在后臺 GCBackground GC模式下清掃可以與應用線程并發(fā)執(zhí)行。這是 .NET Core 3.0 的重要優(yōu)化時間線示意 應用線程: [Alloc][Alloc][Alloc][Alloc][Alloc][Alloc]... │ │ GC線程: ──[標記 Gen2]──[清掃 Gen2]──────[壓縮 Gen2]── │ │ │ │ ├─ 并發(fā)清掃應用線程繼續(xù)分配 │ └─ 壓縮時需要 STW并發(fā)清掃的關鍵技術是標記-清掃并發(fā)標記階段在后臺線程中并行執(zhí)行清掃階段在標記完成后立即開始不需要等待應用線程全部掛起。只有壓縮階段需要 STWStop-The-World。并發(fā)清掃的實現依賴于以下機制標記位的原子操作標記階段設置標記位使用原子操作清掃階段讀取標記位不需要加鎖。段級鎖清掃器獲取段的鎖后其他線程不能修改該段的內容。段級鎖的粒度比全局鎖小得多減少了競爭。卡片表補償并發(fā)期間應用線程可能創(chuàng)建新的引用這些引用通過卡片表記錄清掃完成后由 GC 進行補償掃描。3.4 并行清掃在多核機器上清掃可以并行化。不同清掃器線程負責不同的段互不干擾段 0 ──? 清掃器線程 0 段 1 ──? 清掃器線程 1 段 2 ──? 清掃器線程 2 段 3 ──? 清掃器線程 3并行清掃的加速比接近線性——4 核機器上清掃 4 個段的耗時約等于清掃 1 個段的 4 倍。但并行清掃也有開銷任務分發(fā)需要將段分配給清掃器線程這本身有同步開銷?？臻e列表合并各線程回收的空閑塊需要合并到全局空閑列表中。緩存競爭多個線程同時寫入空閑列表可能導致緩存行失效。因此并行清掃在段數較多時收益明顯段數較少時可能得不償失。.NET Core GC 會根據段數和 CPU 核數自動決定是否啟用并行清掃。四、壓縮階段Compact Phase4.1 為什么需要壓縮清掃雖然回收了死亡對象的內存但它留下的空閑塊是分散的。如果死亡對象和存活對象交替出現空閑塊也會交替出現清掃前的段布局 ┌──────┬────────┬──────┬────────┬──────┬────────┬──────┐ │ 存活 │ 死亡 │ 存活 │ 死亡 │ 存活 │ 死亡 │ 存活 │ │ ObjA │ ObjX │ ObjB │ ObjY │ ObjC │ ObjZ │ ObjD │ └──────┴────────┴──────┴────────┴──────┴────────┴──────┘ 空閑塊: [ObjX] [ObjY] [ObjZ] 分散在存活對象之間 清掃后未壓縮 ┌──────┬────────┬──────┬────────┬──────┬────────┬──────┬──────┐ │ 存活 │ 死亡 │ 存活 │ 死亡 │ 存活 │ 死亡 │ 存活 │ 空閑 │ │ ObjA │ ObjX │ ObjB │ ObjY │ ObjC │ ObjZ │ ObjD │ │ └──────┴────────┴──────┴────────┴──────┴────────┴──────┴──────┘ 空閑塊分散在 ObjA/ObjB/ObjC/ObjD 之間 → 碎片化 壓縮后 ┌──────┬──────┬──────┬──────┬──────────────────────────────┐ │ 存活 │ 存活 │ 存活 │ 存活 │ 連續(xù)空閑空間 │ │ ObjA │ ObjB │ ObjC │ ObjD │ (可分配區(qū)域) │ └──────┴──────┴──────┴──────┴──────────────────────────────┘ 所有存活對象移到段開頭空閑空間集中在段尾 → 無碎片壓縮的核心價值是將分散的空閑塊合并為連續(xù)的可用空間。沒有壓縮碎片會逐步累積最終導致即使總空閑內存足夠也無法分配大塊對象因為找不到足夠大的連續(xù)空間。4.2 壓縮的三個步驟壓縮是 GC 中最復雜的操作涉及三個緊密耦合的步驟步驟 1計算新地址// ComputeNewAddresses簡化示意 void ComputeNewAddresses(int generation) { uint8_t* write_ptr segment-start; // 寫入指針從段頭開始 for (uint8_t* current segment-start; current segment-allocated; current obj-GetSize()) { Object* obj (Object*)current; if (obj-IsMarked()) { // 存活對象記錄新地址 obj-SetNewAddress(write_ptr); write_ptr obj-GetSize(); } // 死亡對象跳過不分配新地址 } segment-allocated write_ptr; // 更新段的分配上限 }這一步是純讀取 順序寫入對內存的訪問模式非常友好。每個存活對象只被訪問一次按順序從段頭掃到段尾。關鍵細節(jié)新地址單調遞增存活對象按原順序排列新地址嚴格遞增。這意味著壓縮不會改變對象的相對順序有利于緩存局部性。死亡對象被跳過死亡對象不占用新地址空間相當于在計算新地址的同時完成了收縮。對象大小不變壓縮不改變對象大小只改變對象的起始地址。步驟 2修復引用Fix References// FixReferences簡化示意 void FixReferences(int generation) { // 修復棧上的引用 for (Thread* thread : suspended_threads) { for (RefLocation ref : thread-stack_references) { if (ref.target segment_start ref.target segment_end) { *ref.location ref.target-GetNewAddress(); } } } // 修復堆上的引用存活對象中的引用字段 for (uint8_t* obj segment-start; obj segment-allocated; ) { if (obj-IsMarked()) { obj-FixReferences(); // 對象內部的引用字段全部更新 obj obj-GetSize(); } } // 修復靜態(tài)字段 for (StaticRef ref : static_references) { if (ref.target segment_start ref.target segment_end) { *ref.location ref.target-GetNewAddress(); } } // 修復句柄表 for (HandleEntry entry : handle_table) { if (entry.target segment_start entry.target segment_end) { entry.target entry.target-GetNewAddress(); } } }引用修復是壓縮中最復雜、最耗時的部分。需要修復的引用來源包括棧引用各線程棧幀中指向壓縮段的對象引用。堆引用存活對象內部的引用字段指向同一段或其他段中的對象。靜態(tài)字段類靜態(tài)變量中指向壓縮段的引用。句柄表GCHandle 中指向壓縮段的引用。GC 內部結構如卡片表、根表等。引用修復的關鍵約束必須在復制之前完成。因為復制會移動對象如果先復制再修復引用修復時找不到舊地址。步驟 3復制對象數據// CopyObjects簡化示意 void CopyObjects(int generation) { for (uint8_t* current segment-start; current segment-old_allocated; current obj-GetSize()) { Object* obj (Object*)current; if (obj-IsMarked()) { uint8_t* new_addr obj-GetNewAddress(); if (current ! new_addr) { // 對象需要移動復制數據 size_t size obj-GetSize(); MemMove(new_addr, current, size); } } } }復制階段使用MemMove批量移動對象數據。由于對象是按順序處理的且新地址也是順序遞增的MemMove的調用可以很好地利用 CPU 的 DMA 緩存行預取和 SIMD 指令。關鍵優(yōu)化原地跳過如果對象的新地址等于舊地址通常發(fā)生在段尾部的存活對象直接跳過不復制。批量復制MemMove內部使用 SIMD 指令如 AVX2一次復制 32 或 64 字節(jié)比逐字節(jié)復制快數倍。寫合并多個小對象的復制可以合并為一次MemMove調用減少函數調用開銷。4.3 壓縮的代價壓縮涉及大量內存復制和引用更新是 GC 中最耗時的操作。以下是一個典型場景的耗時分解100MB Gen 2 堆碎片率 60%一次全量壓縮 步驟 耗時 占比 ───────────────────────────────────── 計算新地址 5-10ms ~15% 修復引用 20-80ms ~60% ← 最耗時 復制對象數據 5-10ms ~15% 清理段元數據 1-2ms ~5% ───────────────────────────────────── 合計 30-100ms 100%各步驟的耗時特征計算新地址O(n) 順序遍歷緩存友好耗時與存活對象數成正比。修復引用O(n r)n 為存活對象數r 為引用字段總數。引用字段越多耗時越長。棧引用和句柄表引用的修復需要逐個處理無法批量優(yōu)化。復制對象數據O(n)但MemMove的常數極小實際耗時通常低于引用修復。清理段元數據O(1) 或 O(段數)耗時可忽略。4.4 壓縮的并發(fā)化.NET Core GC 在 .NET 6 中引入了并發(fā)壓縮的部分優(yōu)化。核心思想是將壓縮拆分為多個階段其中計算新地址和修復引用可以在后臺線程中并行執(zhí)行只有最后的復制 最終引用修復需要 STW。傳統(tǒng)壓縮全 STW [計算新地址][修復引用][復制對象][最終修復] ← 全部 STW 并發(fā)壓縮.NET 6 [計算新地址]──[修復引用] ← 后臺線程并行執(zhí)行 │ ▼ STW 切換點 [復制對象][最終修復] ← 短 STW這種設計的優(yōu)勢是將 STW 時間從幾十毫秒降低到幾毫秒。后臺階段雖然也消耗 CPU 和內存帶寬但不影響應用線程只有最后的 STW 階段會暫停應用。五、LOH 清掃與壓縮5.1 LOH 為什么不同LOH大對象堆的清掃和壓縮與 SOH小對象堆有本質區(qū)別原因在 07-02 中已經提到過不使用 bump pointerLOH 使用空閑列表管理天然不存在清掃后合并空閑塊的需求。對象生命周期長LOH 對象通常存活整個應用生命周期碎片率增長緩慢。壓縮代價極高LOH 對象可能從 85KB 到幾 GB復制一個大對象的代價相當于復制成千上萬個小對象。5.2 LOH 清掃LOH 的清掃與 SOH 類似也是遍歷死亡對象并回收內存。但由于 LOH 對象數量遠少于 SOH 對象LOH 清掃的耗時通?？梢院雎圆挥?。// LOH Sweep簡化示意 void SweepLOH() { for (auto entry : loh_free_list) { if (!entry.obj-IsMarked()) { // 死亡 LOH 對象回收 AddToLOHFreeList(entry.obj, entry.size); } else { // 存活 LOH 對象清除標記 entry.obj-ClearMark(); } } }5.3 LOH 壓縮LOH 壓縮是一個手動觸發(fā)的操作默認不自動執(zhí)行。這是因為 LOH 壓縮的代價極高——它需要移動所有存活的大對象并更新所有指向它們的引用。// 手動觸發(fā) LOH 壓縮 GCSettings.LargeObjectHeapCompactionMode GCLargeObjectHeapCompactionMode.CompactOnce; // 下一次 GC.Collect() 會壓縮 LOH GC.Collect();LOH 壓縮的觸發(fā)條件觸發(fā)方式條件說明手動觸發(fā)GCSettings.LargeObjectHeapCompactionMode CompactOnce下一次 GC.Collect() 觸發(fā)永久模式GCSettings.LargeObjectHeapCompactionMode CompactEveryTime每次 GC.Collect() 都觸發(fā)不推薦自動觸發(fā)無.NET Core 默認不自動壓縮 LOHLOH 壓縮的代價內存復制所有存活 LOH 對象需要被移動復制量可能達到數 GB。引用更新所有指向 LOH 對象的引用需要更新包括棧引用、堆引用、靜態(tài)字段、句柄表。STW 時間長LOH 壓縮通常需要 STW 數百毫秒到數秒取決于 LOH 大小和存活對象數。因此LOH 壓縮應該謹慎使用只在確實存在嚴重碎片問題且影響分配時才觸發(fā)。5.4 LOH 碎片問題與緩解LOH 碎片是 .NET 中一個經典問題。當頻繁分配和釋放大小不一的 LOH 對象時空閑列表會逐漸碎片化最終導致即使總空閑內存足夠也無法分配新的大對象。緩解 LOH 碎片的策略避免頻繁分配/釋放 LOH 對象使用對象池復用 LOH 對象?？刂茖ο蟠笮”M量使對象大小低于 85,000 字節(jié)閾值使其走 SOH 路徑。定期手動壓縮在低峰期手動觸發(fā) LOH 壓縮。使用ArrayPoolT對于數組類型的 LOH 對象使用數組池復用。六、壓縮的代價與觸發(fā)策略6.1 壓縮耗時分解一次完整的 Gen 2 壓縮100MB 堆的耗時構成Full GC 耗時分解100MB 堆碎片率 60% 標記: ████████████████████████ 60% (15-30ms) ← 后臺GC改造目標 清掃: ████ 10% (2-5ms) 壓縮: ██████ 30% (10-50ms) ← 最慢但僅在碎片率超閾值時觸發(fā) ───────────────────────────────────────────────── 合計: 100% (27-85ms)關鍵觀察標記占大頭標記是耗時最長的階段也是后臺 GC 優(yōu)化的主要目標。清掃最穩(wěn)定清掃耗時波動最小因為它只依賴存活對象數與碎片率無關。壓縮最可變壓縮耗時波動最大從幾毫秒低碎片到數百毫秒高碎片 大堆。6.2 壓縮觸發(fā)策略.NET Core GC 的壓縮觸發(fā)策略可以概括為保守觸發(fā)按需壓縮。是否壓縮的決策邏輯 1. Gen 0? → 不壓縮每次 GC 都重建 2. Gen 1? → 不壓縮與 Gen 2 共享段隨 Gen 2 一起壓縮 3. Gen 2? ├─ 碎片率 50%? → Yes → 壓縮 └─ No → 不壓縮 4. LOH? ├─ 手動觸發(fā)? → Yes → 壓縮 └─ No → 不壓縮即使碎片率很高這個策略的核心考量壓縮的代價高壓縮需要移動對象、更新引用耗時可能遠超清掃。碎片不是最緊急的問題只要還有足夠大的連續(xù)空閑塊碎片不會導致分配失敗。預算機制優(yōu)先通過 budget 機制控制 GC 頻率比通過壓縮控制碎片更經濟。6.3 壓縮的替代方案在某些場景下壓縮不是最優(yōu)選擇。.NET Core GC 提供了以下替代方案段復用回收的段不還給操作系統(tǒng)留給下輪復用。這避免了還了再要的系統(tǒng)調用開銷?？臻e列表優(yōu)化通過按大小分類的空閑列表提高小塊的分配命中率減少對新段的需求。晉升策略調優(yōu)調整對象晉升策略讓短命對象更快離開 Gen 0減少 Gen 0 的碎片累積。七、GC 耗時分解與優(yōu)化方向7.1 一次 Full GC 的完整耗時一次 Full GC100MB Gen 2 堆碎片率 40%的耗時構成 階段 耗時 是否 STW 可并發(fā) ───────────────────────────────────────────────── 掛起線程 1-5ms Yes 否 根掃描 1-3ms Yes 否 標記 Gen 0/1 5-10ms 部分 是后臺 標記 Gen 2 10-20ms 部分 是后臺 清掃 Gen 0 1-2ms 部分 是并發(fā) 清掃 Gen 1/2 2-5ms 部分 是并發(fā) 壓縮 Gen 2 10-30ms Yes 否 修復引用 5-20ms Yes 部分 恢復線程 1-3ms Yes 否 ───────────────────────────────────────────────── 總 STW 時間 20-60ms 總耗時含并發(fā) 30-100ms7.2 優(yōu)化方向基于耗時分解GC 優(yōu)化的優(yōu)先級如下減少標記耗時后臺 GC 已經將標記移到后臺進一步優(yōu)化空間有限。減少壓縮觸發(fā)通過 budget 自適應和晉升策略降低碎片率減少壓縮觸發(fā)頻率。減少 STW 時間并發(fā)壓縮.NET 6將大部分壓縮工作移到后臺進一步降低 STW 時間。減少清掃耗時清掃已經很快10%優(yōu)化空間有限。八、清掃和壓縮的時機選擇8.1 何時壓縮.NET Core GC 根據以下因素決定是否壓縮碎片率空閑空間分散度超過閾值時觸發(fā)壓縮。Gen 2 默認閾值約 50%LOH 默認不自動壓縮。最近一次壓縮的時間間隔避免頻繁壓縮。如果剛做過壓縮即使碎片率略有上升也不會立即再次壓縮。堆大小大堆壓縮的收益更大——碎片浪費的絕對空間更多壓縮后釋放的連續(xù)空間也更可觀。內存壓力當操作系統(tǒng)通知內存緊張時GC 可能降低壓縮閾值更積極地壓縮以釋放空間。8.2 實際項目中的觀察在實際項目中大多數 GC 只需要清掃不需要壓縮。壓縮通常只在以下場景觸發(fā)長運行服務運行時間越長碎片累積越多壓縮觸發(fā)越頻繁。對象生命周期差異大如果同時存在短命對象和長命對象長命對象之間的空洞會逐步累積為碎片。LOH 頻繁分配雖然 LOH 不自動壓縮但 LOH 碎片會影響 Gen 2 的碎片率間接觸發(fā) Gen 2 壓縮。九、清掃的零分配保證9.1 Intrusive List 技術清掃階段有一個重要的設計原則不分配任何新對象。所有需要的臨時數據空閑鏈表節(jié)點等從已回收的對象本身借用內存。這是經典的intrusive list侵入式鏈表技術。具體來說被回收的死亡對象的內存被直接用作空閑鏈表的節(jié)點。死亡對象的第一個字段原本存儲方法表指針之后的位置被覆寫為下一個空閑塊的指針。這樣空閑鏈表不需要任何額外的內存分配——它寄生在已回收的對象內存上。死亡對象回收前的內存布局 ┌──────────────────────────────────────────────────────┐ │ 方法表指針 (8B) │ 同步塊 (8B) │ 字段數據 (N 字節(jié)) │ │ ← 對象頭 ← 對象數據 │ └──────────────────────────────────────────────────────┘ │ ▼ 回收后方法表指針之后的內存被覆寫為鏈表指針 ┌──────────────────────────────────────────────────────┐ │ 方法表指針 (8B) │ 空閑鏈表下一個節(jié)點指針 (8B) │ ... │ │ (GC 不再需要方法表指針) │ └──────────────────────────────────────────────────────┘ │ ▼ 插入空閑鏈表 FreeList[size_class] ──? [此塊] ──? [下一個空閑塊] ──? ...9.2 零分配的優(yōu)勢這種設計的優(yōu)勢是多方面的零額外內存不需要為空閑鏈表分配任何額外內存?？臻e鏈表的節(jié)點就是死亡對象本身。零額外分配不需要在清掃過程中調用malloc或new避免了在 GC 過程中觸發(fā)遞歸 GC 的風險。零額外開銷空閑鏈表的插入操作只是修改一個指針時間復雜度 O(1)。不清零被回收的對象不需要清零。因為它的內存即將被重新分配使用清零是浪費。緩存友好空閑鏈表節(jié)點與對象數據在同一塊內存中訪問局部性好。9.3 與 Java GC 的對比Java 的 OpenJDK GC如 G1使用獨立的空閑列表結構每個空閑塊需要額外的元數據來記錄大小和下一個節(jié)點。這意味著清掃階段需要為每個死亡塊分配一個空閑節(jié)點。.NET 的 intrusive list 技術避免了這一開銷是零分配保證的關鍵。十、與 Unity GC 的對比10.1 Unity (SGen) 的清掃與壓縮Unity 的 GC 基于 Mono 的 SGenScavenge-Sweep Garbage Collector與 .NET Core GC 有顯著差異特性.NET Core GCUnity (SGen)清掃方式順序遍歷 intrusive list標記-清掃 獨立空閑列表壓縮策略Gen 2 按需壓縮分代壓縮Scavenge 階段LOH 壓縮手動觸發(fā)無專門 LOH并發(fā)清掃.NET 3.0 支持增量清掃可配置零分配保證清掃階段不分配部分支持壓縮暫停時間30-100ms100MB10-50ms100MBUnity 的增量清掃是應對移動設備資源限制的特殊設計——將清掃拆分成多個小片段避免單次清掃暫停過長。而 .NET Core GC 更傾向于一次性完成通過后臺 GC 和并發(fā)壓縮來降低單次暫停的代價。10.2 為什么 Unity 的壓縮暫停更短Unity SGen 的壓縮暫停通常比 .NET Core GC 短原因有三堆更小移動設備的堆通常只有幾十 MB而 .NET 服務端應用的堆可能達到數 GB。壓縮耗時與堆大小成正比。壓縮策略更保守SGen 只在必要時壓縮小代不壓縮整個堆。對象更小移動應用的對象通常較小復制代價更低。但這些差異也反映了平臺約束移動設備內存有限不能像服務端那樣使用大堆和 LOH。十一、量化數據的口徑說明11.1 數據性質本文給出的所有量化數據耗時、百分比、閾值等均為典型估算或示例量級非實測常數。實際數值取決于以下因素堆大小100MB 堆與 10GB 堆的耗時相差兩個數量級。碎片率碎片率從 10% 上升到 80%壓縮耗時可能增加 5-10 倍。CPU 核數并行清掃和壓縮的加速比接近線性但受內存帶寬限制。對象大小分布大對象多的堆壓縮耗時更長。引用密度引用字段多的對象修復耗時更長。11.2 典型場景參考以下數據基于 16 核 64GB 服務端場景的典型估算非實測場景Gen 0 耗時Gen 2 耗時是否壓縮低碎片 (20%)0.5-2ms10-30ms否中碎片 (20-50%)0.5-2ms20-60ms否高碎片 (50%)0.5-2ms50-150ms是LOH 壓縮N/A100-500ms是手動十二、總結與實踐建議12.1 核心要點回顧清掃和壓縮是 GC 回收階段的核心它們的設計體現了按需觸發(fā)、零分配保證、并發(fā)優(yōu)化的思想清掃回收死亡對象通過 intrusive list 技術實現零分配耗時僅占 GC 的 10%。壓縮消除碎片將分散的空閑塊合并為連續(xù)空間但代價高30% 的 GC 耗時。按需觸發(fā)壓縮只在碎片率超過閾值時觸發(fā)大多數 GC 只需清掃。并發(fā)優(yōu)化后臺 GC 將清掃移到后臺.NET 6 將壓縮的部分工作移到后臺。LOH 特殊處理LOH 不自動壓縮需要手動觸發(fā)代價極高。12.2 實踐建議基于對清掃和壓縮的理解以下是針對 C# 開發(fā)者的實踐建議理解壓縮觸發(fā)條件壓縮只在碎片率超過閾值時觸發(fā)。如果你的應用碎片率始終很低壓縮幾乎不會成為性能瓶頸。謹慎使用 LOH 壓縮GCSettings.LargeObjectHeapCompactionMode CompactOnce是核武器級別的操只在確實存在嚴重 LOH 碎片且影響分配時才使用。關注 Gen 2 堆大小Gen 2 堆越大壓縮耗時越長。通過減少長命對象的數量和大小可以降低壓縮耗時。避免對象生命周期混疊短命對象和長命對象混在一起會導致碎片快速累積?？梢酝ㄟ^分層設計將短命和長命對象放在不同的類中來減少碎片。監(jiān)控碎片率使用 PerfView 或 ETW 事件監(jiān)控 GC 碎片率發(fā)現異常上升趨勢。理解零分配保證清掃階段不分配新對象所以不會觸發(fā)遞歸 GC。這意味著清掃的耗時是確定性的不會因 GC 嵌套而膨脹。12.3 清掃與壓縮的決策樹GC 回收階段 │ ├─ 標記階段完成 │ │ │ ├─ Gen 0? │ │ └─ 清掃重建段天然無碎片 │ │ │ ├─ Gen 1? │ │ └─ 清掃隨 Gen 2 一起處理 │ │ │ ├─ Gen 2? │ │ ├─ 碎片率 50%? │ │ │ ├─ Yes → 清掃 → 壓縮 │ │ │ └─ No → 清掃不壓縮 │ │ └─ 并發(fā)清掃? │ │ ├─ Yes → 后臺清掃 │ │ └─ No → STW 清掃 │ │ │ └─ LOH? │ ├─ 手動壓縮? │ │ ├─ Yes → 清掃 → 壓縮STW耗時高 │ │ └─ No → 清掃不壓縮 │ └─ 碎片率 70%? │ └─ 仍不自動壓縮LOH 壓縮代價過高十三、深入壓縮的引用修復細節(jié)13.1 引用修復的挑戰(zhàn)引用修復是壓縮階段最復雜的部分面臨以下挑戰(zhàn)引用來源多樣棧引用、堆引用、靜態(tài)字段、句柄表、GC 內部結構每種來源的修復方式不同。引用目標可能移動被引用的對象可能在同一段需要修復、在不同段不需要修復因為 GC 內部結構已經處理了跨段引用。修復順序必須先修復所有引用再移動對象數據。否則修復時找不到舊地址。13.2 棧引用的修復棧引用的修復是最直接的部分。在壓縮開始前所有應用線程被掛起GC 可以安全地掃描每個線程的棧幀// 棧引用修復簡化示意 void FixStackReferences(Thread* thread) { for (StackFrame* frame : thread-frames) { for (RefLocation ref : frame-local_variables) { if (ref.is_gc_ref ref.target_in_compressed_segment) { // 更新引用為新地址 *ref.location ref.target-GetNewAddress(); } } for (RefLocation ref : frame-parameters) { if (ref.is_gc_ref ref.target_in_compressed_segment) { *ref.location ref.target-GetNewAddress(); } } } }棧引用修復的關鍵點線程必須掛起修復棧引用時應用線程不能運行否則棧內容可能被改寫。寄存器也需要修復除了棧引用掛起時保存的寄存器快照中的引用也需要修復。修復是原地進行的直接修改棧幀中的引用值不需要移動棧本身。13.3 堆引用的修復堆引用的修復比棧引用復雜得多。存活對象內部的引用字段可能指向同一段中的任何對象也可能指向其他段。只有指向同一段的引用需要修復// 堆引用修復簡化示意 void FixHeapReferences(heap_segment* segment) { for (uint8_t* obj segment-start; obj segment-old_allocated; ) { if (obj-IsMarked()) { // 遍歷對象的引用字段 MethodTable* mt obj-GetMethodTable(); for (RefField* field : mt-reference_fields) { uint8_t* ref_addr obj field-offset; Object* target *(Object**)ref_addr; // 只修復指向同一段的引用 if (target segment-start target segment-end) { *(Object**)ref_addr target-GetNewAddress(); } } obj obj-GetSize(); } else { obj obj-GetSize(); // 死亡對象跳過 } } }堆引用修復的耗時取決于引用字段的數量。一個包含 10 個引用字段的對象修復時需要檢查 10 次、最多更新 10 次。對于引用字段多的對象如字典、列表修復耗時可能顯著高于簡單對象。13.4 句柄表的修復句柄表的修復相對簡單因為句柄表是一個集中管理的數據結構// 句柄表修復簡化示意 void FixHandleTable(heap_segment* segment) { for (HandleEntry entry : handle_table) { if (entry.target segment-start entry.target segment-end) { entry.target entry.target-GetNewAddress(); } } }句柄表的大小通常遠小于堆修復耗時可以忽略不計。但需要注意固定句柄pinned handle——固定句柄指向的對象在壓縮時不能被移動壓縮算法需要跳過這些對象。十四、深入壓縮算法的變體14.1 傳統(tǒng)壓縮移動對象前面描述的壓縮方式是移動對象將存活對象從舊地址復制到新地址。這是最常見的壓縮方式優(yōu)點是實現簡單、碎片消除徹底。但移動對象有一個問題指針不變性。如果外部代碼持有對象的原始指針如通過GCHandle的固定句柄移動對象會導致指針失效。這就是為什么固定句柄指向的對象不能被移動。14.2 間接壓縮更新指針另一種壓縮方式是不移動對象只更新引用。具體來說不移動任何對象數據。為每個對象維護一個轉發(fā)指針forwarding pointer指向壓縮后的邏輯位置。所有引用指向轉發(fā)指針而不是直接指向對象。傳統(tǒng)壓縮移動對象 舊地址: [ObjA][ObjB][ObjC] → 新地址: [ObjA][ObjB][ObjC][空閑] 引用 → ObjA 引用 → ObjA (新地址) 間接壓縮更新指針 舊地址: [ObjA][ObjB][ObjC] → 邏輯地址: [ObjA][ObjB][ObjC][空閑] 引用 → ObjA 引用 → 轉發(fā)指針 → ObjA (邏輯地址)間接壓縮的優(yōu)點是不需要移動對象數據缺點是引入了額外的間接尋址每次引用都需要多一次內存訪問。這在性能敏感的場景中是不可接受的所以 .NET Core GC 不使用這種方式。14.3 部分壓縮只壓縮熱點段還有一種優(yōu)化思路是只壓縮熱點段即分配最頻繁的段而不是壓縮整個代。這種部分壓縮的策略是識別熱點段分配最頻繁的段。只壓縮熱點段非熱點段保持原樣。非熱點段中的引用指向熱點段時通過 GC 內部結構進行間接尋址。這種方式的優(yōu)點是壓縮范圍小、耗時短缺點是實現復雜、間接尋址有性能開銷。.NET Core GC 目前不使用這種方式但在 .NET 7 中引入了更細粒度的段級壓縮優(yōu)化。十五、結語清掃和壓縮是 GC 回收階段的兩個核心操作它們共同決定了 GC 的內存效率和暫停時間。清掃通過 intrusive list 技術實現了零分配耗時穩(wěn)定且可預測壓縮通過移動對象和修復引用消除了碎片但代價較高。.NET Core GC 的設計哲學是能不清壓就不清壓必須清壓時盡量并行化。通過碎片率閾值、budget 自適應、后臺 GC、并發(fā)壓縮等技術.NET Core GC 在大多數場景下將壓縮的 STW 時間控制在幾毫秒到幾十毫秒之間。理解清掃和壓縮的機制有助于開發(fā)者寫出更友好的對象生命周期模式——減少碎片累積、降低壓縮觸發(fā)頻率、避免 LOH 碎片問題。在下一章中我們將深入后臺 GC 的實現07-05看看 .NET Core GC 如何將清掃和壓縮的耗時進一步攤薄到應用線程的分配間隙中。