知識星球DbContextPool 是 ASP.NET Core 2.1 引入的新特性，可以節省建立 DbContext 實體的開銷，但沒有想到其中藏著一個小坑。
最近有一個 ASP.NET Core 專案持續執行一段時間後日誌中就會出現資料庫連線池達到最大連線數限制的錯誤：
System.InvalidOperationException: Timeout expired. The timeout period elapsed prior to obtaining a connection from the pool. This may have occurred because all pooled connections were in use and max pool size was reached.
at System.Data.Common.ADP.ExceptionWithStackTrace(Exception e)開始以為是哪個地方的程式碼造成 DbContext 不能正常 Dispose ，但在程式碼中沒有找到任何相關線索。後來實在沒有其他可以懷疑的地方，唯有 DbContextPool ，於是嘗試去掉 DbContextPool ，結果錯誤就消失了。果然是 DbContextPool 引起的，但讓人納悶的是 DbContextPool 本來就是為了節省建立 DbContext 實體的開銷，怎麼反而消耗更多資料庫連線，而且這個專案的負載很低，怎麼可能把整個連線池都消耗殆盡呢？
今天在周會上談了這個怪問題，後來突然想到：每個 DbContext 實體都會佔用一個資料庫連線（SqlConnection），不啟用 DbContextPool 的時候，請求一結束，對應 DbContext 實體就被 Dispose ，資料庫連線就會被放回連線池。而使用 DbContextPool 的時候，請求結束後 DbContext 不會被 Dispose 而是被放回 DbContextPool ，DbContext 被放回屬於自己的池中，就意味它對應的資料庫連線不會被放回它所屬的連線池。DbContextPool 中的每一個 DbContext 都對應一個資料庫連線，DbContextPool 中每多一個 DbContext ，資料庫連線池中就會少一個資料庫連線。當這兩個池的大小不一樣且 DbContextPool 大於資料庫連線池，問題就來了，DbContextPool 根據自家池（假設是128）子的大小暢快地向池中填 DbContext ，渾然不顧資料庫連線池的大小(假設是100)，當填到第 101 個 DbContext 時就會出現上面的錯誤。
這個專案中用的都是預設設定，是不是預設設定就會觸發這個問題呢？
檢視 DbContextPool 的 實現原始碼 發現池的預設大小限制是 128
public static IServiceCollection AddDbContextPool(
[NotNull] this IServiceCollection serviceCollection,
[NotNull] Action optionsAction,
int poolSize = 128)
where TContext : DbContext
=> AddDbContextPool(serviceCollection, optionsAction, poolSize);檢視 SqlConnention 的 實現原始碼 發現連線池的預設大小限制是 100
internal const int Max_Pool_Size = 100;預設設定就會觸發問題，實實在在的一個小坑。
知道了原因，解決起來就很簡單了，將 DbContextPool 的 poolSize 設定為小於資料庫連線池的 Max_Pool_Size
services.AddDbContextPool(option =>
option.UseSqlServer(Configuration.DbConnectionStr()),
poolSize: 64);原文地址：https://www.cnblogs.com/dudu/p/10398225.html
