Apakah HttpClient dan HttpClientHandler harus dibuang di antara permintaan?

System.Net.Http.HttpClient dan System.Net.Http.HttpClientHandler di .NET Framework 4.5 mengimplementasikan IDisposable (via System.Net.Http.HttpMessageInvoker ).

The usingdokumentasi pernyataan mengatakan:

Sebagai aturan, ketika Anda menggunakan objek IDisposable, Anda harus mendeklarasikan dan membuat instance dalam pernyataan menggunakan.

Jawaban ini menggunakan pola ini:

var baseAddress = new Uri("http://example.com");
var cookieContainer = new CookieContainer();
using (var handler = new HttpClientHandler() { CookieContainer = cookieContainer })
using (var client = new HttpClient(handler) { BaseAddress = baseAddress })
{
    var content = new FormUrlEncodedContent(new[]
    {
        new KeyValuePair<string, string>("foo", "bar"),
        new KeyValuePair<string, string>("baz", "bazinga"),
    });
    cookieContainer.Add(baseAddress, new Cookie("CookieName", "cookie_value"));
    var result = client.PostAsync("/test", content).Result;
    result.EnsureSuccessStatusCode();
}

Tetapi contoh-contoh yang paling terlihat dari Microsoft tidak memanggil Dispose()secara eksplisit atau implisit. Misalnya:

• The artikel blog asli mengumumkan relase dari HttpClient.
• Dokumentasi MSDN sebenarnya untuk HttpClient.
• BingTranslateSample
• GoogleMapsSample
• WorldBankSample

Dalam komentar pengumuman , seseorang bertanya kepada karyawan Microsoft:

Setelah memeriksa sampel Anda, saya melihat bahwa Anda tidak melakukan tindakan buang pada contoh HttpClient. Saya telah menggunakan semua contoh HttpClient dengan menggunakan pernyataan pada aplikasi saya dan saya pikir itu adalah cara yang benar sejak HttpClient mengimplementasikan antarmuka IDisposable. Apakah saya di jalan yang benar?

Jawabannya adalah:

Secara umum itu benar meskipun Anda harus berhati-hati dengan "menggunakan" dan async karena mereka tidak benar-benar bercampur. Net 4, Dalam. Net 4.5 Anda dapat menggunakan "menunggu" di dalam pernyataan "menggunakan".

Btw, Anda dapat menggunakan kembali HttpClient yang sama sebanyak yang Anda suka sehingga biasanya Anda tidak akan membuat / membuangnya setiap saat.

Paragraf kedua berlebihan untuk pertanyaan ini, yang tidak peduli berapa kali Anda dapat menggunakan contoh HttpClient, tetapi tentang apakah perlu untuk membuangnya setelah Anda tidak lagi membutuhkannya.

(Pembaruan: sebenarnya paragraf kedua adalah kunci untuk jawabannya, seperti yang disediakan di bawah ini oleh @DPeden.)

Jadi pertanyaan saya adalah:

1. Apakah perlu, mengingat implementasi saat ini (.NET Framework 4.5), untuk memanggil Buang () pada instance HttpClient dan HttpClientHandler? Klarifikasi: oleh "perlu" Maksud saya jika ada konsekuensi negatif untuk tidak membuang, seperti kebocoran sumber daya atau risiko korupsi data.

2. Jika tidak perlu, apakah itu akan menjadi "praktik yang baik" karena mereka menerapkan IDisposable?

3. Jika perlu (atau disarankan), apakah kode ini yang disebutkan di atas mengimplementasikannya dengan aman (untuk .NET Framework 4.5)?

4. Jika kelas-kelas ini tidak perlu memanggil Buang (), mengapa mereka diimplementasikan sebagai IDisposable?

5. Jika mereka memerlukan, atau jika itu adalah praktik yang disarankan, apakah contoh Microsoft menyesatkan atau tidak aman?

Konsensus umum adalah bahwa Anda tidak (seharusnya tidak) perlu membuang HttpClient.

Banyak orang yang terlibat erat dalam cara kerjanya menyatakan hal ini.

Lihat posting blog Darrel Miller dan posting SO terkait: Perayapan HttpClient mengakibatkan kebocoran memori untuk referensi.

Saya juga sangat menyarankan Anda membaca bab HttpClient dari Merancang API Web Evolvable dengan ASP.NET untuk konteks tentang apa yang terjadi di bawah tenda, khususnya bagian "Siklus Hidup" yang dikutip di sini:

Meskipun HttpClient secara tidak langsung mengimplementasikan antarmuka IDisposable, penggunaan standar HttpClient adalah tidak membuangnya setelah setiap permintaan. Objek HttpClient dimaksudkan untuk hidup selama aplikasi Anda perlu membuat permintaan HTTP. Memiliki objek ada di beberapa permintaan memungkinkan tempat untuk menetapkan DefaultRequestHeaders dan mencegah Anda dari harus menentukan kembali hal-hal seperti CredentialCache dan CookieContainer pada setiap permintaan seperti yang diperlukan dengan HttpWebRequest.

Atau bahkan membuka DotPeek.

Jawaban saat ini agak membingungkan dan menyesatkan, dan mereka kehilangan beberapa implikasi DNS penting. Saya akan mencoba untuk meringkas di mana semuanya berdiri dengan jelas.

1. Secara umum, sebagian besar IDisposableobjek idealnya harus dibuang ketika Anda selesai menggunakannya , terutama yang memiliki sumber daya OS yang dinamai / dibagikan . HttpClienttidak terkecuali, karena seperti ditunjukkan oleh Darrel Miller, ia mengalokasikan token pembatalan, dan badan permintaan / respons dapat berupa aliran yang tidak dikelola.
2. Namun, praktik terbaik untuk HttpClient mengatakan Anda harus membuat satu contoh dan menggunakannya kembali sebanyak mungkin (menggunakan anggota aman thread-nya dalam skenario multi-threaded). Oleh karena itu, dalam sebagian besar skenario Anda tidak akan pernah membuangnya hanya karena Anda akan membutuhkannya setiap saat .
3. Masalah dengan menggunakan kembali HttpClient yang sama "selamanya" adalah bahwa koneksi HTTP yang mendasarinya mungkin tetap terbuka terhadap IP yang semula diselesaikan DNS, terlepas dari perubahan DNS . Ini bisa menjadi masalah dalam skenario seperti penyebaran biru / hijau dan failover berbasis DNS . Ada berbagai pendekatan untuk menangani masalah ini, yang paling dapat diandalkan yang melibatkan server mengirimkan Connection:closeheader setelah perubahan DNS terjadi. Kemungkinan lain melibatkan daur ulang HttpClientpada sisi klien, baik secara berkala atau melalui beberapa mekanisme yang mempelajari tentang perubahan DNS. Lihat https://github.com/dotnet/corefx/issues/11224 untuk informasi lebih lanjut (saya sarankan membacanya dengan seksama sebelum secara membabi buta menggunakan kode yang disarankan dalam posting blog yang ditautkan).

Dalam pemahaman saya, panggilan Dispose()hanya diperlukan ketika itu mengunci sumber daya yang Anda butuhkan nanti (seperti koneksi tertentu). Itu selalu disarankan untuk membebaskan sumber daya yang tidak lagi Anda gunakan, bahkan jika Anda tidak membutuhkannya lagi, hanya karena Anda biasanya tidak memegang sumber daya yang tidak Anda gunakan (pun intended).

Contoh Microsoft tidak salah, tentu saja. Semua sumber daya yang digunakan akan dirilis saat aplikasi keluar. Dan dalam kasus contoh itu, itu terjadi segera setelah HttpClientselesai digunakan. Dalam kasus serupa, panggilan secara eksplisit Dispose()agak berlebihan.

Tetapi, secara umum, ketika sebuah kelas mengimplementasikan IDisposable, pemahamannya adalah bahwa Anda harus Dispose()melakukan instansinya segera setelah Anda sepenuhnya siap dan mampu. Saya berpendapat ini terutama benar dalam kasus-kasus seperti di HttpClientmana tidak terdokumentasi secara eksplisit mengenai apakah sumber daya atau koneksi dipegang / dibuka. Dalam kasus di mana koneksi akan digunakan kembali [segera], Anda harus melupakannya Dipose()- Anda tidak "sepenuhnya siap" dalam kasus itu.

Lihat juga: IDisposable. Metode Buang dan Kapan menelepon Buang

Buang () panggilan kode di bawah ini, yang menutup koneksi yang dibuka oleh instance HttpClient. Kode dibuat dengan mendekompilasi dengan dotPeek.

HttpClientHandler.cs - Buang

ServicePointManager.CloseConnectionGroups(this.connectionGroupName);

Jika Anda tidak memanggil buang, maka ServicePointManager.MaxServicePointIdleTime, yang dijalankan oleh timer, akan menutup koneksi http. Standarnya adalah 100 detik.

ServicePointManager.cs

internal static readonly TimerThread.Callback s_IdleServicePointTimeoutDelegate = new TimerThread.Callback(ServicePointManager.IdleServicePointTimeoutCallback);
private static volatile TimerThread.Queue s_ServicePointIdlingQueue = TimerThread.GetOrCreateQueue(100000);

private static void IdleServicePointTimeoutCallback(TimerThread.Timer timer, int timeNoticed, object context)
{
  ServicePoint servicePoint = (ServicePoint) context;
  if (Logging.On)
    Logging.PrintInfo(Logging.Web, SR.GetString("net_log_closed_idle", (object) "ServicePoint", (object) servicePoint.GetHashCode()));
  lock (ServicePointManager.s_ServicePointTable)
    ServicePointManager.s_ServicePointTable.Remove((object) servicePoint.LookupString);
  servicePoint.ReleaseAllConnectionGroups();
}

Jika Anda belum menyetel waktu idle ke tak terbatas maka tampaknya aman untuk tidak memanggil buang dan biarkan timer koneksi idle menendang dan menutup koneksi untuk Anda, meskipun akan lebih baik bagi Anda untuk memanggil buang ke dalam pernyataan menggunakan jika Anda tahu Anda selesai dengan instance HttpClient dan membebaskan sumber daya lebih cepat.

Jawaban singkat: Tidak, pernyataan dalam jawaban yang saat ini diterima TIDAK akurat : "Konsensus umum adalah bahwa Anda tidak (seharusnya tidak) perlu membuang HttpClient".

Jawaban panjang : KEDUA pernyataan berikut ini benar dan dapat dicapai pada saat yang sama:

1. "HttpClient dimaksudkan untuk dipakai satu kali dan digunakan kembali sepanjang umur aplikasi", dikutip dari dokumentasi resmi .
2. Suatu IDisposablebenda seharusnya / direkomendasikan untuk dibuang.

Dan mereka TIDAK PERLU KONFLIK satu sama lain. Ini hanya masalah bagaimana Anda mengatur kode Anda untuk menggunakan kembali HttpClientDAN masih membuangnya dengan benar.

Bahkan jawaban lagi dikutip dari saya jawaban lain :

Ini bukan kebetulan melihat orang-orang di beberapa posting blog menyalahkan bagaimana HttpClient's IDisposableantarmuka membuat mereka cenderung menggunakan using (var client = new HttpClient()) {...}pola dan kemudian menyebabkan masalah socket handler kelelahan.

Saya percaya bahwa konsepsi tak terucap (salah?): "Sebuah objek IDisposable diharapkan berumur pendek" .

NAMUN, sementara itu terlihat seperti hal yang berumur pendek ketika kita menulis kode dengan gaya ini:

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

yang dokumentasi resmi pada IDisposable tidak pernah menyebutkan IDisposablebenda harus berumur pendek. Menurut definisi, IDisposable hanyalah sebuah mekanisme untuk memungkinkan Anda melepaskan sumber daya yang tidak dikelola. Tidak ada lagi. Dalam hal itu, Anda HARUS pada akhirnya memicu pembuangan, tetapi itu tidak mengharuskan Anda untuk melakukannya dalam waktu singkat.

Karena itu, tugas Anda adalah memilih dengan tepat kapan akan memicu pembuangan, berdasarkan kebutuhan siklus hidup objek nyata Anda. Tidak ada yang menghentikan Anda menggunakan IDisposable dengan cara yang tahan lama:

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

Dengan pemahaman baru ini, sekarang kita meninjau kembali posting blog itu , kita dapat dengan jelas melihat bahwa "perbaikan" diinisialisasi HttpClientsekali tetapi tidak pernah membuangnya, itu sebabnya kita dapat melihat dari output netstatnya bahwa, koneksi tetap pada keadaan ESTABLISHED yang berarti ia memiliki TIDAK ditutup dengan benar. Jika ditutup, kondisinya akan menjadi TIME_WAIT sebagai gantinya. Dalam praktiknya, bukan masalah besar untuk membocorkan hanya satu koneksi yang terbuka setelah seluruh program Anda berakhir, dan poster blog masih melihat peningkatan kinerja setelah perbaikan; tapi tetap saja, itu secara konsep tidak benar untuk menyalahkan IDisposable dan memilih untuk TIDAK membuangnya.

Karena belum ada yang menyebutkannya di sini, cara terbaik baru untuk mengelola HttpClient dan HttpClientHandler di .Net Core 2.1 menggunakan HttpClientFactory .

Ini memecahkan sebagian besar masalah dan gotcha yang disebutkan di atas dengan cara yang bersih dan mudah digunakan. Dari posting blog hebat Steve Gordon :

Tambahkan paket-paket berikut ke proyek .Net Core (2.1.1 atau lebih baru):

Microsoft.AspNetCore.All
Microsoft.Extensions.Http

Tambahkan ini ke Startup.cs:

services.AddHttpClient();

Suntikkan dan gunakan:

[Route("api/[controller]")]
public class ValuesController : Controller
{
    private readonly IHttpClientFactory _httpClientFactory;

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

    [HttpGet]
    public async Task<ActionResult> Get()
    {
        var client = _httpClientFactory.CreateClient();
        var result = await client.GetStringAsync("http://www.google.com");
        return Ok(result);
    }
}

Jelajahi serangkaian posting di blog Steve untuk mendapatkan lebih banyak fitur.

Dalam kasus saya, saya membuat HttpClient di dalam metode yang benar-benar melakukan panggilan layanan. Sesuatu seperti:

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

Dalam peran pekerja Azure, setelah berulang kali memanggil metode ini (tanpa membuang HttpClient), akhirnya akan gagal dengan SocketException(upaya koneksi gagal).

Saya menjadikan HttpClient sebagai variabel instan (membuangnya di tingkat kelas) dan masalah itu hilang. Jadi saya akan mengatakan, ya, buang HttpClient, dengan asumsi aman (Anda tidak memiliki panggilan async yang luar biasa) untuk melakukannya.

Dalam penggunaan umum (tanggapan <2GB) tidak perlu untuk Membuang HttpResponseMessages.

Jenis pengembalian metode HttpClient harus dibuang jika Konten Stream mereka tidak sepenuhnya dibaca. Kalau tidak, tidak ada cara bagi CLR untuk mengetahui Streaming tersebut dapat ditutup sampai mereka dikumpulkan.

• Jika Anda membaca data menjadi byte [] (mis. GetByteArrayAsync) atau string, semua data dibaca, jadi tidak perlu dibuang.
• Kelebihan lainnya akan default untuk membaca Stream hingga 2GB (HttpCompletionOption adalah ResponseContentRead, HttpClient.MaxResponseContentBufferSize default adalah 2GB)

Jika Anda mengatur HttpCompletionOption ke ResponseHeadersRead atau respons lebih besar dari 2GB, Anda harus membersihkan. Ini dapat dilakukan dengan memanggil Buang di HttpResponseMessage atau dengan menelepon Buang / Tutup di Stream yang diperoleh dari Konten HttpResonseMessage atau dengan membaca konten sepenuhnya.

Apakah Anda menelepon Buang di HttpClient tergantung pada apakah Anda ingin membatalkan permintaan yang tertunda atau tidak.

Jika Anda ingin membuang HttpClient, Anda bisa jika mengaturnya sebagai kumpulan sumber daya. Dan pada akhir aplikasi Anda, Anda membuang sumber daya Anda.

Kode:

// 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 (Uri baru ("base url")).

• HttpClient, sebagai antarmuka, tidak dapat memanggil Buang ().
• Buang () akan dipanggil secara tertunda oleh Pengumpul Sampah. Atau ketika program membersihkan objek melalui destruktornya.
• Menggunakan Referensi Lemah + logika pembersihan tertunda sehingga tetap digunakan selama sering digunakan kembali.
• Ini hanya mengalokasikan HttpClient baru untuk setiap URL basis yang diteruskan ke sana. Alasan yang dijelaskan oleh jawaban Ohad Schneider di bawah ini. Perilaku buruk saat mengubah url dasar.
• HttpClientHandle memungkinkan untuk mengejek dalam tes

Menggunakan injeksi dependensi di konstruktor Anda membuat mengelola masa pakai Anda HttpClientlebih mudah - mengambil manajer seumur hidup di luar kode yang membutuhkannya dan membuatnya mudah diubah di kemudian hari.

Preferensi saya saat ini adalah membuat kelas klien http terpisah yang mewarisi dari HttpClientsatu kali per target titik akhir domain dan kemudian menjadikannya singleton menggunakan injeksi ketergantungan.public class ExampleHttpClient : HttpClient { ... }

Lalu saya mengambil ketergantungan konstruktor pada klien http khusus di kelas layanan tempat saya membutuhkan akses ke API itu. Ini memecahkan masalah seumur hidup dan memiliki keuntungan ketika datang ke koneksi pooling.

Anda dapat melihat contoh yang berfungsi dalam jawaban terkait di https://stackoverflow.com/a/50238944/3140853

Silakan baca jawaban saya untuk pertanyaan yang sangat mirip yang diposting di bawah ini. Harus jelas bahwa Anda harus memperlakukan HttpClientinstance sebagai lajang dan digunakan kembali di seluruh permintaan.

Apa overhead untuk membuat HttpClient baru per panggilan dalam klien WebAPI?

Saya pikir kita harus menggunakan pola singleton untuk menghindari keharusan membuat instance dari HttpClient dan menutupnya sepanjang waktu. Jika Anda menggunakan .Net 4.0 Anda bisa menggunakan kode sampel seperti di bawah ini. untuk informasi lebih lanjut tentang pola singleton, periksa di sini .

class HttpClientSingletonWrapper : HttpClient
{
    private static readonly Lazy<HttpClientSingletonWrapper> Lazy= new Lazy<HttpClientSingletonWrapper>(()=>new HttpClientSingletonWrapper()); 

    public static HttpClientSingletonWrapper Instance {get { return Lazy.Value; }}

    private HttpClientSingletonWrapper()
    {
    }
}

Gunakan kode seperti di bawah ini.

var client = HttpClientSingletonWrapper.Instance;