在.NET应用的运维生涯中，“内存泄漏”或“内存居高不下”是一个令人头疼却又无法回避的经典问题。它不像代码异常那样会立即崩溃，而是像一场“慢病”，悄无声息地吞噬着服务器资源，最终可能导致性能骤降或频繁重启。本文将记录一次完整的内存问题排查之旅，并分享从中得到的启示。

一、 问题浮现：生产环境的警报

一个平静的下午，监控系统突然发出警报：某核心业务应用所在服务器的内存使用率已持续超过90%，并多次触发GC。应用虽未完全宕机，但响应速度明显变慢，情况危急。

初步信息：

• 应用类型：  ASP.NET Core 5.0 Web API

• 部署方式： Docker容器，运行在K8s集群

• 症状： 内存使用率在应用启动后缓慢但稳定上升，直至高位震荡，频繁Full GC但效果不佳。

二、 排查之路：从猜测到实证

面对问题，切忌盲目猜测。我们建立了一套清晰的排查流程。

步骤一：确认问题与收集数据

首先，我们在测试环境尝试复现，但未成功。于是转向生产环境，在保证安全的前提下进行数据采集。

1. 获取内存转储（Dump File）：

   • 工具：  dotnet-dump (CLI工具)

   • 命令：  dotnet-dump collect -p <pid> — 这是对线上服务影响最小的方式，几乎无侵入性。

   • 我们分别在内存占用70%和90%时各抓取了一个dump文件，以便对比分析。

步骤二：初探dump文件

使用强大的  JetBrains dotMemory 和  WinDbg 对dump文件进行分析。

1. 概览（Overview）：

   • 打开dotMemory，加载dump文件。首先关注的是 内存分配（Allocations）和 保留内存（Retained Memory）的大小。

   • 发现 Gen 2 Heap（二代堆）和 LOH（大对象堆）的体积异常庞大，且充满了“幸存”下来的对象。这表明有很多对象逃脱了GC的清理，长期存活。

2. 寻找可疑对象（Biggest Objects）：

   • 使用 Object Set功能，按保留大小（Retained Size）排序，快速定位到几个“嫌疑犯”。

   • 排在第一位的是一组巨大的 byte[]数组，其保留内存高达数百MB。第二位的是一大批某个特定的自定义业务模型对象 BusinessModel。

步骤三：深挖根源（Root Cause Analysis）

找到大对象只是第一步，关键是要找到是谁引用了它们，导致GC无法回收。

1. 分析 byte[]数组：

   • 查看 byte[]的引用链（Reference Tree）。发现它们被静态的（ static）内存缓存 IMemoryCache所持有。

   • 问题点： 代码中为了“优化”性能，将大量数据缓存到了内存中，并且设置了很长的过期时间（SlidingExpiration），但缓存键的设计不合理，导致缓存条目无限增长，从未被淘汰。

2. 分析 BusinessModel对象：

   • 查看 BusinessModel的引用链。发现它们被一系列的事件处理器（Event Handlers）所引用。

   • 问题点： 这是一个典型的事件订阅未取消导致的内存泄漏。某个服务在初始化时订阅了全局静态事件，但该服务的生命周期是 Scoped（每次请求都会创建），而事件发布者是单例（ Singleton）。这导致每次请求创建的服务实例在请求结束后，由于仍被全局事件持有而无法被GC回收，其内部引用的所有 BusinessModel对象也随之泄漏。

三、 解决方案：对症下药

找到了根本原因，修复就变得清晰明了。

1. 修复缓存问题：

   • 策略调整： 重新评估缓存策略，对缓存数据进行分类。对于超大数据集，改用绝对过期（AbsoluteExpiration）而非滑动过期，或者考虑使用分布式缓存（如Redis）来分担内存压力。

   • 代码修改： 引入缓存键淘汰策略，定期清理或使用LRU（最近最少使用）策略的自定义缓存实现。

   csharp

   // 原代码（问题代码）_memoryCache.Set(cacheKey, hugeData, new MemoryCacheEntryOptions{
       SlidingExpiration = TimeSpan.FromHours(2) // 可能导致无限期存活});// 修改后_memoryCache.Set(cacheKey, hugeData, new MemoryCacheEntryOptions{https://zq.zhaopin.com/moment/71183718
       AbsoluteExpiration = DateTimeOffset.Now.AddMinutes(30) // 明确绝对过期时间});

2. 修复事件泄漏问题：

   • 生命周期管理： 确保订阅者的生命周期不短于发布者。如果订阅者是短生命周期的，必须在适当的时候（如 Dispose）取消订阅。

   • 代码修改： 让 Scoped服务实现 IDisposable接口，在 Dispose方法中取消事件订阅。

   csharp

   public class LeakyService : IDisposable{
       public LeakyService()https://zq.zhaopin.com/moment/71183738
       {
           GlobalStaticEvent.SomeEvent += HandleEvent; // 错误的订阅
       }
       private void HandleEvent(object sender, EventArgs e)
       {
           // ... 处理逻辑
       }https://zq.zhaopin.com/moment/71183757
       public void Dispose()
       {
           // 修复：在Dispose中取消订阅
           GlobalStaticEvent.SomeEvent -= HandleEvent;
       }}https://zq.zhaopin.com/moment/71183762

四、 启示与最佳实践

这次排查给我们带来了宝贵的经验，总结为以下几点：

1. 工具链是王： 熟练掌握 dotnet-dump、 dotMemory、 WinDbg、 PerfView等工具。它们是诊断.NET内存问题的“CT机”，没有它们，排查工作将是盲人摸象。

2. 理解GC与对象生命周期： 深刻理解.NET的垃圾回收机制，尤其是代际（Generations）和根（Roots）的概念。明确哪些引用会导致对象长期存活（如静态字段、事件、线程静态变量等）。

3. 谨慎使用静态成员和事件： 静态成员和事件是内存泄漏的重灾区。在使用它们时，必须像对待“危险品”一样，时刻思考其生命周期和谁该负责清理。

4. 关注依赖注入（DI）生命周期： 在 ASP.NET Core中，清晰理解 Singleton、 Scoped、 Transient服务的区别。避免将 Scoped服务注入到 Singleton中，或在 Singleton中持有 Scoped服务的数据，这同样会导致泄漏。

5. 监控与预警前置： 建立完善的应用性能监控（APM）体系，不仅要监控CPU和内存总量，更要监控.NET特有的指标，如：

   • GC Gen 0/1/2 Collections

   • Heap Size /  LOH Size

   • Exception Rate

   • 使用 EventCounter或 Meter在应用中暴露自定义指标（如缓存项数量）。

6. 代码审查与“健康检查”： 将常见的内存陷阱（如未取消的事件订阅、不合理的缓存）纳入代码审查清单。定期对应用进行“内存健康”检查，而不是等到出现问题才行动。

结论

内存问题的排查是一场需要耐心、技术和经验的侦探游戏。每一次成功的解决，不仅是修复了一个Bug，更是对.NET运行时理解的一次深化。它提醒我们，在追求功能与性能的同时，必须对资源管理保持敬畏之心。建立起防患于未然的意识和工具链，方能在复杂的企业级应用中保持长治久安。