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<TContext>(
[NotNull] this IServiceCollection serviceCollection,
[NotNull] Action<DbContextOptionsBuilder> optionsAction,
int poolSize = 128)
where TContext : DbContext
=> AddDbContextPool<TContext, TContext>(serviceCollection, optionsAction, poolSize);
查看 SqlConnention 的 實現源碼 發現連接池的默認大小限制是 100
internal const int Max_Pool_Size = 100;
默認設置就會觸發問題，實實在在的一個小坑。
知道了原因，解決起來就很簡單了，將 DbContextPool 的 poolSize 設置為小於數據庫連接池的 Max_Pool_Size
services.AddDbContextPool<JobDb>(option =>
option.UseSqlServer(Configuration.DbConnectionStr()),
poolSize: 64);