ASP.NET Core 6迁移后EF出现间歇性连接关闭异常的解决咨询

核心问题定位 #

异常"An error occurred while closing the provider connection"的直接诱因是数据库连接未被正确回收，结合你的代码和迁移背景，主要原因有两点：

1. 部分仓储直接实例化UnitOfWork却未通过using释放，导致DbContext持有的数据库连接无法及时返回连接池，最终引发连接状态异常。
2. ASP.NET Core的DI生命周期管理比旧MVC更严格，未通过DI注入的UnitOfWork无法被框架自动管理生命周期，多个仓储共享的同一个UnitOfWork可能出现重复释放或释放时机错误的问题。

快速验证方案（先解决最明显的问题） #

先针对直接实例化UnitOfWork的代码进行修改，用using语句确保资源被及时释放，这是成本最低的验证手段：

public List<SomeClass> GetItems()
{
    // 用using包裹，确保UnitOfWork和DbContext被正确释放
    using (var uow = new UnitOfWork())
    {
        return uow.Context.Claims.ToList();
    }
}

修改后观察异常是否减少或消失，这能快速确认资源泄漏是否是核心诱因。

分阶段DI改造（避免一次性重构风险） #

如果快速验证有效，可以逐步推进DI改造，不用一次性修改所有仓储：

1. 注册UnitOfWork生命周期：在Program.cs中添加Scoped生命周期的注册，确保一个请求内共享同一个UnitOfWork实例，符合业务场景且能被框架自动管理释放：

// 注册Scoped生命周期的UnitOfWork
builder.Services.AddScoped<IUnitOfWork, UnitOfWork>();

2. 优先改造异常高发模块：先针对出现异常的业务模块，将仓储的构造函数注入改为依赖DI提供的IUnitOfWork，停止手动实例化。例如确保所有共享同一UnitOfWork的仓储都通过构造函数接收注入的实例，而非自行创建。
3. 完善UnitOfWork的Dispose实现：确保Dispose方法正确释放DbContext，避免连接泄漏：

public class UnitOfWork : IUnitOfWork, IDisposable
{
    public IDispatchDataContext Context { get; private set; }

    public UnitOfWork()
    {
        Context = new DispatchDataContext();
    }

    private bool _disposed = false;

    public void Dispose()
    {
        Dispose(true);
        GC.SuppressFinalize(this);
    }

    protected virtual void Dispose(bool disposing)
    {
        if (!_disposed)
        {
            if (disposing)
            {
                // 释放DbContext
                Context?.Dispose();
            }
            _disposed = true;
        }
    }

    // 析构函数，确保非托管资源被释放
    ~UnitOfWork()
    {
        Dispose(false);
    }
}

额外排查点 #

• 连接池配置：检查连接字符串的Max Pool Size参数，默认是100，如果业务并发较高，可适当调整（如Max Pool Size=200;），避免连接池耗尽导致的异常。
• 异步操作风险：确保UnitOfWork不会被跨线程调用，异步操作中不要将UnitOfWork实例传递到其他线程，否则可能出现并发释放的问题。
• DbContext配置：检查DispatchDataContext的构造函数是否正确配置连接字符串，ASP.NET Core中需确保从配置文件读取正确的连接字符串，避免因连接配置错误导致的连接异常。

内容的提问来源于stack exchange，提问作者Vikram Singh Saini