ASP.NET Core中相同连接字符串的EF、Hangfire、Serilog是否共享连接池？

三个模块是否共享连接池 #

是的，三个功能模块会共享同一个连接池。ADO.NET 连接池的唯一标识依据是标准化解析后的连接字符串，只要三个组件使用的连接字符串所有参数完全一致，就会被划分到同一个连接池管理，和三个组件各自操作的SQL Schema无关，Schema属于SQL层面的逻辑命名空间划分，不会影响底层连接池的分配逻辑。

连接池爆满报错排查方向 #

你遇到的连接池超时报错是因为池内所有连接都被占用且达到最大上限（默认100），无法分配新连接，结合你给出的代码，可以按以下优先级排查：

• 删除手动释放DbContext的逻辑：EF Core的DbContext默认注册为Scope生命周期，ASP.NET Core DI容器会在请求结束时自动释放DbContext，你在BaseService中手动Dispose DbContext属于多余操作，甚至可能导致连接状态异常，无法正常归还到连接池。
• 修正OrderService构造函数语法错误：你贴出的OrderService构造函数语法存在问题，正确的注入写法应为public OrderService(MyDBContext dbContext):base(dbContext)，如果实际运行代码也是错误写法，会导致DbContext没有被正确托管，出现连接泄漏。
• 检查异步方法调用规范：如果业务代码中存在未加await调用异步方法、使用.Result/.Wait()同步阻塞异步方法的情况，会导致异步上下文卡住，连接无法被正常释放，快速占满连接池。
• 调整Hangfire配置：Hangfire默认会占用若干常驻连接用于任务调度，如果你配置的Worker并发数过高，会持续占用大量连接挤压业务可用额度。如果需要隔离Hangfire的连接占用，可以给Hangfire的连接字符串单独加Application Name=Hangfire参数，让它使用独立的连接池。
• 优化Serilog MSSqlServer Sink配置：如果业务日志量较大，可以调整Sink的批量写入参数batchPostingLimit、period，降低日志写入的连接占用频率。
• 临时验证方案：可以在连接字符串中添加Max Pool Size=200临时提高连接池上限，如果报错消失，说明默认100的连接数不足以支撑业务并发，再针对性做性能优化即可。

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