EF Core 小坑：DbContextPool 會引發數據庫鏈接池鏈接耗盡

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);