當(dāng)需要向某特定URL地址發(fā)送HTTP請(qǐng)求并得到相應(yīng)響應(yīng)時(shí)，通常會(huì)用到HttpClient類。該類包含了眾多有用的方法，可以滿足絕大多數(shù)的需求。但是如果對(duì)其使用不當(dāng)時(shí)，可能會(huì)出現(xiàn)意想不到的事情。
|
1
|
using(var client = new HttpClient()) |
對(duì)象所占用資源應(yīng)該確保及時(shí)被釋放掉，但是，對(duì)于網(wǎng)絡(luò)連接而言，這是錯(cuò)誤的。
原因有二，網(wǎng)絡(luò)連接是需要耗費(fèi)一定時(shí)間的，頻繁開啟與關(guān)閉連接，性能會(huì)受影響；再者，開啟網(wǎng)絡(luò)連接時(shí)會(huì)占用底層socket資源，但在HttpClient調(diào)用其本身的Dispose方法時(shí)，并不能立刻釋放該資源，這意味著你的程序可能會(huì)因?yàn)楹谋M連接資源而產(chǎn)生預(yù)期之外的異常。
所以比較好的解決方法是延長(zhǎng)HttpClient對(duì)象的使用壽命，比如對(duì)其建一個(gè)靜態(tài)的對(duì)象：
|
1
|
private static HttpClient Client = new HttpClient(); |
但從程序員的角度來看，這樣的代碼或許不夠優(yōu)雅。
所以在.NET Core 2.1中引入了新的HttpClientFactory類。
它的用法很簡(jiǎn)單，首先是對(duì)其進(jìn)行IoC的注冊(cè)：
|
1
2
3
4
5
|
public void ConfigureServices(IServiceCollection services){ services.AddHttpClient(); services.AddMvc();} |
然后通過IHttpClientFactory創(chuàng)建一個(gè)HttpClient對(duì)象，之后的操作如舊，但不需要擔(dān)心其內(nèi)部資源的釋放：
|
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;} |
它的內(nèi)部為IHttpClientFactory接口綁定了DefaultHttpClientFactory類。
再看IHttpClientFactory接口中關(guān)鍵的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的創(chuàng)建不再是簡(jiǎn)單的new HttpClient()，而是傳入了兩個(gè)參數(shù)：HttpMessageHandler handler與bool disposeHandler。disposeHandler參數(shù)為false值時(shí)表示要重用內(nèi)部的handler對(duì)象。handler參數(shù)則從上一句的代碼可以看出是以name為鍵值從一字典中取出，又因?yàn)镈efaultHttpClientFactory類是通過TryAddSingleton方法注冊(cè)的，也就意味著其為單例，那么這個(gè)內(nèi)部字典便是唯一的，每個(gè)鍵值對(duì)應(yīng)的ActiveHandlerTrackingEntry對(duì)象也是唯一，該對(duì)象內(nèi)部中包含著handler。
下一句代碼StartHandlerEntryTimer(entry); 開啟了ActiveHandlerTrackingEntry對(duì)象的過期計(jì)時(shí)處理。默認(rèn)過期時(shí)間是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對(duì)象傳入新的ExpiredHandlerTrackingEntry對(duì)象。
|
1
2
3
4
5
6
7
|
public ExpiredHandlerTrackingEntry(ActiveHandlerTrackingEntry other){ Name = other.Name; _livenessTracker = new WeakReference(other.Handler); InnerHandler = other.Handler.InnerHandler;} |
在其構(gòu)造方法內(nèi)部，handler對(duì)象通過弱引用方式關(guān)聯(lián)著，不會(huì)影響其被GC釋放。
然后新建的ExpiredHandlerTrackingEntry對(duì)象被放入專用的隊(duì)列。
最后開始清理工作，定時(shí)器的時(shí)間間隔設(shè)定為每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對(duì)象已經(jīng)被GC，如果是的話，則釋放其內(nèi)部資源，即網(wǎng)絡(luò)連接。
回到最初創(chuàng)建HttpClient的代碼，會(huì)發(fā)現(xiàn)并沒有傳入任何name參數(shù)值。這是得益于HttpClientFactoryExtensions類的擴(kuò)展方法。
|
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缺少無參數(shù)的構(gòu)造方法，唯一的構(gòu)造方法需要傳入多個(gè)參數(shù)，這也意味著構(gòu)建它時(shí)需要依賴其它一些類，所以目前只適用于在ASP.NET程序中使用，還無法應(yīng)用到諸如控制臺(tái)一類的程序，希望之后官方能夠?qū)ζ淅^續(xù)增強(qiáng)，使得應(yīng)用范圍變得更廣。
|
1
2
3
4
5
|
public DefaultHttpClientFactory( IServiceProvider services, ILoggerFactory loggerFactory, IOptionsMonitor<HttpClientFactoryOptions> optionsMonitor, IEnumerable<IHttpMessageHandlerBuilderFilter> filters) |
總結(jié)
以上就是這篇文章的全部?jī)?nèi)容了，希望本文的內(nèi)容對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，如果有疑問大家可以留言交流，謝謝大家對(duì)服務(wù)器之家的支持。
原文鏈接：https://www.cnblogs.com/lizhizhang/p/9502862.html
