Müssen HttpClient und HttpClientHandler entsorgt werden?

Der Allgemeine Konsens ist, dass Sie nicht (sollte nicht) entsorgen müssen HttpClient.

Viele Menschen, die sehr eng eingebunden in die Art, wie es funktioniert angegeben haben.

Sehen Darrel Miller ' s blog-post und im Zusammenhang DAMIT posten: HttpClient-crawling-Ergebnisse in Speicherverlust für Referenz.

Ich würde auch empfehlen, dass Sie Lesen die HttpClient-Kapitel von Gestaltung Optimierbare Web-APIs mit ASP.NET Kontext auf, was Los ist unter der Haube, vor allem das "Lifecycle" - Abschnitt hier zitiert:

Obwohl HttpClient hat indirekt die IDisposable implementieren
Schnittstelle, die standard-Verwendung der HttpClient ist nicht, Sie zu entsorgen
nach jeder Anfrage. Das HttpClient-Objekt bestimmt ist, so zu Leben, wie
lange, wie Sie Ihre Anwendung braucht, um HTTP-Anfragen. Ein Objekt haben
bestehen über mehrere Anfragen hinweg ermöglicht, einen Platz für die Einstellung
DefaultRequestHeaders und verhindert, dass Sie zu re-spezifizieren
Dinge wie CredentialCache-und CookieContainer auf jede Anfrage
notwendig war mit HttpWebRequest.

Oder sogar öffnen DotPeek.

InformationsquelleAutor der Antwort David Peden

In meinem Verständnis, Berufung Dispose() ist nur notwendig, wenn es das sperren von Ressourcen, die Sie später brauchen (wie eine Verbindung). Es ist immer empfohlenum freie Ressourcen, Sie sind nicht mehr mit, selbst wenn Sie nicht Sie wieder brauchst, einfach, weil Sie sollte nicht in der Regel sein festhalten an Ressourcen, die Sie nicht verwenden (Wortspiel beabsichtigt).

Dem Microsoft-Beispiel ist nicht falsch, unbedingt. Alle verwendeten Ressourcen werden freigegeben, wenn die Anwendung beendet wird. Und in dem Fall, das Beispiel, das passiert fast sofort nach der HttpClient getan wird, verwendet wird. In wie Fällen explizit aufrufen Dispose() ist etwas überflüssig.

Aber, in der Regel, wenn eine Klasse implementiert IDisposable das Verständnis ist, dass Sie sollten Dispose() seiner Instanzen, sobald Sie voll sind, die bereit und in der Lage. Ich würde behaupten dies ist insbesondere wahr in Fällen wie HttpClient wobei es nicht explizit dokumentiert ist, ob Ressourcen oder verbindungen statt auf/öffnen. In dem Fall, in dem die Verbindung wiederverwendet wird wieder [bald], Sie werden wollen, zu verzichten Dipose()ing -- Sie sind nicht "völlig fertig" in diesem Fall.

Siehe auch:
IDisposable.Dispose-Methode und Wenn beim Aufruf von Dispose

InformationsquelleAutor der Antwort svidgen

In meinem Fall, ich war die Schaffung eines HttpClient innerhalb einer Methode, die tatsächlich den service-Aufruf. So etwas wie:

public void DoServiceCall() {
  var client = new HttpClient();
  await client.PostAsync();
}

In einer Azure worker-Rolle, nach wiederholter Aufruf dieser Methode (ohne Entsorgung der HttpClient), wäre es schließlich nicht mit SocketException (Verbindung fehlgeschlagen).

Machte ich den HttpClient eine Instanz-variable (Entsorgung es auch in der Klasse) und das Problem ging Weg. Also ich würde sagen, ja, entsorgen Sie die HttpClient, vorausgesetzt, dass der safe (Sie haben keine ausstehenden asynchronen Aufrufe) zu tun.

InformationsquelleAutor der Antwort David Faivre

Wenn Sie möchten, entsorgen Sie HttpClient, können Sie, wenn Sie es als eine Ressource pool. Und am Ende der Anwendung, Sie verfügen über Ihren resource pool.

Code:

//Notice that IDisposable is not implemented here!
public interface HttpClientHandle
{
    HttpRequestHeaders DefaultRequestHeaders { get; }
    Uri BaseAddress { get; set; }
    //...
    //All the other methods from peeking at HttpClient
}

public class HttpClientHander : HttpClient, HttpClientHandle, IDisposable
{
    public static ConditionalWeakTable<Uri, HttpClientHander> _httpClientsPool;
    public static HashSet<Uri> _uris;

    static HttpClientHander()
    {
        _httpClientsPool = new ConditionalWeakTable<Uri, HttpClientHander>();
        _uris = new HashSet<Uri>();
        SetupGlobalPoolFinalizer();
    }

    private DateTime _delayFinalization = DateTime.MinValue;
    private bool _isDisposed = false;

    public static HttpClientHandle GetHttpClientHandle(Uri baseUrl)
    {
        HttpClientHander httpClient = _httpClientsPool.GetOrCreateValue(baseUrl);
        _uris.Add(baseUrl);
        httpClient._delayFinalization = DateTime.MinValue;
        httpClient.BaseAddress = baseUrl;

        return httpClient;
    }

    void IDisposable.Dispose()
    {
        _isDisposed = true;
        GC.SuppressFinalize(this);

        base.Dispose();
    }

    ~HttpClientHander()
    {
        if (_delayFinalization == DateTime.MinValue)
            _delayFinalization = DateTime.UtcNow;
        if (DateTime.UtcNow.Subtract(_delayFinalization) < base.Timeout)
            GC.ReRegisterForFinalize(this);
    }

    private static void SetupGlobalPoolFinalizer()
    {
        AppDomain.CurrentDomain.ProcessExit +=
            (sender, eventArgs) => { FinalizeGlobalPool(); };
    }

    private static void FinalizeGlobalPool()
    {
        foreach (var key in _uris)
        {
            HttpClientHander value = null;
            if (_httpClientsPool.TryGetValue(key, out value))
                try { value.Dispose(); } catch { }
        }

        _uris.Clear();
        _httpClientsPool = null;
    }
}

var handler = HttpClientHander.GetHttpClientHandle(new Uri("Basis-url")).

• HttpClient, als ein interface, kann nicht-Aufruf von Dispose().
• Dispose() wird aufgerufen, in einer verzögerten Weise durch den Garbage Collector.
  Oder wenn das Programm bereinigt das Objekt durch seine Destruktor.
• Verwendet Schwache Referenzen + verzögerte Bereinigung Logik so bleibt es in Gebrauch sind, so lange wie es wird Häufig wiederverwendet.
• Es nur reserviert einen neuen HttpClient für jede Unterseite URL an Sie übergeben. Gründe erläutert, die von Ohad Schneider Antwort unten. Schlechtes Verhalten beim ändern der Basis-url.
• HttpClientHandle ermöglicht für Spott in tests

InformationsquelleAutor der Antwort TamusJRoyce

Kurze Antwort: Nein, die Aussage in der derzeit akzeptierte Antwort ist NICHT korrekt: "Der Allgemeine Konsens ist, dass Sie nicht (sollte nicht) entsorgen müssen HttpClient".

Lange Antwort: die BEIDEN folgenden Aussagen sind wahr und achieveable zur gleichen Zeit:

1. "HttpClient soll einmal instanziiert und wiederverwendet, während der gesamten Lebensdauer einer Anwendung", zitiert aus offizielle Dokumentation.
2. Eine IDisposable Objekt soll/empfohlen entsorgt werden.

Ist und Sie NICHT NOTWENDIGERWEISE miteinander in KONFLIKT geraten. Es ist nur eine Frage, wie organisieren Sie Ihren code wiederverwenden einer HttpClient noch UND entsorgen Sie es ordnungsgemäß.

Einen noch mehr beantworten zitiert aus meinem eine andere Antwort:

Es ist kein Zufall, Leute zu sehen,
in einige blog-Beiträge Schuld, wie HttpClient 's IDisposable - Schnittstelle
macht Sie neigen dazu, verwenden Sie die using (var client = new HttpClient()) {...} Muster
und führen dann zu erschöpft socket-handler problem.

Ich glaube, dass kommt auf eine unausgesprochene (mis?)Konzeption:
"ein IDisposable-Objekt ist voraussichtlich von kurzer Dauer sein".

JEDOCH, während es sieht aus wie eine kurzlebige Sache, wenn wir code schreiben, der in diesem Stil:

using (var foo = new SomeDisposableObject())
{
    ...
}

den offizielle Dokumentation über die IDisposable -
nie erwähnt IDisposable Objekte müssen von kurzer Dauer sein.
Per definition IDisposable ist lediglich ein Mechanismus, um zu ermöglichen, die Sie zur Freigabe von nicht verwalteten Ressourcen.
Nichts mehr. In diesem Sinne, Sie sollen schließlich Auslöser der Entsorgung,
aber Sie müssen nicht, dies zu tun in einer kurzlebigen Mode.

Es ist daher Ihre Aufgabe, richtig zu wählen, wenn zum auslösen der Entsorgung,
Basis auf Ihren realen Objekt im Lebenszyklus der Anforderung.
Es gibt nichts hindert Sie mit einem IDisposable in einer langlebigen Art:

using System;
namespace HelloWorld
{
    class Hello
    {
        static void Main()
        {
            Console.WriteLine("Hello World!");

            using (var client = new HttpClient())
            {
                for (...) { ... }  //A really long loop

                //Or you may even somehow start a daemon here

            }

            //Keep the console window open in debug mode.
            Console.WriteLine("Press any key to exit.");
            Console.ReadKey();
        }
    }
}

Mit diesem neuen Verständnis, jetzt rekapitulieren wir das blog-post
wir können eindeutig feststellen, dass der "fix" initialisiert HttpClient einmal, aber nie entsorgen Sie es,
das ist, warum wir sehen können, von seiner netstat-Ausgabe,,
die Verbindung bleibt im Status ESTABLISHED was bedeutet, es wurde NICHT richtig geschlossen.
Wenn es geschlossen wäre, seinen Staat wäre in TIME_WAIT statt.
In der Praxis ist es nicht eine große Sache undicht wird nur eine Verbindung geöffnet, nachdem Sie Ihre gesamte Programm endet,
und die blog-poster immer noch einen performance-Gewinn, nach dem Update;
aber noch ist es begrifflich falsch, die Schuld IDisposable und wählen Sie NICHT entsorgen Sie es.

InformationsquelleAutor der Antwort RayLuo