.NET 垃圾回收器行為深度驗證：Debug/Release 差異、JIT 優化與根引用掃描實證

本文源於論壇一個關於 GC.Collect() 不立即回收局部變量對象的疑問。作者通過對比 Debug/Release 模式下 IL 指令、JIT 編譯後的機器碼、Windbg 追蹤 GC 根掃描過程，實證驗證了 .NET GC 「從根引用掃描可達對象」的核心理論，並揭示 JIT 優化 (如寄存器分配、局部變量槽復用) 對對象生命週期的實際影響。

現象復現

static tc gto; // 靜態根引用
public class tc { public int a = 99; ~tc() { a = -1; gto = this; } }

private void button1_Click(...) {
    tc to = new tc();
    GC.Collect(); GC.WaitForPendingFinalizers();
    // breakpoint: to 是否已被終結?
}

觀察：Debug 下首次點擊析構函數不執行，第二次才執行；Release 下首次即執行。原因在於 JIT 對局部變量槽的不同處理。

IL 層面差異

機器碼 (JIT) 實證

• Release：JIT_NewFast 返回引用在 EAX，隨即 GCInterface::CollectGeneration 內部覆蓋 EAX，對象無任何根引用 → 被回收，析構函數執行。
• Debug：引用存入棧槽 [ebp-0Ch]，GC 掃描棧帧發現根 → 對象存活。
• 驗證實驗：在 Release 代碼末尾加 to.ToString()，JIT 為保留調用將引用存入 ESI (被調用者保存寄存器)，GC 掃描到寄存器根 → 對象存活，行為與 Debug 一致。

核心結論

1. .NET GC **嚴格遵循根引用掃描**：靜態字段、線程棧局部變量槽、CPU 寄存器、GC Handle 等構成根集合。
2. JIT 優化會消除「顯而易見」的局部變量引用 (Release pop)，導致對象比預期更早可回收。
3. Debug 模式為調試體驗人為延長局部變量壽命 (保留槽、禁用優化)，**不可作為 GC 行為基準**。
4. Visual Studio 調試器會注入隱藏代碼保持對象可檢查，進一步干擾 GC 時機。
5. 風靈靈驗證需：Release 編譯 + 無調試器附加 + 查看 JIT 機器碼 (Windbg/SOS)。

實踐啟示

• 不要依賴析構函數 (~Finalize()) 釋放關鍵資源，**請實現 IDisposable 並顯式 using/Dispose()**。
• 理解 GC.KeepAlive(obj) 可防止 JIT 過早回收正在使用的對象 (如 P/Invoke 併發場景)。
• 內存診斷工具：dotnet-gcdump、PerfView、Visual Studio 內存分析器，而非斷點觀察。