OWIN+Identity+Web Api架构SQL连接泄漏问题如何排查修复？

问题根因 #

1. AspNet Identity 2.x与EF6的异步兼容缺陷：从堆栈信息可以定位到异常发生在UserStore.EnsureRolesLoaded加载用户关联数据阶段，Identity 2.x内置的GetUserAggregateAsync方法在加载用户导航属性（你代码中用到的user.MemberOf）时，若触发懒加载、或异步调用链未正确配置上下文捕获，会导致EF持有的数据库连接即使在DbContext被Dispose后，仍被未完全释放的异步上下文引用，无法回到连接池被复用，高并发下连接占用速度远超GC回收速度，最终触发连接池耗尽。
2. OWIN上下文与Web API过滤器生命周期不匹配：你在AuthenticationFilter中通过HttpContext.Current.GetOwinContext()获取注入实例，Web API过滤器的执行收尾逻辑独立于OWIN管道的销毁逻辑，高并发场景下部分OWIN上下文的Dispose操作会被延迟，进一步加剧连接释放滞后问题。
3. 连接配置缺失：若连接字符串未开启多活动结果集（MARS），同一DbContext上触发的多个异步查询会强制占用独立连接，进一步消耗连接池资源。

修复方案 #

• 重构认证逻辑的资源生命周期：不依赖OWIN注入的UserManager，在认证方法内手动创建并即时释放所有资源，从根源避免上下文持有问题：

private static async Task<IPrincipal> AuthenticateInternalAsync(string userName, string password, CancellationToken cancellationToken)
{
    cancellationToken.ThrowIfCancellationRequested();
    // 用using块包裹资源，方法执行结束后立即释放
    using(var context = ApplicationDbContext.Create(nameOrConnectionString))
    using(var userStore = new UserStore<ApplicationUser>(context))
    using(var userManager = new ApplicationUserManager(userStore))
    {
        var applicationUser = await userManager.FindByNameAsync(userName).ConfigureAwait(false);
        if (applicationUser == null) return null;
        var isAuthenticated = await userManager.CheckPasswordAsync(applicationUser, password).ConfigureAwait(false);
        if (!isAuthenticated) return null;
        // 显式加载导航属性，完全避免懒加载触发额外异步查询
        await context.Entry(applicationUser).Collection(u => u.MemberOf).LoadAsync(cancellationToken).ConfigureAwait(false);
        
        // 剩余原有逻辑保持不变
        var identity = new ClaimsIdentity(claims, DefaultAuthenticationTypes.ApplicationCookie);
        var roles = applicationUser.MemberOf.Select(member => member.Name).ToArray();
        return new GenericPrincipal(identity, roles);
    }
}

• 调整数据库连接配置：在连接字符串中追加以下参数，合理设置连接池上限并开启MARS支持：
  MultipleActiveResultSets=True;Max Pool Size=200;
  不需要将连接池上限设置到上万量级，常规并发场景下200-500的上限完全足够。
• 修复异步调用链配置：所有异步方法调用后添加.ConfigureAwait(false)，避免捕获同步上下文导致的任务和资源延迟释放。
• 可选优化：在ApplicationDbContext构造函数中全局禁用懒加载和代理创建，从框架层面避免隐式查询触发的连接占用：

public ApplicationDbContext() : base("nameOrConnectionString", throwIfV1Schema: false)
{
    Configuration.LazyLoadingEnabled = false;
    Configuration.ProxyCreationEnabled = false;
}

验证方式 #

修复后可通过SQL Server管理器查看活跃会话数，正常情况下500并发的性能测试，会话占用量会稳定在连接池上限的30%以内，不会再出现持续上涨的情况。

内容的提问来源于stack exchange，提问作者Raptor