Dispose 不释放？C# 资源泄漏的 3 种隐蔽场景排查

大家好，我是码农刚子。

最近在做项目代码审查时，发现了一个有意思的现象：大家都知道要用 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 种隐蔽场景：

场景	原因	解决方案
异常中断	异常导致 Dispose 代码不执行	使用 `using` 或 try-finally
事件订阅	事件处理器持有对象引用	取消订阅或使用弱事件模式
静态引用	单例/静态对象生命周期过长	在移除时立即 Dispose，应用关闭时清理

最后的建议：

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

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

你在项目中遇到过资源泄漏吗？欢迎在评论区分享你的踩坑故事！

Dispose 不释放？C# 资源泄漏的 3 种隐蔽场景排查

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

问题代码

正确做法

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

问题代码

正确做法

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

问题代码

正确做法

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

1. 使用内存分析工具

2. 使用 GC.GetTotalMemory() 监控

3. 使用 Finalizer 检测

总结

访客信息

关于博主

码农刚子

文章分类

标签云

最新文章

Dispose 不释放？C# 资源泄漏的 3 种隐蔽场景排查

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

问题代码

正确做法

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

问题代码

正确做法

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

问题代码

正确做法

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

1. 使用内存分析工具

2. 使用 GC.GetTotalMemory() 监控

3. 使用 Finalizer 检测

总结

相关文章

ML.NET 快速入门与实践教程：开源机器学习框架

聊一聊 C# 中的闭包陷阱：foreach 循环的坑你还记得吗？

访客信息

关于博主

码农刚子

文章分类

标签云

最新文章