Memory Management (III) - .NET CLR ?

摘要提示

• 指標問題: C 語言的指標導致無法自動重新定址，形成無法避免的記憶體碎片。
• 參考新語言: Java/C# 移除指標、僅保留參考，讓執行環境有機會進行搬移與整理記憶體。
• GC 與壓縮: .NET/Java 的垃圾回收具備 compact collection 概念，理論上可解碎片。
• 問題驗證: 以 C# 重現先前 C 範例，驗證在 CLR 下碎片能否被回收與合併。
• 初始結果: 預設 GC 無法找回被釋放的大塊空間，實測為 FAIL。
• 強制回收: 呼叫 GC.Collect(GC.MaxGeneration) 後改善有限，仍無法有效合併空間。
• 執行緒型 GC: 關閉 gcConcurrent 無助於問題，與碎片合併沒有直接關係。
• 伺服器 GC: 啟用 gcServer 後，回收表現大幅改善，顯示發生了 compact collection。
• 文獻缺口: 官方與多數文章多談世代回收，鮮少明言 server GC 進行壓縮回收。
• 結論與建議: 在需要對抗碎片的情境下，啟用 gcServer 能顯著改善記憶體再利用。

全文重點

本文延續前兩篇記憶體管理的討論，從「碎片化」問題切入，探究在 .NET CLR 下是否能透過語言與執行環境的機制徹底解決。C 語言因為提供指標，執行中對記憶體位置有絕對位址的直接操作，使得系統無法在不中斷語意的前提下對物件進行搬移與重新定址，因此碎片在語言層面無法自動排除。相較之下，Java/C# 等新一代語言移除了「指標」概念，保留「參考」，讓 CLR/Java VM 有能力於回收過程進行物件搬移與空間壓縮，即所謂的 compact collection，理論上可以避免碎片問題長期惡化。

作者以 C# 重寫先前用 C 所做的壓力測試：先連續配置 64MB 的 byte 陣列直至 OutOfMemoryException，之後交錯釋放其中一半，然後嘗試配置 72MB 的陣列，觀察是否能成功配置以驗證可用連續空間是否被有效合併。測試環境為 .NET 2.0（x86）、Windows Vista x86。

初次測試結果顯示，預設設定下即使釋放了大量記憶體，仍無法配置新的大塊陣列，顯示碎片未被整理。作者進一步手動呼叫 GC.Collect(GC.MaxGeneration) 嘗試觸發完整回收，結果僅略有改善，仍無法達到期待的連續空間回收效果。接著關閉 gcConcurrent（並行 GC），期望避免 GC 與主執行緒交錯導致觀察偏差，結果亦無顯著幫助。

轉而啟用 gcServer（伺服器 GC）後，情況大幅改觀：在釋放了部分記憶體之後，重新配置大尺寸區塊的成功率明顯提升，顯示 GC 在此模式下進行了有效的 compact collection（壓縮與搬移），讓可用空間重新變為大塊連續區段，進而不再受碎片困擾。雖然官方與多數文章對 server GC 的說明多著墨於伺服器環境的吞吐與工作集行為，並未明白指出「server GC 一定會進行壓縮回收」或「workstation GC 不會」，但本實測驗證在啟用 gcServer 後，CLR 確實會做出足以消除碎片影響的壓縮行為。

作者最後指出：在現代受管環境中，語言設計與執行時的 GC 策略確實能解決傳統指標導致的碎片問題；實務上若面臨大物件或連續大區塊配置需求，建議評估啟用 gcServer。文末附上實驗程式與設定檔，鼓勵讀者於不同平台實測比較，並回報差異。

段落重點

引言與動機：從 C 的碎片問題轉向 .NET

作者回顧先前文章中的記憶體碎片問題，提出疑問：若改用 .NET 開發，是否能藉由 CLR 與 GC 自動處理而不再受碎片困擾？本文即以此為重點，並以實測驗證。同時也提到多數文章過度聚焦 GC 世代與 IDisposable 等議題，未能直指碎片與壓縮回收的核心，因而動手做了對照試驗來驗證實際行為。

指標的根本限制：為何 C 無法自動搬移記憶體

說明 C 語言因為指標能直接取得記憶體的絕對位址，使得系統在執行期間無法安全地進行物件搬移與重新定址，一旦搬移就可能破壞指標語意，導致碎片化無解。因此，從語言層面移除指標、改以參考 model，才有可能讓執行環境在回收時進行 relocation，將零碎空間合併為大塊連續空間，根本上解決碎片問題。

受管環境的優勢：GC 與 compact collection 的可行性

Java/C# 移除指標保留參考，使 CLR/Java VM 能於 GC 過程進行搬移與壓縮（compact collection）。理論上，這讓受管環境有能力在回收時重整記憶體，將存活物件集中並釋放出大塊連續空間，從系統層面解決碎片。然而，理論可行與實作細節之間仍有落差，需要透過測試來驗證目前 .NET CLR 的實際表現。

實驗設計：大塊配置、交錯釋放與再配置驗證

以 .NET 2.0（x86）在 Vista x86 上測試：先連續配置 64MB byte 陣列至 OOM，然後釋放其中一半（形成碎片），再嘗試配置 72MB 陣列，觀察能否成功。此設計可直接測試「回收後是否出現足夠的大塊連續空間」。程式記錄配置數、釋放情況與最終可配置總量，並提供設定檔以控制 GC 模式（gcConcurrent/gcServer）。

初始結果與強制 GC：預設與手動 Collect 的侷限

在預設設定下，釋放空間後仍無法取得足夠的大塊連續空間，顯示碎片未被有效合併；手動呼叫 GC.Collect(GC.MaxGeneration) 的改善也有限，代表僅進行了回收，但未充分觸發搬移與壓縮，或壓縮範圍不足以滿足 72MB 的新配置需求。此結果說明「僅依賴世代回收或同步強制回收」不一定能解決碎片。

gcConcurrent 測試：並行 GC 對碎片沒有實質幫助

考量並行 GC 可能造成觀察時機與回收進度錯位，嘗試關閉 gcConcurrent 以排除干擾。實測顯示關閉後依然無法有效回收出大塊連續空間，顯示並行與否對「是否進行壓縮」不是關鍵因素。碎片問題的核心仍在是否進行搬移與 compact collection。

gcServer 測試：壓縮回收生效，碎片影響消失

啟用 gcServer 後，情況顯著改善：釋放的空間能被有效「合併」回來，能成功配置更大區塊（72MB）的陣列，表現符合預期的 compact collection 行為。雖然官方文件與多數文章對 server GC 的差異描述多著重吞吐與伺服器情境，未明說其壓縮策略；但本實測結果清楚顯示在 server GC 模式下 CLR 會進行足以消除碎片影響的壓縮與搬移。

結語與程式碼：現代平台的解答與實務建議

結論是：在移除指標、僅保留參考的受管語言與 CLR 下，碎片問題能被系統用 compact collection 從根本解決；實務上若應用會頻繁配置/釋放大區塊、或需長期穩定的大塊連續空間，建議評估啟用 gcServer。作者提供完整測試程式與設定檔，鼓勵在不同平台驗證行為差異，並指出這次實驗最大的收穫是理解到 gcServer 在此類情境下的關鍵效果。

資訊整理

知識架構圖

1. 前置知識：
   • 作業系統記憶體管理基礎：虛擬記憶體、位址空間、配置與釋放
   • 記憶體碎裂概念：外部碎裂、連續配置需求
   • .NET/Java 記憶體模型：Stack vs Heap、Reference 與 Pointer 差異
   • .NET GC 基本觀念：代數(Generations)、停頓(Stop-the-world)、LOH(大物件堆)
2. 核心概念：
   • Pointer vs Reference：取消可見的指標讓 CLR/VM 可以在 GC 時搬移物件與重新定址
   • Compact Collection：回收同時壓縮存活物件，減少外部碎裂
   • .NET GC 模式：Workstation GC、Server GC、Concurrent/Background GC
   • 實證方法：以大尺寸陣列配置/釋放/再配置驗證碎裂與壓縮效果
   • 設定觸發點：透過 app.config 啟用 gcServer 對行為的關鍵影響
3. 技術依賴：
   • GC 能否壓縮取決於：語言不暴露原生指標 + 執行時支援搬移/壓縮
   • .NET CLR 設定：runtime 配置 gcServer/gcConcurrent 影響回收策略與壓縮時機
   • 測試行為依賴平台：.NET 版本、x86/x64、OS、LOH 策略
   • 手動觸發 GC（GC.Collect）僅影響時機，不保證壓縮；模式設定才影響策略
4. 應用場景：
   • 需要大量/大區塊連續配置的服務（影像處理、快取、序列化緩衝區）
   • 長時間運行的伺服器應用，需降低記憶體碎裂造成的 OOM/效能退化
   • 需驗證/診斷 GC 行為、碎裂與配置失敗的開發與維運情境
   • 從 C/C++ 移植到 .NET/Java 時處理原有碎裂風險與策略轉換

學習路徑建議

1. 入門者路徑：
   • 了解 Heap/Stack 與外部碎裂的基本概念
   • 認識 .NET GC 代數與停頓行為、LOH 是什麼
   • 用小範例觀察配置/釋放與 GC.Collect 的效果差異
2. 進階者路徑：
   • 比較 Workstation GC 與 Server GC、gcConcurrent 的差異與適用情境
   • 研究 Compact/Moving GC 的原理與限制（特別是 LOH 壓縮策略）
   • 以大量/大物件配置範例做基準測試，觀察不同設定下的碎裂與成功率
3. 實戰路徑：
   • 針對服務型應用啟用 Server GC，評估延遲與吞吐量與記憶體占用
   • 以效能/診斷工具（PerfView、EventPipe、dotnet-counters）觀察 GC 事件
   • 設計記憶體配置策略（池化、分塊、避免過大連續配置）並量測回歸

關鍵要點清單

• Pointer vs Reference：移除可見指標使執行時能在 GC 中搬移/壓縮物件，系統層面可解碎裂（優先級: 高）
• Compact Collection：GC 回收同時壓縮存活物件以回收連續大區塊，對抗外部碎裂（優先級: 高）
• Workstation vs Server GC：實測顯示啟用 Server GC 才得到預期的壓縮效果與大區塊再配置成功（優先級: 高）
• gcConcurrent 設定：控制 GC 是否在背景/獨立執行緒執行，影響時機非策略，對壓縮幫助有限（優先級: 中）
• GC.Collect(GC.MaxGeneration)：只影響回收時機，不保證進行壓縮與消除碎裂（優先級: 中）
• 大物件配置測試法：用 64MB 配置、間隔釋放、再配置 72MB 檢驗碎裂與壓縮成效（優先級: 高）
• LOH 行為：大物件(>~85KB)進入 LOH，壓縮策略依 .NET 版本/設定而異，易導致碎裂（優先級: 高）
• 平台差異：x86/x64、.NET 版本、OS 版本會影響最大可用記憶體與 GC 行為（優先級: 中）
• IDisposable/世代知識侷限：僅理解代數與釋放介面不足以處理碎裂，需要策略層面的壓縮（優先級: 中）
• 配置模式對 OOM 的影響：碎裂下連續大區塊配置易失敗，即便總可用容量足夠（優先級: 高）
• 設定檔開關：runtime 下 gcServer/gcConcurrent 設定是變更 GC 策略/時機的入口（優先級: 高）
• 原生實作不可見：CLR 內部 GC/壓縮多在 native code，僅能透過設定與實測驗證（優先級: 中）
• 移植觀點：由 C/C++ 轉 .NET/Java 可利用壓縮式 GC 緩解碎裂，但需避免曝露指標語義（優先級: 中）
• 實務緩解策略：若無法依賴壓縮，採用池化、固定大小分塊、減少巨大連續配置（優先級: 高）
• 度量先行：以基準測試與診斷工具觀察 GC 事件、Fragmentation 指標再決定策略（優先級: 高）