C# 銳利體驗 (五) (5)：解構函式與垃圾收集進階

解構函式限制與替代方案

C# 編譯器不允許使用者自行重載或呼叫 Finalize 方法——編譯器徹底屏蔽父類別 Finalize 方法（因 C# 單根繼承，System.Object 為所有類別祖先，自然每個類別都有 Finalize），彷彿此方法不存在。以下代碼錯誤：

class MyClass
{
    override protected void Finalize() {} // 錯誤
    public void MyMethod() { this.Finalize(); } // 錯誤
}

但以下代碼正確：

class MyClass
{
    public void Finalize() 
    { Console.WriteLine("My Class Destructor"); }
}
public class Test
{
    public static void Main()
    {
        MyClass obj = new MyClass();
        obj.Finalize(); // 呼叫的是自訂 Finalize，非 Object.Finalize
    }
}

此時 Finalize 已脫離「終結操作」語義，成為一般方法，但也屏蔽了父類別 System.Object.Finalize，需格外小心！

終結操作限制與效能成本

• 實作解構函式（終結器）後，執行時將物件參考加入「終結物件參考佇列」。
• 垃圾收集時，若物件無參考但在終結佇列中，不立即收集，標記為需終結。
• 垃圾收集完成後，終結執行緒喚醒執行終結操作，再從佇列移除。
• 下一次垃圾收集才真正回收記憶體資源。
• 終結操作導致垃圾收集執行兩次，帶來額外系統開銷。
• 透過執行緒機制實現，存在執行緒安全問題。.NET 不保證終結執行順序（物件 A 參考 B，兩者皆有終結，A 執行時 B 參考可能已失效）。
• 不允許使用者直接呼叫 Finalize()。迫切需求可實作 IDisposable 提供公共 Dispose() 方法。
• 提供 Dispose() 後，仍需提供 Finalize（虛擬解構函式），因 Dispose() 不保證被呼叫。.NET 不建議實作終結操作，除非有非受控資料（資料庫連線、檔案開啟等）需嚴格釋放。

手動控制垃圾收集

• 大規模物件集合操作後，確信不再使用，可呼叫 System.GC.Collect() 強制立即回收。頻繁呼叫顯著降低效能。
• 物件已在終結佇列，但程式中已執行終結操作（呼叫 Dispose()），可呼叫 System.GC.SuppressFinalize() 從佇列移除參考，忽略終結操作。終結操作系統負擔極重。

深入了解 .NET 自動垃圾收集後，便能領會 C# 解構函式為何繞大彎實現編程需求，才能遊刃有餘處理記憶體與非記憶體資源回收——這正是解構本原！