如何在DotNetCore中使用HttpClientFactory類

這篇文章將為大家詳細(xì)講解有關(guān)如何在DotNetCore中使用HttpClientFactory類，文章內(nèi)容質(zhì)量較高，因此小編分享給大家做個(gè)參考，希望大家閱讀完這篇文章后對相關(guān)知識有一定的了解。

當(dāng)需要向某特定URL地址發(fā)送HTTP請求并得到相應(yīng)響應(yīng)時(shí)，通常會用到HttpClient類。該類包含了眾多有用的方法，可以滿足絕大多數(shù)的需求。但是如果對其使用不當(dāng)時(shí)，可能會出現(xiàn)意想不到的事情。

using(var client = new HttpClient())

對象所占用資源應(yīng)該確保及時(shí)被釋放掉，但是，對于網(wǎng)絡(luò)連接而言，這是錯(cuò)誤的。

原因有二，網(wǎng)絡(luò)連接是需要耗費(fèi)一定時(shí)間的，頻繁開啟與關(guān)閉連接，性能會受影響；再者，開啟網(wǎng)絡(luò)連接時(shí)會占用底層socket資源，但在HttpClient調(diào)用其本身的Dispose方法時(shí)，并不能立刻釋放該資源，這意味著你的程序可能會因?yàn)楹谋M連接資源而產(chǎn)生預(yù)期之外的異常。

所以比較好的解決方法是延長HttpClient對象的使用壽命，比如對其建一個(gè)靜態(tài)的對象：

private static HttpClient Client = new HttpClient();

但從程序員的角度來看，這樣的代碼或許不夠優(yōu)雅。

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

它的用法很簡單，首先是對其進(jìn)行IoC的注冊：

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

然后通過IHttpClientFactory創(chuàng)建一個(gè)HttpClient對象，之后的操作如舊，但不需要擔(dān)心其內(nèi)部資源的釋放：

public class LzzDemoController : Controller
{
 IHttpClientFactory _httpClientFactory;

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

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

AddHttpClient的源碼：

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

它的內(nèi)部為IHttpClientFactory接口綁定了DefaultHttpClientFactory類。

再看IHttpClientFactory接口中關(guān)鍵的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的創(chuàng)建不再是簡單的new HttpClient()，而是傳入了兩個(gè)參數(shù)：HttpMessageHandler handler與bool disposeHandler。disposeHandler參數(shù)為false值時(shí)表示要重用內(nèi)部的handler對象。handler參數(shù)則從上一句的代碼可以看出是以name為鍵值從一字典中取出，又因?yàn)镈efaultHttpClientFactory類是通過TryAddSingleton方法注冊的，也就意味著其為單例，那么這個(gè)內(nèi)部字典便是唯一的，每個(gè)鍵值對應(yīng)的ActiveHandlerTrackingEntry對象也是唯一，該對象內(nèi)部中包含著handler。

下一句代碼StartHandlerEntryTimer(entry); 開啟了ActiveHandlerTrackingEntry對象的過期計(jì)時(shí)處理。默認(rèn)過期時(shí)間是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;
}

在其構(gòu)造方法內(nèi)部，handler對象通過弱引用方式關(guān)聯(lián)著，不會影響其被GC釋放。

然后新建的ExpiredHandlerTrackingEntry對象被放入專用的隊(duì)列。

最后開始清理工作，定時(shí)器的時(shí)間間隔設(shè)定為每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對象已經(jīng)被GC，如果是的話，則釋放其內(nèi)部資源，即網(wǎng)絡(luò)連接。

回到最初創(chuàng)建HttpClient的代碼，會發(fā)現(xiàn)并沒有傳入任何name參數(shù)值。這是得益于HttpClientFactoryExtensions類的擴(kuò)展方法。

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缺少無參數(shù)的構(gòu)造方法，唯一的構(gòu)造方法需要傳入多個(gè)參數(shù)，這也意味著構(gòu)建它時(shí)需要依賴其它一些類，所以目前只適用于在ASP.NET程序中使用，還無法應(yīng)用到諸如控制臺一類的程序，希望之后官方能夠?qū)ζ淅^續(xù)增強(qiáng)，使得應(yīng)用范圍變得更廣。

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

關(guān)于如何在DotNetCore中使用HttpClientFactory類就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學(xué)到更多知識。如果覺得文章不錯(cuò)，可以把它分享出去讓更多的人看到。