平时做技术实践时，很多问题不是概念不会，而是细节没串起来。拿“一文揭秘C#中资源泄漏的三种隐蔽场景排查与解决”来说，它看着像小点，放到项目里常会牵出环境、配置、兼容性和维护成本。下面按实际采用顺序，把思路、关键写法和容易踩坑的地方讲清楚，便于大家直接对照操作。

目录

• 场景 1：异常中断导致 Dispose 永不执行
• 问题代码
• 正确做法
• 场景 2：事件订阅导致的隐形引用链
• 问题代码
• 正确做法
• 场景 3：静态引用和单例模式中的隐形泄漏
• 问题代码
• 正确做法
• 排查技巧：如何发现资源泄漏
• 1. 采用内存分析工具
• 2. 采用 GC.GetTotalMemory() 监控
• 3. 采用 Finalizer 检测
• 总结

实际处理时，最近在做项目代码审查时，发现了一个有意思的现象：大家都知道要用 using 或 Dispose() 来释放资源，但真正遇到资源泄漏时，还是一脸懵。有人问我："刚哥，我都调用 Dispose() 了，为什么内存还在涨？"

说实话，这个问题问得好。因为 Dispose 不释放 结合项目来看，的坑，远比你想象的要深。今天我就从 6 年 .NET 开发的经验出发，给你揭露 3 种最隐蔽、最容易踩的资源泄漏场景。

场景 1：异常中断导致 Dispose 永不执行

在这个场景下，这是最常用的坑。很多人写代码时，脑子里想的是"正常流程"，但忽略了异常这个"幽灵"。

问题代码

public class ResourceLeakDemo
{
    public void BadExample()
    {
        SqlConnection conn = new SqlConnection("Server=localhost;Database=test");
        conn.Open();
        
        // 如果这里抛异常，conn 永远不会被释放
        var result = ExecuteQuery(conn);
        
        conn.Dispose();  // 这行代码可能永远执行不到
    }
    
    private object ExecuteQuery(SqlConnection conn)
    {
        throw new Exception("模拟查询异常");
    }
}

问题分析：

• 若 ExecuteQuery() 抛异常，程序直接跳到 catch 块或调用者
• conn.Dispose() 这一行永远不会执行
• 连接对象留在内存中，等待 GC 回收（但 GC 不一定及时）

正确做法

// 方案 1：using 语句（推荐）
public void GoodExample_Using()
{
    using (SqlConnection conn = new SqlConnection("Server=localhost;Database=test"))
    {
        conn.Open();
        var result = ExecuteQuery(conn);
        // 即使异常，using 也会自动调用 Dispose()
    }
}

// 方案 2：using 声明（C# 8.0+，更简洁）
public void GoodExample_UsingDeclaration()
{
    using SqlConnection conn = new SqlConnection("Server=localhost;Database=test");
    conn.Open();
    var result = ExecuteQuery(conn);
    // 方法结束时自动 Dispose()
}

// 方案 3：try-finally（不推荐，但有时必要）
public void GoodExample_TryFinally()
{
    SqlConnection conn = new SqlConnection("Server=localhost;Database=test");
    try
    {
        conn.Open();
        var result = ExecuteQuery(conn);
    }
    finally
    {
        conn?.Dispose();  // 无论如何都会执行
    }
}

关键点：

• using 语句会在 IL 层面生成 try-finally，保证 Dispose 一定执行
• C# 8.0+ 的 using 声明更简洁，自动在作用域结束时释放
• 永远不要依赖"手动调用 Dispose"，异常会破坏你的计划

场景 2：事件订阅导致的隐形引用链

这个坑特别隐蔽，因为代码看起来完全没问题，但内存就是不释放。

问题代码

public class EventLeakDemo
{
    public class DataService
    {
        public event EventHandler OnDataChanged;
        
        public void NotifyDataChanged()
        {
            OnDataChanged?.Invoke(this, EventArgs.Empty);
        }
    }
    
    public class UIComponent
    {
        private DataService _service;
        
        public UIComponent(DataService service)
        {
            _service = service;
            // 订阅事件，但从不取消订阅
            _service.OnDataChanged += OnServiceDataChanged;
        }
        
        private void OnServiceDataChanged(object sender, EventArgs e)
        {
            Console.WriteLine("数据已更新");
        }
    }
    
    public void LeakyCode()
    {
        var service = new DataService();
        var ui = new UIComponent(service);
        
        // ui 对象即使不再使用，也不会被 GC 回收
        // 因为 service 的 OnDataChanged 事件持有对 ui 的引用
        ui = null;  // 这行代码不会释放 ui
    }
}

问题分析：

• UIComponent 订阅了 DataService 的事件
• 事件处理器 OnServiceDataChanged 是实例方法，隐含持有 this 的引用
• 即使 ui = null，service.OnDataChanged 的委托链中仍然持有对 ui 的引用
• 只要 service 还活着，ui 就永远不会被 GC 回收

正确做法

public class EventLeakFixed
{
    public class DataService : IDisposable
    {
        public event EventHandler OnDataChanged;
        
        public void NotifyDataChanged()
        {
            OnDataChanged?.Invoke(this, EventArgs.Empty);
        }
        
        public void Dispose()
        {
            // 清空所有事件订阅
            OnDataChanged = null;
        }
    }
    
    public class UIComponent : IDisposable
    {
        private DataService _service;
        
        public UIComponent(DataService service)
        {
            _service = service;
            _service.OnDataChanged += OnServiceDataChanged;
        }
        
        private void OnServiceDataChanged(object sender, EventArgs e)
        {
            Console.WriteLine("数据已更新");
        }
        
        public void Dispose()
        {
            // 关键：取消事件订阅
            if (_service != null)
            {
                _service.OnDataChanged -= OnServiceDataChanged;
            }
        }
    }
    
    public void CorrectCode()
    {
        var service = new DataService();
        using (var ui = new UIComponent(service))
        {
            // 使用 ui
        }  // 自动调用 ui.Dispose()，取消事件订阅
        
        using (service)
        {
            // 使用 service
        }  // 自动调用 service.Dispose()，清空事件
    }
}

关键点：

• 订阅事件时，一定要在适当时机取消订阅
• 若对象实现了 IDisposable，在 Dispose 中取消所有事件订阅
• 采用弱事件模式（Weak Event Pattern）能够避免这个问题
• 在 WPF/MVVM 框架里，这个坑特别常用

场景 3：静态引用和单例模式中的隐形泄漏

这个坑最狡猾，因为静态对象的生命周期是整个应用程序，很容易被忽视。

问题代码

public class SingletonLeakDemo
{
    // 单例模式
    public class CacheManager
    {
        private static CacheManager _instance = new CacheManager();
        private Dictionary<string, IDisposable> _resources = new();
        
        public static CacheManager Instance => _instance;
        
        public void AddResource(string key, IDisposable resource)
        {
            _resources[key] = resource;
        }
        
        public void RemoveResource(string key)
        {
            // 问题：只是从字典中移除，但没有释放资源
            _resources.Remove(key);
        }
    }
    
    public void LeakyCode()
    {
        // 创建一个需要释放的资源
        var conn = new SqlConnection("Server=localhost;Database=test");
        
        // 添加到单例缓存
        CacheManager.Instance.AddResource("conn1", conn);
        
        // 后来想移除这个资源
        CacheManager.Instance.RemoveResource("conn1");
        
        // 问题：conn 对象虽然从字典中移除了，但从未被 Dispose()
        // 而且 CacheManager 是静态的，整个应用生命周期都存在
        // 所以 conn 永远不会被 GC 回收
    }
}

问题分析：

• 单例对象的生命周期 = 应用程序生命周期
• 若单例中存储了需释放的资源，这些资源也会被"永久保留"
• 即使从字典中移除，如果没有显式 Dispose，资源仍然泄漏

正确做法

public class SingletonLeakFixed
{
    public class CacheManager : IDisposable
    {
        private static readonly Lazy<CacheManager> _instance = 
            new Lazy<CacheManager>(() => new CacheManager());
        private Dictionary<string, IDisposable> _resources = new();
        private bool _disposed = false;
        public static CacheManager Instance => _instance.Value;
        public void AddResource(string key, IDisposable resource)
        {
            if (_disposed)
                throw new ObjectDisposedException(nameof(CacheManager));
            _resources[key] = resource;
        }
        public void RemoveResource(string key)
        {
            if (_resources.TryGetValue(key, out var resource))
            {
                // 关键：移除时立即释放资源
                resource?.Dispose();
                _resources.Remove(key);
            }
        }
        public void Dispose()
        {
            if (_disposed) return;
            // 释放所有缓存的资源
            foreach (var resource in _resources.Values)
            {
                resource?.Dispose();
            }
            _resources.Clear();
            _disposed = true;
        }
    }
    public void CorrectCode()
    {
        var conn = new SqlConnection("Server=localhost;Database=test");
        CacheManager.Instance.AddResource("conn1", conn);
        // 移除时自动释放
        CacheManager.Instance.RemoveResource("conn1");
        // 应用关闭时释放所有资源
        CacheManager.Instance.Dispose();
    }
}

关键点：

• 单例对象也要实现 IDisposable
• 在移除资源时，立即调用 Dispose()
• 应用关闭时，显式调用单例的 Dispose() 方法
• 采用 Lazy<T> 实现线程安全的单例

排查技巧：如何发现资源泄漏

1. 采用内存分析工具

// 在 Visual Studio 中使用内存分析工具
// Debug → Performance Profiler → Memory Usage
// 对比堆快照，找出未释放的对象

public void MemoryLeakTest()
{
    for (int i = 0; i < 10000; i++)
    {
        var conn = new SqlConnection("Server=localhost;Database=test");
        conn.Open();
        // 忘记 Dispose
    }
    // 内存分析工具会显示 10000 个 SqlConnection 对象未释放
}

2. 采用 GC.GetTotalMemory() 监控

public void MonitorMemory()
{
    long before = GC.GetTotalMemory(true);
    
    // 执行可能泄漏的代码
    for (int i = 0; i < 1000; i++)
    {
        using (var conn = new SqlConnection("Server=localhost;Database=test"))
        {
            conn.Open();
        }
    }
    
    long after = GC.GetTotalMemory(true);
    
    Console.WriteLine($"内存增长: {(after - before) / 1024 / 1024} MB");
    // 如果增长过大，说明有泄漏
}

3. 采用 Finalizer 检测

public class ResourceWithFinalizer : IDisposable
{
    private bool _disposed = false;
    
    public void Dispose()
    {
        Dispose(true);
        GC.SuppressFinalize(this);
    }
    
    protected virtual void Dispose(bool disposing)
    {
        if (!_disposed)
        {
            if (disposing)
            {
                // 释放托管资源
            }
            _disposed = true;
        }
    }
    
    ~ResourceWithFinalizer()
    {
        // 如果这个 Finalizer 被调用，说明 Dispose 没有被正确调用
        Console.WriteLine("警告：对象通过 Finalizer 被回收，可能存在泄漏");
        Dispose(false);
    }
}

总结

资源泄漏的 3 种隐蔽场景：

最后的建议：

• 永远采用 using 语句，不要手动调用 Dispose
• 订阅事件时，一定要记得取消订阅
• 单例对象也要实现 IDisposable，同时在适当时机释放
• 定期用内存分析工具检查，不要等到线上才发现

结合项目来看，下次面试被问到"如何排查资源泄漏"，你就能够从这 3 个场景入手，展示出你对 .NET 内存管理的深刻理解。

到此这篇关于一文揭秘C#中资源泄漏的3种隐蔽场景排查与解决的文章就介绍到这了,更多相关C#资源泄漏场景排查内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多兼容脚本之家！

您可能感兴趣的文章:

• C#防止内存泄漏的实战指南
• C#内存泄漏的四个常用场景及其解决办法
• C#非托管泄漏中HEAP_ENTRY的Size对不上解析
• C#中event内存泄漏总结