.NET Core開發日誌——HttpClientFactory

當需要向某特定URL地址傳送HTTP請求並得到相應響應時，通常會用到HttpClient類。該類包含了眾多有用的方法，可以滿足絕大多數的需求。但是如果對其使用不當時，可能會出現意想不到的事情。

部落格園官方團隊就遇上過這樣的問題，國外博主也記錄過類似的情況，YOU`RE USING HTTPCLIENT WRONG AND IT IS DESTABILIZING YOUR SOFTWARE。

究其緣由是一句看似正確的程式碼引起的：

using(var client = new HttpClient())

物件所佔用資源應該確保及時被釋放掉，但是，對於網路連線而言，這是錯誤的。

原因有二，網路連線是需要耗費一定時間的，頻繁開啟與關閉連線，效能會受影響；再者，開啟網路連線時會佔用底層socket資源，但在HttpClient呼叫其本身的Dispose方法時，並不能立刻釋放該資源，這意味著你的程式可能會因為耗盡連線資源而產生預期之外的異常。

所以比較好的解決方法是延長HttpClient物件的使用壽命，比如對其建一個靜態的物件：

private static HttpClient Client = new HttpClient();

但從程式設計師的角度來看，這樣的程式碼或許不夠優雅。

所以在.NET Core 2.1中引入了新的HttpClientFactory類。

它的用法很簡單，首先是對其進行IoC的註冊：

public void ConfigureServices(IServiceCollection services)
{
    services.AddHttpClient();
    services.AddMvc();
}

然後通過IHttpClientFactory建立一個HttpClient物件，之後的操作如舊，但不需要擔心其內部資源的釋放：

public class MyController : Controller
{
    IHttpClientFactory _httpClientFactory;

    public MyController(IHttpClientFactory httpClientFactory)
    {
        _httpClientFactory = httpClientFactory;
    }

    public IActionResult Index()
    {
        var client = _httpClientFactory.CreateClient();
        var result = client.GetStringAsync("http://myurl/");
        return View();
    }
}

第一眼瞧去，可能不明白AddHttpClient方法與IHttpClientFactory有什麼關係，但查到其原始碼後就能一目瞭然：

public static IServiceCollection AddHttpClient(this IServiceCollection services)
{
    if (services == null)
    {
        throw new ArgumentNullException(nameof(services));
    }

    services.AddLogging();
    services.AddOptions();

    //
    // Core abstractions
    //
    services.TryAddTransient<HttpMessageHandlerBuilder, DefaultHttpMessageHandlerBuilder>();
    services.TryAddSingleton<IHttpClientFactory, DefaultHttpClientFactory>();

    //
    // Typed Clients
    //
    services.TryAdd(ServiceDescriptor.Singleton(typeof(ITypedHttpClientFactory<>), typeof(DefaultTypedHttpClientFactory<>)));

    //
    // Misc infrastructure
    //
    services.TryAddEnumerable(ServiceDescriptor.Singleton<IHttpMessageHandlerBuilderFilter, LoggingHttpMessageHandlerBuilderFilter>());

    return services;
}

它的內部為IHttpClientFactory介面繫結了DefaultHttpClientFactory類。

再看IHttpClientFactory介面中關鍵的CreateClient方法：

public HttpClient CreateClient(string name)
{
    if (name == null)
    {
        throw new ArgumentNullException(nameof(name));
    }

    var entry = _activeHandlers.GetOrAdd(name, _entryFactory).Value;
    var client = new HttpClient(entry.Handler, disposeHandler: false);

    StartHandlerEntryTimer(entry);

    var options = _optionsMonitor.Get(name);
    for (var i = 0; i < options.HttpClientActions.Count; i++)
    {
        options.HttpClientActions[i](client);
    }

    return client;
}

HttpClient的建立不再是簡單的new HttpClient()，而是傳入了兩個引數：HttpMessageHandler handler與bool disposeHandler。disposeHandler引數為false值時表示要重用內部的handler物件。handler引數則從上一句的程式碼可以看出是以name為鍵值從一字典中取出，又因為DefaultHttpClientFactory類是通過TryAddSingleton方法註冊的，也就意味著其為單例，那麼這個內部字典便是唯一的，每個鍵值對應的ActiveHandlerTrackingEntry物件也是唯一，該物件內部中包含著handler。

下一句程式碼StartHandlerEntryTimer(entry); 開啟了ActiveHandlerTrackingEntry物件的過期計時處理。預設過期時間是2分鐘。

internal void ExpiryTimer_Tick(object state)
{
    var active = (ActiveHandlerTrackingEntry)state;

    // The timer callback should be the only one removing from the active collection. If we can`t find
    // our entry in the collection, then this is a bug.
    var removed = _activeHandlers.TryRemove(active.Name, out var found);
    Debug.Assert(removed, "Entry not found. We should always be able to remove the entry");
    Debug.Assert(object.ReferenceEquals(active, found.Value), "Different entry found. The entry should not have been replaced");

    // At this point the handler is no longer `active` and will not be handed out to any new clients.
    // However we haven`t dropped our strong reference to the handler, so we can`t yet determine if
    // there are still any other outstanding references (we know there is at least one).
    //
    // We use a different state object to track expired handlers. This allows any other thread that acquired
    // the `active` entry to use it without safety problems.
    var expired = new ExpiredHandlerTrackingEntry(active);
    _expiredHandlers.Enqueue(expired);

    Log.HandlerExpired(_logger, active.Name, active.Lifetime);

    StartCleanupTimer();
}

先是將ActiveHandlerTrackingEntry物件傳入新的ExpiredHandlerTrackingEntry物件。

public ExpiredHandlerTrackingEntry(ActiveHandlerTrackingEntry other)
{
    Name = other.Name;

    _livenessTracker = new WeakReference(other.Handler);
    InnerHandler = other.Handler.InnerHandler;
}

在其構造方法內部，handler物件通過弱引用方式關聯著，不會影響其被GC釋放。

然後新建的ExpiredHandlerTrackingEntry物件被放入專用的佇列。

最後開始清理工作，定時器的時間間隔設定為每10秒一次。

internal void CleanupTimer_Tick(object state)
{
    // Stop any pending timers, we`ll restart the timer if there`s anything left to process after cleanup.
    //
    // With the scheme we`re using it`s possible we could end up with some redundant cleanup operations.
    // This is expected and fine.
    // 
    // An alternative would be to take a lock during the whole cleanup process. This isn`t ideal because it
    // would result in threads executing ExpiryTimer_Tick as they would need to block on cleanup to figure out
    // whether we need to start the timer.
    StopCleanupTimer();

    try
    {
        if (!Monitor.TryEnter(_cleanupActiveLock))
        {
            // We don`t want to run a concurrent cleanup cycle. This can happen if the cleanup cycle takes
            // a long time for some reason. Since we`re running user code inside Dispose, it`s definitely
            // possible.
            //
            // If we end up in that position, just make sure the timer gets started again. It should be cheap
            // to run a `no-op` cleanup.
            StartCleanupTimer();
            return;
        }

        var initialCount = _expiredHandlers.Count;
        Log.CleanupCycleStart(_logger, initialCount);

        var stopwatch = ValueStopwatch.StartNew();

        var disposedCount = 0;
        for (var i = 0; i < initialCount; i++)
        {
            // Since we`re the only one removing from _expired, TryDequeue must always succeed.
            _expiredHandlers.TryDequeue(out var entry);
            Debug.Assert(entry != null, "Entry was null, we should always get an entry back from TryDequeue");

            if (entry.CanDispose)
            {
                try
                {
                    entry.InnerHandler.Dispose();
                    disposedCount++;
                }
                catch (Exception ex)
                {
                    Log.CleanupItemFailed(_logger, entry.Name, ex);
                }
            }
            else
            {
                // If the entry is still live, put it back in the queue so we can process it 
                // during the next cleanup cycle.
                _expiredHandlers.Enqueue(entry);
            }
        }

        Log.CleanupCycleEnd(_logger, stopwatch.GetElapsedTime(), disposedCount, _expiredHandlers.Count);
    }
    finally
    {
        Monitor.Exit(_cleanupActiveLock);
    }

    // We didn`t totally empty the cleanup queue, try again later.
    if (_expiredHandlers.Count > 0)
    {
        StartCleanupTimer();
    }
}

上述方法核心是判斷是否handler物件已經被GC，如果是的話，則釋放其內部資源，即網路連線。

回到最初建立HttpClient的程式碼，會發現並沒有傳入任何name引數值。這是得益於HttpClientFactoryExtensions類的擴充套件方法。

public static HttpClient CreateClient(this IHttpClientFactory factory)
{
    if (factory == null)
    {
        throw new ArgumentNullException(nameof(factory));
    }

    return factory.CreateClient(Options.DefaultName);
}

Options.DefaultName的值為string.Empty。

DefaultHttpClientFactory缺少無引數的構造方法，唯一的構造方法需要傳入多個引數，這也意味著構建它時需要依賴其它一些類，所以目前只適用於在ASP.NET程式中使用，還無法應用到諸如控制檯一類的程式，希望之後官方能夠對其繼續增強，使得應用範圍變得更廣。

public DefaultHttpClientFactory(
    IServiceProvider services,
    ILoggerFactory loggerFactory,
    IOptionsMonitor<HttpClientFactoryOptions> optionsMonitor,
    IEnumerable<IHttpMessageHandlerBuilderFilter> filters)