¿Cuál es la diferencia entre CloseableHttpClient y HttpClient en la API de Apache HttpClient?

Este team de redactores ha estado horas investigando para dar solución a tu búsqueda, te dejamos la resolución por eso esperamos serte de mucha ayuda.

Solución:

• El principal punto de entrada de la API HttpClient es la interfaz HttpClient.
• La función más esencial de HttpClient es ejecutar métodos HTTP.
• La ejecución de un método HTTP implica uno o varios intercambios de solicitud HTTP/respuesta HTTP, generalmente manejados internamente por HttpClient.

---

• CloseableHttpClient es una clase abstracta que es la implementación base de HttpClient que también implementa java.io.Closeable.

• Aquí hay un ejemplo del proceso de ejecución de solicitudes en su forma más simple:

  CloseableHttpClient httpclient = HttpClients.createDefault();
  HttpGet httpget = new HttpGet("http://localhost/");
  CloseableHttpResponse response = httpclient.execute(httpget);
  try 
      //do something
   finally 
      response.close();
  

---

• Desasignación de recursos HttpClient: Cuando una instancia de CloseableHttpClient ya no es necesaria y está a punto de quedar fuera del alcance, el administrador de conexiones asociado debe cerrarse llamando al método CloseableHttpClient#close().

  CloseableHttpClient httpclient = HttpClients.createDefault();
  try 
      //do something
   finally 
      httpclient.close();
  

vea la Referencia para aprender los fundamentos.

---

@Scadge Desde Java 7, el uso de la declaración de prueba con recursos garantiza que cada recurso se cierre al final de la declaración. Se puede utilizar tanto para el cliente como para cada respuesta.

try(CloseableHttpClient httpclient = HttpClients.createDefault())

    // e.g. do this many times
    try (CloseableHttpResponse response = httpclient.execute(httpget)) 
    //do something
    

    //do something else with httpclient here

Tenía la misma pregunta. Las otras respuestas no parecen abordar por qué close() es realmente necesario. Además, Op parecía estar luchando por descubrir la forma preferida de trabajar con HttpClient, et al.

---

Según Apache:

// The underlying HTTP connection is still held by the response object
// to allow the response content to be streamed directly from the network socket.
// In order to ensure correct deallocation of system resources
// the user MUST call CloseableHttpResponse#close() from a finally clause.

Además, las relaciones son las siguientes:

HttpClient (interfaz)

Implementado por:

CloseableHttpClient – A salvo de amenazas.

DefaultHttpClient – ThreadSafe PERO en desuso, uso HttpClientBuilder en cambio.

HttpClientBuilder – NO ThreadSafe, PERO crea ThreadSafe CloseableHttpClient.

• Úselo para crear PERSONALIZADO CloseableHttpClient.

HttpClients – NO ThreadSafe, PERO crea ThreadSafe CloseableHttpClient.

• Úselo para crear DEFAULT o MINIMAL CloseableHttpClient.

La forma preferida según Apache:

CloseableHttpClient httpclient = HttpClients.createDefault();

El ejemplo que dan no httpclient.close() en el finally cláusula, y también hace uso de ResponseHandler así como.

---

Como alternativa, la forma en que mkyong lo hace también es un poco interesante:

HttpClient client = HttpClientBuilder.create().build();

Él no muestra un client.close() llamar pero creo que es necesario, ya que client sigue siendo un ejemplo de CloseableHttpClient.

Las otras respuestas no parecen abordar por qué close() es realmente necesario? * 2

Duda sobre la respuesta “desasignación de recursos HttpClient”.

Se menciona en el antiguo documento httpcomponents 3.x, que es muy antiguo y tiene mucha diferencia con 4.x HC. Además la explicación es tan breve que no dice cuál es este recurso subyacente.

Investigué un poco sobre el código fuente de la versión 4.5.2, encontré las implementaciones de CloseableHttpClient:close() básicamente solo cierra su administrador de conexión.

(FYI) Es por eso que cuando usa un compartido PoolingClientConnectionManager y llamar al cliente close()excepción java.lang.IllegalStateException: Connection pool shut down ocurrira. Para evitar, setConnectionManagerShared obras.

yo prefiero no hacer CloseableHttpClient:close() después de cada solicitud

Solía ​​​​crear una nueva instancia de cliente http al hacer la solicitud y finalmente cerrarla. En este caso, mejor no llamar. close(). Dado que, si el administrador de conexión no tiene un indicador “compartido”, se cerrará, lo cual es demasiado costoso para una sola solicitud.

De hecho, también encontré en la biblioteca clj-http, un contenedor de Clojure sobre Apache HC 4.5, no llama close() en absoluto. Ver función request en el archivo core.clj

Te mostramos las reseñas y valoraciones de los usuarios

Acuérdate de que tienes la capacidad de añadir una tasación si te fue útil.

---

---

Utiliza Nuestro Buscador