第三章：内存泄漏的常见“案发现场”

你好，欢迎来到第三章。前两章我们打下了理论基础：第一章明确了"内存泄漏"是意外引用导致GC无法回收；第二章深入了GC的底层机制，知道了根（Roots）、代（Generations）和弱引用（WeakReference）。

现在，是时候进入真正的"犯罪现场"了。这一章，我将为你系统梳理C#和WPF开发中最容易引发内存泄漏的8大场景。每一个场景，我都会讲清楚"它为什么会导致泄漏"、"泄漏是如何发生的"以及"如何识别它"。

理解了这些，你就具备了"侦探"的眼光，能很快在代码中嗅到危险的味道。

---

场景一：事件订阅与取消（头号元凶）

这是WPF和C#应用中最常见、最致命的内存泄漏来源，没有之一。

为什么它会导致泄漏？

事件基于委托，而委托本质上是方法指针 + 目标对象引用。当你订阅一个事件时：

csharp

source.SomeEvent += this.OnSomeEvent;

事件源（source）内部会持有一个对订阅者（this）的强引用 。如果事件源的生命周期长于订阅者，那么订阅者将永远无法被GC回收，直到事件源本身被回收。

典型案发现场

场景	说明	危险级别
静态事件	静态事件的生命周期与AppDomain相同（通常等于整个进程）。任何订阅了静态事件的对象都会被永久持有。	🔴 极高
全局/单例事件源	如 Application.Current、Dispatcher、SystemEvents 等。它们长期存活，订阅它们的对象容易被"钉死"。	🔴 极高
窗口/控件间的事件订阅	子窗口订阅了主窗口的事件，或反之。子窗口关闭后仍被主窗口引用。	🟠 高
在构造函数中订阅事件	如果对象在创建时订阅了一个长生命事件源的事件，但从未在销毁前取消订阅。	🟠 高
使用Lambda/匿名方法订阅事件	如果Lambda内部捕获了外部变量（尤其是 this），会形成一个隐式的强引用链。	🟡 中高

错误示例

csharp

// 错误：主窗口订阅了静态事件
public partial class MainWindow : Window
{
    public MainWindow()
    {
        InitializeComponent();
        SystemEvents.DisplaySettingsChanged += OnDisplayChanged; // 泄漏！
    }
    
    private void OnDisplayChanged(object sender, EventArgs e)
    {
        // 处理显示变化
    }
}

一旦 MainWindow 关闭，因为它还在 SystemEvents 的订阅列表中，GC无法回收它，内存就泄漏了。

正确做法

原则：谁订阅，谁取消。 在对象销毁前，务必取消所有事件订阅。

csharp

public partial class MainWindow : Window
{
    public MainWindow()
    {
        InitializeComponent();
        SystemEvents.DisplaySettingsChanged += OnDisplayChanged;
    }
    
    // 在窗口关闭时取消订阅
    protected override void OnClosed(EventArgs e)
    {
        SystemEvents.DisplaySettingsChanged -= OnDisplayChanged;
        base.OnClosed(e);
    }
}

---

场景二：静态集合与静态字段

静态字段是GC根（Roots）中最"长命"的一种。它的生命周期与AppDomain相同，通常等于进程的生命周期。

为什么它会导致泄漏？

任何被静态字段（尤其是静态集合）引用的对象，都会被视为根可达，永远不会被GC回收。

典型案发现报

csharp

public static class Cache
{
    // 静态集合，会永久持有所有添加进去的对象
    public static List<MyData> DataList = new List<MyData>();
}

// 某处代码
Cache.DataList.Add(someLargeObject); // 这个对象永远无法被回收

解决方案

• 谨慎使用静态集合：如果必须使用，确保有明确的清理机制。

• 使用弱引用集合 ：例如 ConditionalWeakTable<TKey, TValue>，它是一个特殊的弱引用字典，当键被GC回收时，值也会自动释放。

• 使用 WeakReference：对于需要缓存但允许被回收的对象，使用弱引用。

---

场景三：数据绑定（Binding）与INotifyPropertyChanged

WPF的数据绑定机制虽然强大，但也暗藏陷阱。

为什么它会导致泄漏？

当绑定源对象实现了 INotifyPropertyChanged 时，WPF的绑定引擎会订阅源对象的 PropertyChanged 事件，以监听属性变化。这意味着绑定目标（通常是UI元素）会持有对绑定源的引用。反过来，绑定源也会通过事件机制持有对绑定目标的引用。这会形成一个复杂的引用链。

典型案发现场

场景	说明
ViewModel未正确实现INotifyPropertyChanged	如果 PropertyChanged 事件被某个长生命周期的监听器（如绑定引擎）订阅，而ViewModel本身又引用了UI元素，就会形成循环引用。
在代码中动态创建Binding	如果手动创建的Binding没有正确清理，可能导致绑定源和目标相互引用，无法释放。
绑定到静态属性	静态属性本身就是根，其变化会持久影响所有绑定。

解决方案

• 确保ViewModel正确实现 INotifyPropertyChanged，并正确处理事件订阅。

• 在页面或窗口卸载时，清理绑定 ：可以调用 BindingOperations.ClearAllBindings 来清除绑定。

• 使用弱事件模式（Weak Event Pattern），让绑定引擎使用弱引用而不是强引用。

• 对于简单的单向绑定 ，WPF内部通常会使用弱引用，但双向绑定和 Mode=OneWay 的某些情况下仍需注意。

---

场景四：DispatcherTimer 与线程

DispatcherTimer 在WPF UI线程上触发，但它本身有一个内部强引用，会导致内存泄漏。

为什么它会导致泄漏？

• 如果你创建了一个 DispatcherTimer，并将它的 Tick 事件绑定到一个对象的方法上，但从未停止（Stop）和取消订阅（-=）该事件，那么即使该对象不再需要，也会被定时器持有。

• 任何在后台线程 上运行的 System.Timers.Timer 或 System.Threading.Timer，如果它们的回调捕获了UI对象，也会导致泄漏。

错误示例

csharp

public partial class MyControl : UserControl
{
    private DispatcherTimer _timer;
    
    public MyControl()
    {
        InitializeComponent();
        _timer = new DispatcherTimer();
        _timer.Interval = TimeSpan.FromSeconds(1);
        _timer.Tick += OnTick;
        _timer.Start(); // 定时器长期运行，持有对当前控件的引用
    }
    
    private void OnTick(object sender, EventArgs e)
    {
        // 更新UI
    }
}

当 MyControl 被移除时，因为 _timer 还在运行且持有对它的引用，整个控件无法被回收。

解决方案

• 在控件/窗口卸载时，停止并清理定时器：

csharp

protected override void OnUnloaded(RoutedEventArgs e)
{
    _timer.Stop();
    _timer.Tick -= OnTick;
    _timer = null;
    base.OnUnloaded(e);
}

• 使用弱引用包装回调（如果无法控制定时器的生命周期）。

---

场景五：Lambda表达式与匿名方法捕获

Lambda表达式和匿名方法很便捷，但它们会捕获外部变量，形成闭包（Closure），从而产生隐式引用。

为什么它会导致泄漏？

编译器会将Lambda表达式编译为一个内部类 ，该类包含对捕获变量的字段引用。如果Lambda被存储在一个长期存活的事件或委托中，那么所有被捕获的变量（包括 this）都会被这个内部类引用，从而无法被GC回收。

错误示例

csharp

// 假设这是一个长期存活的事件源
public static class EventSource
{
    public static event EventHandler SomethingHappened;
}

// 某处代码
public void Subscribe()
{
    // Lambda捕获了 this
    EventSource.SomethingHappened += (s, e) => 
    {
        this.DoSomething(); // 隐式强引用 this
    };
}

即使 Subscribe 方法的所在对象不再需要，由于Lambda内部类持有 this 的引用，且被静态事件持有，该对象永远不会被回收。

解决方案

• 尽量使用命名方法而不是Lambda，以便可以取消订阅。

• 如果必须使用Lambda ，确保在适当时机取消订阅（-=）。

• 注意捕获的变量 ，避免捕获 this 或长生命周期的对象。

---

场景六：大型对象堆（LOH）与碎片化

这是GC机制本身导致的一种"间接"泄漏。

什么情况会触发？

• 分配大于85KB的对象会被放入大型对象堆（LOH）。

• LOH默认不会压缩 （直到 .NET Core 3.0 后支持 GCSettings.LargeObjectHeapCompactionMode）。

• 随着时间的推移，LOH上会形成内存碎片 ，导致虽然总内存足够，但无法分配连续的大块内存，最终抛出 OutOfMemoryException。

典型场景

• 加载大图片（BitmapImage）。

• 频繁创建和释放大型字节数组。

• 使用大型字符串。

解决方案

• 避免频繁分配大对象：考虑对象池（Object Pool）或重用对象。

• 主动触发LOH压缩（仅在必要时，因为性能开销大）：

csharp

GCSettings.LargeObjectHeapCompactionMode = GCLargeObjectHeapCompactionMode.CompactOnce;
GC.Collect();

• 使用 ArrayPool<T> 等池化机制，复用数组。

---

场景七：非托管资源与IDisposable

C#的内存管理是托管的，但非托管资源（文件句柄、数据库连接、GDI句柄等）不受GC控制。

为什么会导致泄漏？

如果分配了非托管资源但没有正确释放，这些资源会一直占用，导致操作系统资源耗尽。

错误示例

csharp

// 忘记调用 Dispose
var stream = new FileStream("data.bin", FileMode.Open);
var reader = new StreamReader(stream);
// ... 使用reader，但没有关闭或释放

解决方案

• 始终对实现了 IDisposable 的对象使用 using 语句：

csharp

using (var stream = new FileStream("data.bin", FileMode.Open))
using (var reader = new StreamReader(stream))
{
    // 使用资源
}

• 在自己编写的类中实现 IDisposable ，并在 Dispose 方法中释放所有非托管资源。

• 实现终结器作为后备，但不要依赖它。

---

场景八：XAML中的x:Name与FindName

在WPF中，为控件指定 x:Name 会在XAML命名空间注册表中建立一个引用。

为什么会导致泄漏？

如果动态添加了一个带有 x:Name 的控件，然后从视觉树中移除了它，但没有调用 UnregisterName 方法，该控件仍会保留在XAML命名空间注册表中，成为不可达但被引用的"僵尸"。

解决方案

• 在移除动态控件时，调用 UnregisterName：

csharp

// 动态添加
MyPanel.Children.Add(newButton);
RegisterName("dynamicButton", newButton);

// 动态移除
MyPanel.Children.Remove(newButton);
UnregisterName("dynamicButton");

• 如果不需要在后台通过 FindName 查找控件，尽量避免使用 x:Name。

---

本章总结：快速对照表

场景	核心原因	关键对策
事件订阅	长生命周期事件源持有订阅者引用	在 Dispose/OnClosed 中取消订阅
静态集合/字段	静态引用是永久根	谨慎使用；考虑弱引用集合
数据绑定	绑定引擎的强引用链	清理绑定；实现弱事件模式
DispatcherTimer	定时器持有Tick订阅者	停止并取消订阅
Lambda捕获	闭包中的隐式 this 引用	使用命名方法；注意捕获范围
大型对象堆	LOH碎片化	避免频繁大对象分配；池化
非托管资源	GC不管理非托管资源	使用 using 或实现 IDisposable
x:Name/FindName	XAML命名空间注册表强引用	调用 UnregisterName