PruneConnectionPoolGroups出现OutOfMemoryException的问题求助

我之前在生产环境处理过完全一致的问题——Windows服务停止时触发System.OutOfMemoryException，堆栈追踪指向System.Data.ProviderBase.DbConnectionFactory.PruneConnectionPoolGroups。下面分享几个经过验证的排查和解决方向：

1. 优先排查连接池泄漏（最常见根源） #

虽然你提到了竞态条件的猜测，但这类问题绝大多数是数据库连接未正确释放导致连接池持续膨胀，最终耗尽内存：

• 确保所有数据库操作都用using语句包裹DbConnection、DbCommand和DbDataReader，自动完成资源释放：

  using (var conn = new SqlConnection(connectionString))
  {
      conn.Open();
      using (var cmd = new SqlCommand(query, conn))
      using (var reader = cmd.ExecuteReader())
      {
          // 业务数据处理逻辑
      }
  }
  

• 检查代码中是否存在长期持有连接的场景（比如单例类缓存连接实例），这类情况会导致连接无法回收到池，最终撑爆内存。

2. 针对竞态条件的验证与修复 #

如果确认是事务未完成时连接池触发清理的竞态问题，可以尝试以下操作：

• 在服务停止逻辑中，主动等待所有未完成的数据库事务结束再执行停止流程。比如维护一个事务计数变量，停止前阻塞等待计数归0，或者用Cancellation Token通知所有异步操作优雅终止。
• 临时调整连接池配置（如增大Max Pool Size，默认值为100），但这只是缓解手段，无法根治竞态问题。

3. .NET框架版本升级修复 #

这个问题在旧版.NET Framework中存在已知的连接池bug，建议：

• 检查当前服务使用的.NET版本，如果是4.5及以下，尝试升级到.NET Framework 4.8——微软在后续版本中修复了多个连接池相关的竞态条件和内存泄漏问题。

4. 内存诊断工具辅助定位 #

如果以上方法无效，用工具精准定位内存泄漏点：

• 使用dotMemory或Visual Studio内置的内存诊断工具，捕获服务停止前的内存快照，分析是否有大量DbConnection实例未被回收。
• 启用ADO.NET连接池日志，通过配置文件添加跟踪开关，查看连接池的创建、销毁和修剪日志，定位异常行为：

  <system.diagnostics>
      <switches>
          <add name="System.Data" value="4" />
      </switches>
  </system.diagnostics>
  

我当时的场景是结合连接泄漏修复和**.NET版本升级**彻底解决了问题。如果你的服务包含异步数据库操作，还要特别注意异步方法的await是否正确使用，避免连接被意外持有。

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