ASP.NET Core中请求数超出SQL连接池容量时的运行机制探究

核心规则与场景表现 #

当连接池最大可用连接数设为10，同时有40个连接请求时，不会像线程池那样临时创建超出上限的新物理连接，具体流程如下：

• 前10个连接请求：连接池会创建10个物理数据库连接，分配给这10个请求，标记为「已占用」状态。
• 第11至40个连接请求：池内无可用连接，这些请求会进入等待队列，等待已占用的连接被释放回池。
• 等待超时逻辑：默认等待超时时间为15秒（可通过连接字符串的Connection Timeout参数调整）。若超时前有连接被释放（比如SqlConnection调用Close/Dispose，或using块执行完毕自动释放），该连接会被分配给等待队列的下一个请求，实现复用；若超时仍未获取到可用连接，会抛出InvalidOperationException，提示池连接耗尽。

连接复用的顺序 #

连接池对可用连接采用**先进先出（FIFO）**的队列管理机制：

• 被释放回池的连接会被加入队列尾部；
• 新的连接请求会从队列头部获取可用连接，确保最早释放的连接被优先复用。

套接字耗尽的可能性评估 #

套接字耗尽的风险主要取决于两个因素：

• 连接池配置与连接泄漏情况：只要合理设置连接池最大连接数（默认是100），且代码中通过using块等方式确保SqlConnection被正确释放，物理连接的数量始终不会超过池的上限，不会出现套接字耗尽。
• 是否绕过连接池：如果连接字符串中设置Pooling=false，则每次创建SqlConnection都会建立新的物理连接，此时若大量创建连接且未及时释放，会快速耗尽系统套接字资源，引发故障。

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