做了多年 C# 开发和性能排查，我见过太多项目跑着跑着内存曲线就跟心电图一样往上冲，虚机内存占满，GC 拼命回收却怎么也腾不出空间。很多人第一反应是“C# 不是有垃圾回收吗？怎么还会内存泄漏？”其实 C# 的内存泄漏绝大部分不是内存本身的错，而是对象根本没机会被回收——引用链还在，GC 在可达性分析时只能老老实实把它当成活对象。也就是说，对象表面上已经“死”了，实际却被某个藏在角落的引用握得死死的，这就是 C# 对象最典型的“死亡陷阱”。

这篇文章我会把日常开发和线上故障里遇到最多的几类陷阱拆开讲：事件订阅不解除、静态容器长期持有对象、非托管资源处置不完整、终结器拖慢回收，以及怎么用工具把泄漏对象一层层挖出来。适合正在做 .NET 服务端、WinForms/WPF 客户端、上位机这类常驻进程项目的同学，尤其是系统运行几天后内存就开始发胖，或者 GC 之后内存依然下不来的情况，可以直接对照排查。

1. 先搞懂 C# 对象的“生老病死”：引用决定了对象是否还活着

要理解对象为什么会泄漏，先得知道 C# 里对象什么时候才算“必须活着”。很多人以为对象离开作用域、变量不再被使用就已经死了，实际上 GC 根本不看作用域，它只看一件事：从根节点出发，能不能沿着引用链找到这个对象。

1.1 GC 根、引用链和“不可达”对象

GC 的起点是一组根节点，包括静态字段、线程栈上的局部变量、CPU 寄存器里的对象引用、GC Handle（比如 GCHandle、P/Invoke 传递的对象）。只要从这些根出发能找到某个对象，这个对象就是可达的，GC 就不会回收它。反过来，如果引用链断了，无论这个对象之前占了多少内存，它都会变成垃圾，在合适的时机被回收。

用大白话说：对象不是自己“死”的，是 GC 判定它“和根已经失去联系”才算死。这里有个很关键的推论——只要还有一个根能走到它，哪怕你业务上觉得它早该释放了，GC 也只能把它当成活对象继续保留。这就是绝大多数内存泄漏的根源：对象本身没有做错什么，是外部还挂着一根看不见的引用线。

1.2 托管堆不“泄漏”，泄漏的是引用本身

理清这个概念后，你会发现 C# 的内存泄漏和 C/C++ 的内存泄漏有本质区别。C++ 是真正把内存弄丢了，找不回来；C# 是内存一直在托管堆里躺着，但因为没有引用能到达它，应该被回收却没被回收。实际上托管堆并不会无限制增长，GC 会不断回收不可达对象，真正让人头疼的，是大量可达对象堆积，把老年代堆越撑越大，GC 压力越来越高，最后导致 Full GC 频繁甚至进程崩溃。

所以排查 C# 内存问题，核心任务不是“找哪里没释放”，而是“找谁还持有对象的引用”。这也是为什么很多人用任务管理器看内存占用半天找不出问题——进程内存大不等于泄漏，必须把引用图翻出来，看清是哪条引用链让对象活了下来。

2. 第一大陷阱：事件订阅不解除，Publisher 把 Subscriber 牢牢拽住

2.1 一段看似无害的 += 代码

事件是 C# 对象泄漏的头号元凶，我见过的案例里，十个内存泄漏至少六个和事件有关。事件在语法上很友好，但在对象生命周期上是个典型的“反向引用”：订阅者把方法交给发布者，发布者的事件内部就持有了订阅者的委托，委托又持有了目标对象。也就是说，你执行publisher.Event += subscriber.Handler之后，只要 publisher 还活着，subscriber 就永远活着。

看段极简代码：

public class Publisher { public event Action DataChanged; public void Raise() => DataChanged?.Invoke(); } public class Subscriber { public void OnDataChanged() { } }

然后在某个常驻模块里写：

var publisher = new Publisher(); var subscriber = new Subscriber(); publisher.DataChanged += subscriber.OnDataChanged;

此时如果你把subscriber的本地引用清掉，比如把它从集合里移除，GC 能不能回收它？不能。因为publisher.DataChanged这个委托链里，还挂着subscriber.OnDataChanged，委托的Target就指向 subscriber。只要 publisher 没死，subscriber 就永远活在引用链上。

2.2 静态事件是超级加强版陷阱

如果 publisher 是普通对象，它自己可能被回收，这会让事情变得没那么严重。但现实里最常见的问题是 publisher 本身就是静态的，或者挂在生命周期很长的对象上，比如某个静态服务、WinForms 的 Application 对象、框架里的 IContainer 等。一旦挂上静态事件，订阅者相当于被静态根永久引用，怎么等 GC 都没用。

我处理过一个上位机项目，界面关闭一个子窗口后内存只增不减。查了半天，发现子窗口在构造函数里订阅了全局设备服务的一个事件，关窗时只调了Close()，根本没解除订阅。窗口对象被关掉了，但它还被全局服务事件拽着，所有 UI 控件、绑定数据全都留在内存里。而且这种泄漏是“每次打开再关闭都会加一分”，窗口越开关越卡。

解决办法就一句话：谁订阅谁解除，成对出现。比如：

publisher.DataChanged += subscriber.OnDataChanged; // 当 subscriber 生命周期结束时 publisher.DataChanged -= subscriber.OnDataChanged;

2.3 事件泄漏的深层规律与弱事件模式

从引用本质上理解，+=和-=必须对称写。但实际项目里，订阅往往在构造函数或者 Initialize 方法里，解除却分散在各个关闭逻辑中，很容易漏。我常用的几个规避手段：

• 把订阅和取消订阅封装到一对方法里，比如Subscribe()和Unsubscribe()，并且用生命周期状态字段防止重复调用。
• 明确对象的 owner 关系，由拥有方负责解绑，不要让被订阅者自己想办法。
• 如果确实无法保证解除，考虑用弱事件模式，比如WeakEventManager（WPF 自带），或者自己用WeakReference封装委托。弱事件模式是让 publisher 只持有一个弱引用，不阻止订阅者被回收，代价是事件分发时会多一次弱引用解析。

另外别忘了匿名方法和 lambda 闭包：publisher.DataChanged += (s, e) => subscriber.Handle();这种写法同样会把 subscriber 捕获进闭包对象，再由委托引用，泄漏路径更隐蔽。我建议在事件订阅处写注释，说明对应解除位置，团队规范里也把“事件订阅必须成对”列为硬性要求。

3. 第二大陷阱：静态容器和全局缓存，把临时对象当长期居民

3.1 ConcurrentDictionary、List、Cache 里的对象为什么回收不掉

静态字段本身就是 GC 根，静态集合里只要还放着对象的引用，这个对象就永远可达。这种设计本身没错，缓存、注册表、配置中心都这么用，但问题出在很多人把“临时需要”的数据顺手塞进了静态容器，却忘了移除。

举个例子，有个物联网服务端程序，每个设备连接进来就创建一个会话对象，然后塞进静态 ConcurrentDictionary：

public static class SessionManager { public static readonly ConcurrentDictionary<string, Session> Sessions = new(); }

设备断开时，如果只处理了 TCP 断开事件，却忘了从字典里把 Session 移除，那么 Session 对象、关联的 Socket、缓冲区、业务对象，全都会留在字典里。短时间看不出问题，设备量大了以后，内存稳步上升，最终撑爆。这个案例里对象本身没有错，是静态根太“热情”，把所有人都留在家里不让走。

还有一个常见场景是“带 key 的缓存”永远只增不减，比如存放计算结果、导入文件解析后的中间对象、OCR 识别结果等。如果不设过期策略，没有容量上限，那这个缓存本身就是个慢速泄漏。区分一个数据结构算不算内存泄漏，就看他有没有清理路径：只进不出，必然出问题。

3.2 用弱引用容器把“非必需持有”降级为“可用即取”

如果某个数据结构只是“缓存性质”，允许对象在内存紧张时被 GC 回收，那就应该用弱引用容器，而不是强引用的 List 或 Dictionary。.NET 里有现成的类型：

• WeakReference和WeakReference<T>：对单个对象做弱引用；
• ConditionalWeakTable<TKey, TValue>：键用完时，键值一起被回收，常用于给对象附加额外数据，比如给已存在的实例扩展属性，而不改变原对象生命周期。

用 ConditionalWeakTable 的例子是这样的：

public static class ExtensionCache { private static readonly ConditionalWeakTable<object, Metadata> Cache = new(); public static Metadata GetMetadata(object target) { return Cache.GetOrCreateValue(target); } }

当 target 对象本身不再被外部引用时，它在 ConditionalWeakTable 里的条目也会跟着失效，不会造成对象累积。这个特性对“给第三方对象附加状态”这类场景非常合适。但要注意，如果缓存里的值对象又反过来强引用了 key 对象，那就会形成引用循环，可能导致 key 被拖住，实际用的时候还是得小心值对象的成员。

说到底，凡是静态容器，都要养成三个习惯：明确谁是所有者；明确对象何时从容器中移除；给容器设置容量上限或定期清理策略。做不到这三点，就别吐槽 GC 不给力。

4. 第三大陷阱：非托管资源没有真正释放，Dispose 形同虚设

4.1 大对象都是直接内存，你没 Dispose 它就一直占着

第二类高发泄漏是“托管对象包着非托管资源”。典型如FileStream、MemoryStream、Bitmap、Image、Socket、数据库连接、CancellationTokenSource等。这些对象内部可能持有 Windows 句柄、原生内存块、Socket 句柄等非托管资源。GC 能回收对象本身，但没法自动决定何时回收它包着的非托管资源——所以 .NET 提供了IDisposable，让你显式释放。

在实际代码里，最常见的问题是：用了using包着大部分资源，但有一些路径没走到。比如下面这种：

public void ProcessImage(string path) { var image = new Bitmap(path); // 中间某行抛异常了 image.Save("out.png"); image.Dispose(); // 没执行到 }

这里如果用using (var image = new Bitmap(path))就能兜住异常场景。看似只是语法差异，实际上一个是不保证释放，一个是必定释放。还有一类是“字段型资源”，构造函数里创建了Stream或CancellationTokenSource，类的生命周期又长，如果只实现了 IDisposable 却忘了在Dispose里释放这些字段，那资源一样会拖住。

4.2 HttpClient 和 Image 的经典误用

HttpClient是另一个名场面。很多人每次请求都new HttpClient()，用完丢给 GC。这有两个问题：一是端口和连接可能被内核占用，连接来不及关闭；二是频繁创建会触发大量 TIME_WAIT 状态的连接，最终导致 socket 耗尽。正确方式是把它作为单例长期复用。所以张口闭口“用完就释放”在某些场景并不准确，核心是搞清楚资源到底是短生命周期还是长生命周期。

Bitmap和Image在 WinForms/WPF 中也很特别。Bitmap 内部引用的是 GDI+ 句柄，如果不 Dispose，句柄数量会一路飙升。更麻烦的是，很多控件本身的Image属性会持有图片引用，你只关掉窗体而不释放图片，图片对象依然被窗体内部的逻辑引用，甚至被静态的 ImageList 引用。排查时看到“MemoryStream 数量异常多”，多半就是某些异步读取路径没把流关掉。

4.3 IDisposable 模式的正确姿势

一个完整且正确的 IDisposable 实现，不只是有个 Dispose 方法而已。我建议按这个模式写，尤其是有继承可能性的类：

public class MyResourceHolder : IDisposable { private IntPtr _nativeHandle; private Stream _stream; private bool _disposed; public void Dispose() { Dispose(true); GC.SuppressFinalize(this); } protected virtual void Dispose(bool disposing) { if (_disposed) return; if (disposing) { _stream?.Dispose(); } if (_nativeHandle != IntPtr.Zero) { // 释放原生句柄 _nativeHandle = IntPtr.Zero; } _disposed = true; } ~MyResourceHolder() { Dispose(false); } }

关键点有几个：

• Dispose()里调用GC.SuppressFinalize(this)，避免对象被提前送到终结队列；
• 终结器只释放非托管资源，不碰托管字段，因为终结器阶段托管对象的状态不可靠；
• 所有公共方法开头都检查_disposed，防止对象被释放后继续使用。

如果不知道对象内部是不是有原生资源，最好直接继承 SafeHandle 或者用Microsoft.Win32.SafeHandles，让 SafeHandle 的终结逻辑帮你兜底。很多人觉得写终结器麻烦，其实大多数业务类根本不需要终结器，直接用using+ 手动释放就够了。终结器是双刃剑，用得不好反而会造成下一类问题。

5. 第四大陷阱：终结器让对象“死而不僵”，回收节奏被打乱

5.1 带终结器的对象至少要经过两次 GC 才能被回收

你可能见过一种现象：某类自己实现了析构函数~MyClass()，然后这个类的对象内存占用特别大，即使看起来没有引用，内存就是不降。这不是对象被谁持有，而是终结器改变了 GC 的回收流程。

有终结器的对象被判定为不可达后，不会立刻释放内存。GC 会先把它放到“待终结队列”里，由终结线程调用它的终结器，然后在下一次 GC 时才能回收内存。这意味着：

• 它至少多活了一代（如果它在第0代被判定不可达，会先转入第1代等待终结）；
• 终结线程的调度压力和不确定都会拖慢回收；
• 如果终结器里执行了耗时操作，还会阻塞其他对象的终结流程。

更隐蔽的是“复活”问题。如果终结器里不小心把对象引用又写回静态字段，对象就重新变为可达。虽然 GC 会再次发现并终结它，但这个过程反复出现时，内存和 CPU 都会受影响。

5.2 用 GC.SuppressFinalize 控制终结行为

如果你实现 IDisposable 且手动释放了非托管资源，就必须调用GC.SuppressFinalize(this)，告诉 GC “这个对象不用进终结队列了”。不然一个既支持 using 又带终结器的对象，会在 Dispose 之后仍然被塞进终结队列，白等一次 GC 才释放。

我在实际项目里还见过一种错误：对象声明了终结器，但终结器里什么也没做，只有一段空代码。这类空终结器会让所有对象都多活一轮 GC，纯属自找麻烦。正确取舍是：确定没有非托管资源就别写终结器；有非托管资源尽量用 SafeHandle 封装，让 SafeHandle 的终结器统一处理。

5.3 大对象堆和固定对象的额外说明

除了终结器，还有两个相关因素会让对象“死得慢”。

一是 LOH（大对象堆）。大于 85KB 的对象直接进 LOH，而 LOH 默认不压缩，即使对象被回收了，地址空间也可能留下碎片。频繁创建大数组、大字符串时，LOH 会反复申请和释放，内存碎片堆积，进程内存看着很高。虽然 .NET Core 之后 LOH 也支持压缩，但那是 Full GC 时才做的，平时尽量复用大缓冲池能规避很多问题。

二是固定对象，比如fixed语句、GCHandle.Alloc(obj, GCHandleType.Pinned)，或者 P/Invoke 一层层传递过来的对象。固定的对象不能移动，会阻碍堆压缩，不释放 GCHandle 就等于一直持有一个强引用。最典型的就是做上位机时把 byte[] 固定住传给原生驱动，用完后忘了GCHandle.Free。这种情况用 dotnet-gcdump 看对象列表时，能发现大量已固定的大字节数组。

6. 实战排查：用工具把泄漏引用链挖出来

6.1 从性能计数器和内存快照开始

纸上谈兵再多，不如直接看证据。排查 C# 内存泄漏，我一般的流程是：

先看基础指标，比如 GC 堆大小、Gen0/Gen1/Gen2 回收次数、LOH 大小、进程私有内存。用dotnet-counters可以实时看：

dotnet-counters monitor --process-id <pid> System.Runtime

重点看gc-heap-size和gc-pause-duration。如果 GC 堆持续增长且每次回收后不下落，基本可以确认有对象在被长期持有。

第二步抓内存快照：

dotnet-gcdump collect -p <pid> -o dump.gcdump

然后用 Visual Studio 或 PerfView 打开 gcdump，直接看托管堆里哪些类型数量最多、占空间最大，再双击某个类型查看实例引用图。这个方法对排查托管对象泄漏最直观。

Windows 上也可以用经典的dotnet-dump：

dotnet-dump collect -p <pid> dotnet-dump analyze dump

进入 SOS 调试器后，最常用的几个命令：

!dumpheap -stat !dumpheap -type Subscriber !gcroot <object address>

!gcroot会一路打出从 GC 根到目标对象的引用链，一眼就能看到到底是哪个静态字段、哪个事件委托把对象拖住了。我在一次排查里用这条命令定位到某个ConcurrentDictionary的 value 里还套着一个巨大的缓存结果对象，引用链清清楚楚。

6.2 用弱引用先验证“该回收的对象没回收”

有时候不方便在生产环境上抓 dump，可以用代码快速定位。比如怀疑某个对象生命周期失控，可以临时写段测试代码：

var weak = new WeakReference(obj); obj = null; GC.Collect(); GC.WaitForPendingFinalizers(); GC.Collect(); Console.WriteLine(weak.IsAlive ? "对象仍存活！存在泄漏引用" : "对象已回收");

这种方法特别适合在开发环境验证“到底回收了没有”。如果输出“仍存活”，说明在触发 GC 的时刻还有引用；如果输出“已回收”，则说明问题可能出在其他路径或者对象被缓存了。注意 WeakReference 测试本身也要谨慎：有些对象因为终结器导致弱引用感觉上活得更久；另外 Release 模式下 JIT 的变量生命周期可能不同，测试时要保证变量在 GC.Collect 之前确实不再被使用。

6.3 排查时的几个常见误判

第一，进程内存大不等于托管堆大。原生内存（比如 GC 原生堆、JIT 代码、非托管模块）也会占内存，如果托管堆很小但总内存大，方向就不该对着 C# 对象查，而是查非托管内存分配。

第二，GC 堆增长但对象数量并不多，可能是数组和缓冲池膨胀，比如 List 频繁扩容、数组池被长期借用不归还。这种对象引用链往往非常短，但内存量很大。

第三，抓 dump 的时机很重要。最好在内存已经连续增长一段时间后、还没触发 OOM 之前抓，并且连续抓两份，中间触发一次 GC。如果第一次抓完对象很多，第二次抓之前手动 GC，对象数量明显下降，说明垃圾能正常回收；如果第二次抓还是一样的多，那基本就是泄漏引用链。

7. 避坑清单与常见问题速查

7.1 一张表对照典型泄漏症状

7.2 我每次上线前都会过的检查项

总结这几个“死亡陷阱”，我给自己列了一个很简单的检查单，发布前对着看一遍：

• 实例对象有没有被静态字段或静态事件直接/间接引用；如果有，它有没有对应的解绑入口。
• 所有事件订阅是否有对称的取消订阅代码，lambda 闭包捕获了谁。
• 缓存容器是否有清理机制；弱引用是否真的被弱引用持有。
• 所有 IDisposable 的局部变量是否包在 using 里；字段资源是否在 Dispose 里释放。
• 是否不必要地写了终结器；如果有，是否调用了 GC.SuppressFinalize。
• 常驻进程是否在关键路径上创建大数组或大字符串，是否能用池化替代。

这套检查单看起来简单，每次都能拦下一批问题。尤其事件订阅和静态容器这两个，几乎是我带过的每个项目里必查项。

最后再分享一个小技巧

做内存排查不要只盯着一种工具，dotnet-gcdump看托管堆、dotnet-counters看趋势、dotnet-dump analyze挖引用链，三者配合才能把问题定位清楚。我的习惯是先在代码里搜索所有静态字段和静态事件，把可能持有长生命周期对象的点列出来，再去 dump 里验证；如果 dump 里出现的意外类型和怀疑目标对不上，优先看它被哪个对象引用，一层层往上翻，基本都能找到藏在背后的“根”。

C# 的对象回收机制本身不背锅，真正决定内存死活的是引用设计。把根引用想清楚，把事件和静态容器管好，90% 的“内存泄漏”其实都能在代码层面直接消灭。