内存泄漏在.NET中主因是对象被意外长期引用。常见情况包括事件未取消订阅、静态集合持续增长、非托管资源未释放及Timer持有引用。诊断可依赖Visual Studio内存分析器、dotMemory、PerfView等工具，通过快照对比与分配追踪定位问题。解决措施涵盖使用using语句释放资源、采用弱事件模式、合理管理缓存生命周期，并避免错误的服务注入。定期压测与监控能有效预防问题，确保应用稳定性。
.NET 中的内存管理由垃圾回收器（GC）自动处理，大多数情况下开发者无需手动释放内存。但即便如此，内存泄漏仍可能发生，尤其在长期运行的应用中。理解 .NET 的内存机制、识别泄漏迹象并使用工具分析问题，是保障应用稳定性的关键。
内存泄漏是如何在 .NET 中发生的？
虽然 .NET 有 GC，但“泄漏”通常指对象被意外地长时间持有引用，导致无法被回收。常见原因包括：
- 事件订阅未取消：对象 A 订阅了对象 B 的事件，但未在适当时候取消订阅，导致 B 持有 A 的引用，A 无法释放。
- 静态集合缓存增长失控：静态 Dictionary 或 List 不断添加对象却不清除，积累大量存活对象。
- 未释放非托管资源：如文件句柄、数据库连接等，需实现 IDisposable 并正确调用 Dispose()。
- Timer 或后台任务持有对象引用：尤其是使用 System.Threading.Timer 时未妥善控制生命周期。
如何诊断内存问题？
发现内存持续增长、GC 回收效果差或频繁发生第2代回收时，应怀疑存在泄漏。可借助以下工具：
- Visual Studio 内存分析器：调试时拍摄多个堆快照（Take Snapshot），比较对象数量变化，查看哪些对象未被释放。
- dotMemory / dotTrace（JetBrains）：专业性能工具，支持实时监控、对象分配追踪和反向引用查找。
- PerfView：微软免费工具，适合生产环境采样，分析内存分配和 GC 行为。
- Application Insights + 内存遥测：结合日志与性能指标，远程监控内存趋势。
解决内存泄漏的实践建议
定位问题后，采取针对性措施修复：
- 检查所有事件注册点，确保在对象销毁前取消订阅，或使用弱事件模式（Weak Event Pattern）。
- 避免将短期对象存入静态集合；若必须缓存，使用 WeakReference 或 MemoryCache 设置过期策略。
- 对实现了 IDisposable 的对象，始终使用 using 语句或 try/finally 确保释放。
- 在依赖注入场景中，注意服务生命周期匹配，避免将 Scoped 或 Transient 服务注入到 Singleton 中造成意外交联。
- 定期进行压力测试和内存快照对比，形成基线数据以便早期发现问题。
基本上就这些。.NET 的内存管理虽自动化程度高，但良好的编码习惯和主动监控仍是避免泄漏的核心。掌握工具使用和常见陷阱，能显著提升应用的健壮性。
