DotNetCore深入了解之HttpClientFactory类详解

2025-05-29 0 40

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

?

1
using(var client = new HttpClient())

对象所占用资源应该确保及时被释放掉,但是,对于网络连接而言,这是错误的。

原因有二,网络连接是需要耗费一定时间的,频繁开启与关闭连接,性能会受影响;再者,开启网络连接时会占用底层socket资源,但在HttpClient调用其本身的Dispose方法时,并不能立刻释放该资源,这意味着你的程序可能会因为耗尽连接资源而产生预期之外的异常。

所以比较好的解决方法是延长HttpClient对象的使用寿命,比如对其建一个静态的对象:

?

1
private static HttpClient Client = new HttpClient();

但从程序员的角度来看,这样的代码或许不够优雅。

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

它的用法很简单,首先是对其进行IoC的注册:

?

1

2

3

4

5
public void ConfigureServices(IServiceCollection services)

{

services.AddHttpClient();

services.AddMvc();

}

然后通过IHttpClientFactory创建一个HttpClient对象,之后的操作如旧,但不需要担心其内部资源的释放:

?

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16
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的源码:

?

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28
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方法:

?

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20
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分钟。

?

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23
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对象。

?

1

2

3

4

5

6

7
public ExpiredHandlerTrackingEntry(ActiveHandlerTrackingEntry other)

{

Name = other.Name;

_livenessTracker = new WeakReference(other.Handler);

InnerHandler = other.Handler.InnerHandler;

}

在其构造方法内部,handler对象通过弱引用方式关联着,不会影响其被GC释放。

然后新建的ExpiredHandlerTrackingEntry对象被放入专用的队列。

最后开始清理工作,定时器的时间间隔设定为每10秒一次。

?

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

61

62

63

64

65

66

67

68

69

70

71
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类的扩展方法。

?

1

2

3

4

5

6

7

8

9
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程序中使用,还无法应用到诸如控制台一类的程序,希望之后官方能够对其继续增强,使得应用范围变得更广。

?

1

2

3

4

5
public DefaultHttpClientFactory(

IServiceProvider services,

ILoggerFactory loggerFactory,

IOptionsMonitor<HttpClientFactoryOptions> optionsMonitor,

IEnumerable<IHttpMessageHandlerBuilderFilter> filters)

总结

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

原文链接:https://www.cnblogs.com/lizhizhang/p/9502862.html

收藏 (0) 打赏

感谢您的支持,我会继续努力的!

打开微信/支付宝扫一扫,即可进行扫码打赏哦,分享从这里开始,精彩与您同在
点赞 (0)

声明:本站所有文章,如无特殊说明或标注,均为本站原创发布。任何个人或组织,在未征得本站同意时,禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益,可联系我们进行处理。

快网idc优惠网 建站教程 DotNetCore深入了解之HttpClientFactory类详解 https://www.kuaiidc.com/98350.html

相关文章

发表评论
暂无评论