使用HttpClient的優解

新工做入職不久，目前仍然還在適應環境當中，筆者不得不說看別人的源碼實在是使人痛苦。所幸前些日子終於將工做流暢地看了一遍，接下來就是熟悉框架技術的階段了。

也正是在看源碼的過程中，有一個比較明顯的用法細節引發了個人注意，我發現一位同事在請求遠程Web Api時，雖然使用了 HttpClient 類，可是在用法上彷佛有些欠考慮。代碼抽象出來就是如下的模樣：

using(var client = new HttpClient())
{
    //do something
}

咱們知道 using 關鍵字經常和實現了 IDisposable 接口的類型一塊兒使用（如數據庫鏈接和文件流操做），用於釋放對象機資源（關於GC回收的相關知識可參考個人另外一篇博文《CLR和.Net對象生存週期》），可是對於 HttpClient 這樣直接和TCP/IP協議打交道的類型倒是未必（ HttpClient 繼承了 HttpMessageInvoker 類， HttpMessageInvoker 實現了 IDisposable 接口，實現上是比較經典的代理模式），翻看一些國內外的文章都能看到對在 using 關鍵字中使用 HttpClient 的吐槽。事實是否是真的這樣呢，其實只要作一個小實驗就能夠了。

讓咱們先試着運行如下代碼

class Program
    {
        static void Main(string[] args)
        {
            for (int i = 0; i < 10000; i++)
            {
                using (var client = new HttpClient())
                {
                    var result = client.GetAsync("http://www.baidu.com").Result;
                    Console.WriteLine(result.StatusCode);
                }
            }
            
            Console.ReadKey();
        }
    }

不出意外就會提示如下錯誤：

單純爲了解決問題而言，咱們能夠經過減少 HttpClient 的 Timeout 屬性加快回收速度（修改系統變量可能會引起其餘的問題），但實際上，這仍是由於 HttpClient 消耗了太多套接字鏈接的關係。爲了驗證這個問題，咱們可使用TcpView這個小工具來查看下項目運行時的 TCP 鏈接數，若是你下載了代碼運行後，會發現 TCP 鏈接和瘋狗同樣向上猛躥。雖然還會有套接字回收的現象，可是和增長的速度相比確實是杯水車薪。

因此這時候咱們須要換一種寫法：

class Program
    {
        private static readonly HttpClient Client=new HttpClient();

        static void Main(string[] args)
        {
            for (int i = 0; i < 10000; i++)
            {
            
            
                var result = Client.GetAsync("http://www.baidu.com").Result;
                Console.WriteLine(result.StatusCode);
            }

            Console.ReadKey();
        }
    }

更換以上寫法後，咱們會發現不管咱們將循環上限如何調整，也不會出現套接字鏈接資源不足的狀況了，而TCPView的結果也好看得多，甚至若是咱們每次都測試傳輸時間的話，咱們會發現單次調用 HttpClient 而言，第二種代碼比第一種代碼要快得多。其實這很好理解，HttpClient內部維持一個專有的鏈接池，每一個HttpClient實例的請求相互隔絕，加快速度的緣由是由於重用了套接字，去除了套接字從新創建鏈接的過程。這也很好地解釋了dudu園長的那一篇博客 《C#中HttpClient使用注意：預熱與長鏈接》中的「預熱」說法。盜一張圖來講明一下套接字的使用狀況。

所以，在使用 HttpClient 時咱們知道如下幾件小事

• 將其定義爲單例模式（由單獨的HttpClient維護鏈接池）
• 不要使用using關鍵字包裹（無效，套接字資源不會跟隨釋放）
• 儘可能不要額外改變 HttpClient 的一些特殊行爲（如上文中的TimeOut）
• 當你須要配置不一樣的Http請求時，容許生成並使用多個HttpClient

其實HttpClient還有一種使用隱患，DNS-Bug，這種作法國外也有同僚給出了相應的解釋和解決方案，詳情請見《Singleton HttpClient? Beware of this serious behaviour and how to fix it》

單例模式擴展開來也有不少的說法，根據C#的一些規範，在編程中我推薦三種作法

A. 靜態構造器

這種方式適用於如上代碼場景，使用靜態構造器確保靜態字段的實例化。

class Program
    {

        private static readonly HttpClient Client;

        static Program()
        {
            Client=new HttpClient();
        }

        static void Main(string[] args)
        {
            //do something
        }
    }

B. HttpClientHelper

單例模式中，經典的雙重檢查鎖定機制。

public static class HttpClientHelper
    {

        private static readonly object LockObj = new object();

        private static HttpClient _client;

        public static HttpClient HttpClient {
            get
            {
                if (_client == null)
                {
                    lock (LockObj)
                    {
                        if (_client == null)
                        {
                            _client= new HttpClient();
                        }
                    }
                }
                
                return _client;
            }
        }
    }

C. HttpClientHelper

這是在編程規範中推薦的一種的作法，經過使用靜態構造函數可以精確保證Client變量可以在它第一次被使用前被實例化。

固然你也能夠直接使用內聯的方式進行初始化，這樣能夠對類型進行性能優化，不過變量的初始化時間就沒法進行精準控制了

public sealed class HttpClientHelper
    { 

        private HttpClientHelper(){}
        
        public static readonly HttpClient Client;

        static HttpClientHelper()
        {
            Client=new HttpClient();   
        }
    }

寄語

多點實踐多點總結，爲認識更深入的代碼世界而奮鬥。