在C#开发的世界里，内存泄漏犹如隐藏在暗处的“幽灵”，悄无声息地侵蚀着系统的性能。对于百万级别的大型系统而言，哪怕是一个小小的内存泄漏，都可能引发连锁反应，导致系统性能急剧下降，甚至陷入瘫痪。今天，让我们一同走进一场惊心动魄的C#内存泄漏排查实战，见证如何凭借精准的技术手段，用短短10行代码让一个濒临崩溃的百万级系统重获新生。
一、背景与问题浮现
我们所面对的是一个支撑着海量业务的大型分布式系统，基于C#语言开发，运行在Windows Server环境下。在系统上线并稳定运行一段时间后，运维团队反馈系统的内存占用持续攀升，且没有下降的趋势。随着时间推移，系统响应变得越来越迟缓，关键业务接口的调用延迟从原本的几十毫秒飙升至数秒，严重影响了用户体验，业务部门也不断收到客户投诉。显然，系统陷入了严重的性能危机，而内存泄漏成为了首要怀疑对象。
二、初步诊断：借助性能监控工具
（一）任务管理器的初步观察
首先，我们通过Windows系统自带的任务管理器对系统进行初步观察。发现目标进程的内存占用不断增长，且在业务高峰期增长速度尤为明显。然而，任务管理器只能提供一个宏观的内存使用概况，无法深入分析内存泄漏的具体原因。
（二）启用Performance Monitor
为了获取更详细的性能数据，我们启用了Windows Performance Monitor（性能监视器）。通过添加与.NET CLR Memory相关的计数器，如“# of Pinned Objects”（固定对象数量）、“% Time in GC”（垃圾回收占用时间百分比）等，我们发现垃圾回收的频率越来越高，但内存占用却没有得到有效释放，“# of Pinned Objects”数量也在持续增加，这进一步证实了内存泄漏的存在。但Performance Monitor依旧无法定位到具体是哪些对象导致了内存泄漏。
三、深入排查：Windbg登场
（一）环境准备
Windbg是一款强大的调试工具，能够深入分析进程的内存状态。我们首先确保系统安装了正确版本的Windbg，并下载了对应的.NET调试符号文件（.pdb），这些符号文件对于准确分析代码至关重要。
（二）附加到目标进程
打开Windbg，通过“File” -> “Attach to a Process”选项，选择目标进程进行附加。附加成功后，我们使用以下命令获取进程的基本信息：
!dumpheap -stat该命令会列出堆上所有对象类型及其数量和占用内存大小。通过分析输出结果，我们发现某个自定义类型“LargeDataObject”的实例数量异常庞大，占用了大量内存。但这仅仅是一个初步线索，还需要进一步深入分析这些对象的引用关系。
（三）分析对象引用链
为了确定哪些对象持有对“LargeDataObject”的引用，从而导致其无法被垃圾回收，我们使用以下命令：
!gcroot -all <object address>这里的<object address>是通过前面的!dumpheap -stat命令获取的“LargeDataObject”实例的地址。通过该命令，我们发现这些“LargeDataObject”实例被一个静态集合类“DataCache”所持有。在代码中，“DataCache”被设计用于缓存一些常用数据，但由于实现上的缺陷，导致缓存的对象无法被及时清理，从而引发了内存泄漏。
四、辅助分析：dotMemory助力
虽然通过Windbg我们已经大致定位到了问题所在，但为了更直观地了解内存使用情况，我们引入了JetBrains dotMemory这款强大的内存分析工具。
（一）dotMemory的安装与使用
下载并安装dotMemory后，我们在调试模式下启动目标应用程序，并在dotMemory中进行附加。dotMemory会自动开始采集内存数据，并以直观的可视化界面展示内存使用情况。
（二）内存快照分析
在系统运行一段时间后，我们在dotMemory中创建一个内存快照。通过分析快照，我们清晰地看到“DataCache”集合类占用了大量内存，且其中的“LargeDataObject”实例数量与Windbg分析结果一致。dotMemory还提供了详细的对象引用关系图，进一步验证了我们在Windbg中得出的结论，即“DataCache”对“LargeDataObject”的强引用导致了内存泄漏。
五、问题修复：10行代码扭转乾坤
经过深入分析，我们确定了问题的根源在于“DataCache”类的缓存策略存在缺陷。在原本的代码中，数据一旦被添加到缓存中，就不会被主动清理，除非程序重启。为了解决这个问题，我们对“DataCache”类进行了如下修改：
public class DataCache
{
private static Dictionary<string, LargeDataObject> cache = new Dictionary<string, LargeDataObject>();
private static readonly TimeSpan cacheDuration = TimeSpan.FromMinutes(30); // 设置缓存时长为30分钟
public static void Add(string key, LargeDataObject value)
{
if (cache.ContainsKey(key))
{
cache[key] = value;
}
else
{
cache.Add(key, value);
}
Task.Run(() => CleanupExpiredCache()); // 启动一个异步任务清理过期缓存
}
private static async void CleanupExpiredCache()
{
await Task.Delay(cacheDuration);
var keysToRemove = cache.Where(kvp => DateTime.Now - kvp.Value.CreationTime > cacheDuration).Select(kvp => kvp.Key).ToList();
foreach (var key in keysToRemove)
{
cache.Remove(key);
}
}
}通过这短短10行代码，我们为缓存添加了过期清理机制，确保不再使用的对象能够及时从缓存中移除，从而解决了内存泄漏问题。
六、修复验证：系统重焕生机
在完成代码修改并重新部署系统后，我们再次通过Performance Monitor和dotMemory对系统进行监控。随着时间推移，我们欣喜地发现系统的内存占用逐渐趋于稳定，垃圾回收频率恢复正常，业务接口的响应时间也大幅缩短，系统重新恢复了高效运行。这场与内存泄漏的战斗，终于以我们的胜利告终。
在C#开发中，内存泄漏是一个不容忽视的问题。通过合理运用Windbg、dotMemory等工具，结合严谨的分析思路，我们能够准确地定位并解决内存泄漏问题，让系统重获新生。希望本次排查实录能够为广大开发者在面对类似问题时提供有益的参考和借鉴，在编程的道路上少走弯路。
