Had the same question. The other answers don't seem to address why close() is really necessary? Also, Op seemed to be struggling to figure out the preferred way to work with HttpClient, et al.
According to 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.
In addition, the relationships go as follows:
HttpClient
(interface)
implemented by:
CloseableHttpClient
- ThreadSafe.
DefaultHttpClient
- ThreadSafe BUT deprecated, use HttpClientBuilder
instead.
HttpClientBuilder
- NOT ThreadSafe, BUT creates ThreadSafe CloseableHttpClient
.
- Use to create CUSTOM
CloseableHttpClient
.
HttpClients
- NOT ThreadSafe, BUT creates ThreadSafe CloseableHttpClient
.
- Use to create DEFAULT or MINIMAL
CloseableHttpClient
.
The preferred way according to Apache:
CloseableHttpClient httpclient = HttpClients.createDefault();
The example they give does httpclient.close()
in the finally
clause, and also makes use of ResponseHandler
as well.
As an alternative, the way mkyong does it is a bit interesting, as well:
HttpClient client = HttpClientBuilder.create().build();
He doesn't show a client.close()
call but I would think it is necessary, since client
is still an instance of CloseableHttpClient
.