CLR 深度解析：大型物件堆 (LOH) 運作機制與效能調優

.NET CLR 的垃圾收集器 (GC) 將物件依大小劃分為小型物件（< 85,000 位元組）與大型物件（≥ 85,000 位元組），後者配置於專屬的大型物件堆 (Large Object Heap, LOH)。LOH 的特殊回收行為——不壓縮、僅第 2 代回收、自由空間鏈表管理——對大型陣列、巨型字串、序列化緩衝區等常見場景有深遠的效能影響。本文深入剖析 LOH 分配與回收機制、碎片化成因、監控指標與調優策略。

LOH 與分代回收架構

CLR 托管堆在邏輯上分為三代：Gen 0、Gen 1、Gen 2。小型物件出生於 Gen 0，存活者晉升至 Gen 1、Gen 2。大型物件則直接配置於 LOH，**邏輯上隸屬 Gen 2**，僅在第 2 代回收 (Full GC) 時被掃描回收。

物理上，GC 透過 VirtualAlloc 向作業系統保留記憶體區段：

• 小型物件堆 (SOH) 區段：服務 Gen 0/1/2 小型物件
• 大型物件堆 (LOH) 區段：專服 ≥ 85 KB 物件

啟動時各配置一個初始區段，隨著配置需求以較小塊提交記憶體。

為何 LOH 不壓縮？

壓縮意味著將物件在記憶體中搬移，需更新所有參考該物件的指標。對大型物件（動輒數 MB 甚至數百 MB），搬移成本極高（記憶體複製 + 指標修正），且大型物件通常壽命較長、參考較少，壓縮收益不彰。因此 CLR 選擇：

1. 掃描 LOH 區段，標記存活物件
2. 將相鄰的已回收空間合併為自由塊，加入自由空間鏈表
3. 後續配置請求優先從自由鏈表尋找合適塊（最佳適配）

警告：雖目前不壓縮，但未來版本可能改變。若需確保物件不被移動，必須使用 GCHandle.Alloc(obj, GCHandleType.Pinned) 固定物件。

LOH 配置與回收觸發條件

配置大型物件時，若 LOH 可用空間不足：

1. 嘗試向 OS 申請新區段 (VirtualAlloc)
2. 若失敗，觸發第 2 代 GC 釋放空間
3. 仍不足則拋出 OutOfMemoryException

第 2 代 GC 觸發條件：

• Gen 0/1/2 或 LOH 配置超過各自閾值（動態調整）
• 呼叫 GC.Collect() 或 GC.Collect(GC.MaxGeneration)
• 系統記憶體壓力高，收到 OS 高記憶體通知

關鍵特性：LOH 回收與 Gen 2 綁定。若應用程式頻繁配置臨時大型物件，會強制頻繁 Full GC，同時掃描龐大 Gen 2，造成嚴重效能抖動。

LOH 碎片化：兩種「碎片」的區別

圖 1：LOH 回收後形成自由空間

圖 2：GC 釋放空區段給 OS

1. 托管堆碎片：LOH 內部自由空間破碎，雖總可用空間足夠，但無單一連續塊滿足大型配置。可透過 SOS !dumpheap -type Free 觀察。
2. 虛擬記憶體 (VM) 位址空間碎片：頻繁 VirtualAlloc/VirtualFree 導致進程位址空間出現大量細小 MEM_FREE 區域，雖托管堆內部完好，但無法配置大區段。需用 !address (WinDbg) 分析。

臨時大型物件是 VM 碎片主因：頻繁申請/釋放區段 → 位址空間破碎 → 後續大型配置失敗 → OOM。

效能監控：效能計數器與 SOS 偵錯

圖 3：效能監視器新增 LOH 計數器

關鍵計數器：

• # Gen 2 Collections：Full GC 次數（計數器於 GC 結束遞增）
• Large Object Heap Size：LOH 當前大小（含自由空間），GC 結束更新

SOS 偵錯指令 (.loadby sos mscorwks)：

!eeheap -gc        // 顯示各堆區段範圍與大小
!dumpheap -stat    // 統計各類型物件計數與大小
!dumpheap -stat 023e1000 033db630  // 限定 LOH 範圍統計

範例輸出顯示 LOH 佔用 49.7 MB，主要為 System.Object[] (8 MB) 與 System.Byte[] (6.6 MB)，自由空間 2 MB。

調優策略：減少 LOH 壓力

1. 物件池化

頻繁配置/釋放大型陣列（如網路緩衝區、序列化暫存區）應改用物件池。Yun Jin 部落格提供 BufferPool 實作參考。核心模式：

// 取用
byte[] buffer = BufferPool.Rent(size);
try { ... } finally { BufferPool.Return(buffer); }

2. 避免大型陣列持有參考

若大型陣列元素為參考型別（如 Node[]），GC 掃描每個元素成本高。改用索引而非直接參考：

// 高 GC 成本
class Node { Data d; Node left, right; }
Node[] tree = new Node[1000000];

// 低 GC 成本
class Node { Data d; uint leftIndex, rightIndex; }
Node[] tree = new Node[1000000]; // 元素無參考，GC 忽略陣列內部

3. VM Hoarding (CLR 2.0+)

透過宿主 API 指定 STARTUP_HOARD_GC_VM 啟動旗標，GC 釋放區段時僅將記憶體退回備用清單 (VirtualFree(MEM_DECOMMIT))，不歸還 OS (MEM_RELEASE)，下次需求直接從備用清單滿足，避免 VM 碎片。適用於長期運行、記憶體使用穩定的伺服器應用。

4. 固定大型物件 (Pinning) 謹慎使用

固定物件阻礙 GC 壓縮 SOH，若大量固定小物件反而惡化碎片。僅在 P/Invoke 需傳遞緩衝區指標時短暫固定。

總結

• LOH 門檻 85 KB，邏輯屬 Gen 2，僅 Full GC 回收，不壓縮，自由空間鏈表管理
• 頻繁臨時大型配置 → 頻繁 Full GC + VM 碎片 → 效能崩潰
• 監控 # Gen 2 Collections 與 Large Object Heap Size，SOS 分析物件分佈
• 核心對策：物件池化、避免大型參考陣列、VM Hoarding (伺服器場景)
• 切勿依賴「LOH 永不壓縮」實作細節，需固定時請明確 GCHandle.Alloc

掌握 LOH 行為，是構建高效能、低延遲 .NET 系統的關鍵能力之一。