在 .NET Framework 與 .NET Core 中 HttpClient 有個臭名昭著的問題，HttpClient 實現了 IDispose 接口，但當你 Dispose 它時，它不會立即關閉所使用的 tcp 連接，而是將 tcp 連接置為 TIME_WAIT 狀態(tài)，240秒（4分鐘）后才真正關閉連接。對于高并發(fā)的場景，比如每秒 1000 個請求，每個請求都用到 HttpClient ，4分鐘內會堆積24萬個 tcp 連接，這樣的連接爆棚會拖垮服務器。為了避開這個坑，通常采用的變通方法是使用靜態(tài)的 HttpClient ，但會帶來另外一個臭名還沒昭著的問題，當 HttpClient 請求的主機名對應的 IP 地址變更時，HttpClient 會蒙在鼓里毫不知情，除非重啟應用程序。

為了徹底解決這兩個問題，解救廣大 .NET 開發(fā)人員，HttpClientFactory 在 .NET Core 2.1 中閃亮登場。那 HttpClientFactory 是如何解決問題的呢？讓我們一起來參觀一下這個有點特別的工廠。

工廠地址在微軟市 github 區(qū) aspnet 街 105584022 號 ，https://github.com/aspnet/HttpClientFactory

參觀 HttpClientFactory 之前先更多了解一下 HttpClient 的 Dispose 問題。

HttpClient 被 Dispose 時產生 TIME_WAIT 狀態(tài)的 tcp 連接的本質是在 HttpClient 被 Dispose 時，它所依賴的 HttpMessageHandler 也被 Dispose 了，管理 tcp 連接的正是 HttpMessageHandler ，HttpMessageHandler?是抽象類，落實到實際應用場景通常是?SocketsHttpHandler?，SocketsHttpHandler 通過?HttpConnectionPoolManager?管理著?HttpConnectionPool?，池中養(yǎng)著一堆 HttpConnection 對應的 tcp 連接，Dispose SocketsHttpHandler 影響的通常不是一個 tcp 連接，而是一池 tcp 連接，也就是會將整個池中的所有 tcp 連接都置于 TIME_WAIT 狀態(tài)，并發(fā)量越大，池中的連接越多，Dispose 的殺傷力越大，大到可以會引發(fā)?socket exhaustion?。所以，要想解決這個問題就要減少 Dispose 操作，最極端的情況就是使用靜態(tài)的 HttpClient ，永不 Dispose ，但如前所述這樣做的副作用很大。

既要 Dispose HttpClient，又要控制好火候，這是解決這個棘手問題的關鍵，而 HttpClientFactory 也正是從這個角度出發(fā)打造出了一個可定時 Dispose 的工廠。

HttpClientFactory 創(chuàng)建 HttpClient 實例的主要代碼如下：

為了解決 HttpMessageHandler 的 Dispose 問題，HttpClientFactory 工廠設計制造出了一款新型 HttpMessageHandler —— LifetimeTrackingHttpMessageHandler ，一個有保質期的 HttpMessageHandler （默認是 2 分鐘），新生產的 LifetimeTrackingHttpMessageHandler （之后簡稱 handler）會被放入 _activeHandlers ，過了保質期的 handler 會被放入 _expiredHandlers （有個 Timer 專門在 ExpiryTimer_Tick 回調方法中負責檢查保質期）， 而在 _expiredHandlers 中的 handler 們會被進一步檢查，有個 CleanupTimer 專門在 CleanupTimer_Tick 回調方法中每隔10秒負責檢查，進一步檢查什么呢？檢查這些過期產品（handler）是否可以作廢（Dispose），怎么檢查的？通過 WeakReference ，代碼如下：

如果 _expiredHandlers 中的 handler 已經被 GC 回收（同時也說明對應的 HttpClient 也被 GC 回收），那就 Dispose 掉它。

HttpClientFactory 就是這樣通過 2 個定時器有條不紊地控制著 Dispose HttpMessageHandler 釋放 TCP 連接的火候，避免在同一時間 Dispose 太多 HttpMessageHandler 引發(fā)的 socket exhaustion 解決了 HttpClient 臭名昭著的問題。

相關文章：

• ASP.Net Core2.1中的HttpClientFactory系列一

• HttpClientFactory系列二：集成Polly處理瞬態(tài)故障

• 在 .NET Core 中結合 HttpClientFactory 使用 Polly（上篇）

• 在 .NET Core 中結合 HttpClientFactory 使用 Polly（中篇）

• 在 .NET Core 中結合 HttpClientFactory 使用 Polly（下篇）
  

原文地址:?https://www.cnblogs.com/dudu/p/http-client-factory.html

---

.NET社區(qū)新聞，深度好文，歡迎訪問公眾號文章匯總 http://www.csharpkit.com

總結

以上是生活随笔為你收集整理的工厂参观记：.NET Core 中 HttpClientFactory 如何解决 HttpClient 臭名昭著的问题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。