当需要向某特定URL地址发送HTTP请求并得到相应响应时,通常会用到HttpClient类。该类包含了众多有用的方法,可以满足绝大多数的需求。但是如果对其使用不当时,可能会出现意想不到的事情。

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

它的内部为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)

总结

以上就是这篇文章的全部内容了,希望本文的内容对大家的学习或者工作具有一定的参考学习价值,如果有疑问大家可以留言交流,谢谢大家对的支持。

标签:
dotnetcore,httpclientfactory类

免责声明:本站文章均来自网站采集或用户投稿,网站不提供任何软件下载或自行开发的软件! 如有用户或公司发现本站内容信息存在侵权行为,请邮件告知! 858582#qq.com
狼山资源网 Copyright www.pvsay.com

评论“DotNetCore深入了解之HttpClientFactory类详解”

暂无“DotNetCore深入了解之HttpClientFactory类详解”评论...

《魔兽世界》大逃杀!60人新游玩模式《强袭风暴》3月21日上线

暴雪近日发布了《魔兽世界》10.2.6 更新内容,新游玩模式《强袭风暴》即将于3月21 日在亚服上线,届时玩家将前往阿拉希高地展开一场 60 人大逃杀对战。

艾泽拉斯的冒险者已经征服了艾泽拉斯的大地及遥远的彼岸。他们在对抗世界上最致命的敌人时展现出过人的手腕,并且成功阻止终结宇宙等级的威胁。当他们在为即将于《魔兽世界》资料片《地心之战》中来袭的萨拉塔斯势力做战斗准备时,他们还需要在熟悉的阿拉希高地面对一个全新的敌人──那就是彼此。在《巨龙崛起》10.2.6 更新的《强袭风暴》中,玩家将会进入一个全新的海盗主题大逃杀式限时活动,其中包含极高的风险和史诗级的奖励。

《强袭风暴》不是普通的战场,作为一个独立于主游戏之外的活动,玩家可以用大逃杀的风格来体验《魔兽世界》,不分职业、不分装备(除了你在赛局中捡到的),光是技巧和战略的强弱之分就能决定出谁才是能坚持到最后的赢家。本次活动将会开放单人和双人模式,玩家在加入海盗主题的预赛大厅区域前,可以从强袭风暴角色画面新增好友。游玩游戏将可以累计名望轨迹,《巨龙崛起》和《魔兽世界:巫妖王之怒 经典版》的玩家都可以获得奖励。