¿Tienen que eliminarse HttpClient y HttpClientHandler?

Las respuestas actuales son un poco confusas y engañosas, y les faltan algunas implicaciones importantes del DNS. Trataré de resumir claramente dónde están las cosas.

1. En términos generales, la mayoría de los IDisposable objetos idealmente deberían ser eliminados cuando haya terminado con ellos, especialmente aquellos que poseen recursos de SO con nombre/compartidos. HttpClient no es una excepción, ya que como Darrel Miller señala que asigna tokens de cancelación, y los cuerpos de solicitud/respuesta pueden ser flujos no administrados.
2. Sin embargo, la práctica recomendada de para HttpClient dice que debe crear una instancia y reutilizarla tanto como sea posible (utilizando sus miembros seguros para subprocesos en escenarios multiproceso). Por lo tanto, en la mayoría de los escenarios nunca te desharás de él simplemente porque lo necesitarás todo el tiempo.
3. El problema con la reutilización del mismo HttpClient "forever" es que la conexión HTTP subyacente podría permanecer abierta contra el IP resuelta por DNS, independientemente de los cambios de DNS . Esto puede ser un problema en escenarios como implementación azul/verde y conmutación por error basada en DNS. Hay varios enfoques para hacer frente a este problema, el más confiable que implica que el servidor envíe un encabezado Connection:close después de que se produzcan cambios en el DNS. Otra posibilidad consiste en reciclar el HttpClient en el lado del cliente, ya sea periódicamente o a través de algún mecanismo que aprenda sobre el cambio de DNS. Ver https://github.com/dotnet/corefx/issues/11224 para más información (sugiero leerlo cuidadosamente antes de usar ciegamente el código sugerido en la entrada del blog enlazada).

A mi entender, llamar a Dispose() solo es necesario cuando se trata de bloquear los recursos que necesita más adelante (como una conexión en particular). Siempre es recomendadoliberar recursos que ya no estás usando, incluso si no los necesitas de nuevo, simplemente porque no deberías generalmente retener recursos que no estás usando (juego de palabras).

El ejemplo de Microsoft no es incorrecto, necesariamente. Todos los recursos utilizados se liberarán cuando se cierre la aplicación. Y en el caso de ese ejemplo, que sucede casi inmediatamente después de que el HttpClient se hace siendo utilizado. En casos similares, llamar explícitamente a Dispose() es algo superfluo.

Pero, en general, cuando una clase implementa IDisposable, el entendimiento es que debe Dispose() de sus instancias tan pronto como esté completamente listo y capaz. Yo postularía que esto es particularmente cierto en casos como HttpClient en los que no está explícitamente documentado en cuanto a si los recursos o conexiones están retenidos/abiertos. En el caso en que el la conexión será reutilizada de nuevo[pronto], querrás renunciar Dipose()a ella {no estás "completamente listo" en ese caso.

Véase también: Identificable.Método Dispose y Cuándo llamar a Dispose

Dispose() llama al siguiente código, que cierra las conexiones abiertas por la instancia HttpClient. El código fue creado descompilando con dotPeek.

HttpClientHandler.cs-Dispose

ServicePointManager.CloseConnectionGroups(this.connectionGroupName);

Si no llamas a dispose, entonces ServicePointManager.MaxServicePointIdleTime, que se ejecuta mediante un temporizador, cerrará las conexiones http. El valor predeterminado es 100 segundos.

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

Si no ha establecido el tiempo de inactividad en infinito, entonces parece seguro no hacerlo llame a dispose y deje que el temporizador de conexión inactiva se active y cierre las conexiones por usted, aunque sería mejor para usted llamar a dispose en una instrucción using si sabe que ha terminado con una instancia HttpClient y libera los recursos más rápido.

En mi caso, estaba creando un HttpClient dentro de un método que realmente hizo la llamada al servicio. Algo como:

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

En un rol de trabajo de Azure, después de llamar repetidamente a este método (sin disponer del HttpClient), eventualmente fallaría con SocketException (el intento de conexión falló).

Hice el HttpClient una variable de instancia (disponiéndolo a nivel de clase) y el problema desapareció. Así que diría, sí, deseche el HttpClient, asumiendo que es seguro (no tiene llamadas asincrónicas sobresalientes) para hacerlo.

En el uso típico (respuestas

Los tipos de retorno de los métodos HttpClient deben Eliminarse si su Contenido de flujo no se lee completamente. De lo contrario, no hay manera de que el CLR sepa que esas corrientes pueden cerrarse hasta que se recolecten basura.

• Si está leyendo los datos en un byte[] (por ejemplo, GetByteArrayAsync) o cadena, todos los datos se leen, por lo que no hay necesidad de disponer.
• Las otras sobrecargas por defecto a la lectura de la secuencia de hasta 2 GB (HttpCompletionOption es ResponseContentRead, HttpClient.El valor predeterminado de MaxResponseContentBufferSize es 2GB)

Si configura HttpCompletionOption a ResponseHeadersRead o la respuesta es mayor de 2 GB, debe limpiar. Esto se puede hacer llamando a Dispose en el HttpResponseMessage o llamando a Dispose/Close en la Secuencia obtenida del Contenido de HttpResonseMessage o leyendo el contenido completamente.

Si llama Disponer en HttpClient depende de si desea cancelar las solicitudes pendientes o no.

Si desea deshacerse de HttpClient, puede hacerlo si lo configura como un grupo de recursos. Y al final de su aplicación, usted dispone de su grupo de recursos.

Código:

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

• HttpClient, como interfaz, no puede llamar a Dispose().
• Dispose() será llamada de forma retardada por el Recolector de Basura. O cuando el programa limpia el objeto a través de su destructor.
• Usos Referencias débiles + lógica de limpieza retrasada para que permanezca en uso mientras se reutilice con frecuencia.
• Solo asigna un nuevo HttpClient para cada URL base que se le pasa. Razones explicadas por Ohad Schneider responder a continuación. Mal comportamiento al cambiar la url base.
• HttpClientHandle permite burlarse en las pruebas

El uso de la inyección de dependencias en su constructor hace que administrar la vida útil de su HttpClient sea más fácil - tomando el gestor de vida fuera del código que lo necesita y haciéndolo fácilmente cambiable en una fecha posterior.

Mi preferencia actual es crear una clase de cliente http separada que hereda de HttpClient una vez por dominio de punto final de destino y luego convertirlo en un singleton usando inyección de dependencias. public class ExampleHttpClient : HttpClient { ... }

Entonces tomo una dependencia del constructor en el cliente http personalizado en las clases de servicio donde necesito acceso a esa API. Esto resuelve el problema de la vida útil y tiene ventajas cuando se trata de la agrupación de conexiones.

Puedes ver un ejemplo trabajado en respuesta relacionada en https://stackoverflow.com/a/50238944/3140853

Respuesta corta: No, la afirmación en la respuesta actualmente aceptada NO es exacta: "El consenso general es que no necesita (no debería) deshacerse de HttpClient".

Respuesta larga: LAS dos afirmaciones siguientes son verdaderas y alcanzables al mismo tiempo:{[12]]}

1. "HttpClient está destinado a ser instanciado una vez y reutilizado durante toda la vida de una aplicación", citado de documentación oficial.
2. Un objeto IDisposable se supone / se recomienda desechar.

Y NO NECESARIAMENTE ENTRAN en CONFLICTO entre sí. Es solo una cuestión de cómo organizar su código para reutilizar un HttpClient Y aún así eliminarlo correctamente.

Un par respuesta más larga citado de mi otra respuesta :

No es una coincidencia ver a la gente in some blog posts blaming how HttpClient ' s IDisposable interface hace que tiendan a usar el patrón using (var client = new HttpClient()) {...} y luego llevar al zócalo agotado problema del manejador.

Creo que eso se reduce a un tácito (mis?)concepción: "se espera que un objeto identificable sea de corta duración".

SIN EMBARGO, aunque ciertamente parece una cosa de corta duración cuando escribimos código en este estilo:

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

La documentación oficial sobre identificable nunca menciona IDisposable los objetos tienen que ser de corta duración. Por definición, IDesposable es simplemente un mecanismo que le permite liberar recursos no administrados. Nada más. En ese sentido, se ESPERA que eventualmente desencadene la eliminación, pero no requiere que lo hagas de una manera efímera.

Por lo tanto, es su trabajo elegir correctamente cuándo activar la eliminación, base en el requisito del ciclo de vida de su objeto real. No hay nada que te impida usar un IDisposable de una manera duradera:

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

Con este nuevo entendimiento, ahora revisitamos esa publicación del blog , podemos notar claramente que el" arreglo " inicializa HttpClient una vez pero nunca lo deseches, es por eso que podemos ver en su salida netstat que, la conexión permanece en el estado ESTABLECIDO, lo que significa que NO se ha cerrado correctamente. Si estuviera cerrado, su estado estaría en TIME_WAIT en su lugar. En la práctica, no es un gran problema filtrar solo una conexión abierta después de que finalice todo el programa, y el poster del blog todavía ve una ganancia de rendimiento después de la corrección; pero aún así, es conceptualmente incorrecto culpa IDisposable y NO disponer de él.

No hay necesidad de llamar a Dispose Porque HttpClient hereda la clase HttpMessageInvoker y HttpMessageInvoker implementa la interfaz IDisposal y HttpClientHandler heredan la clase HttpMessageHandler y HttpMessageHandler implementan la interfaz IDisposal

Creo que uno debería usar el patrón singleton para evitar tener que crear instancias del HttpClient y cerrarlo todo el tiempo. Si está utilizando. Net 4.0, puede usar un código de ejemplo como se muestra a continuación. para obtener más información sobre el patrón singleton, verifique aquí.

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

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

    private HttpClientSingletonWrapper()
    {
    }
}

Utilice el código como se muestra a continuación.

var client = HttpClientSingletonWrapper.Instance;