如何确保我的 HttpClient 4.1 不会泄漏套接字？

Question

我的服务器使用来自内部 Web 服务的数据根据​​每个请求构建其响应。我正在使用 Apache HttpClient 4.1 发出请求。每个初始请求将导致对 Web 服务发出大约 30 个请求。其中，4 - 8 个套接字最终会陷入 CLOSE_WAIT 状态，永远不会被释放。最终这些卡住的套接字超出了我的 ulimit，并且我的进程耗尽了文件描述符。

我不想仅仅提高我的 ulimit (1024)，因为这只会掩盖问题。

我转向 HttpClient 的原因是 java.net.HttpUrlConnection 的行为方式相同。

我尝试移动到每个请求的 SingleClientConnManager ，并在其上调用 client.getConnectionManager().shutdown() ，但套接字最终仍然卡住。

我应该尝试解决这个问题，以便在没有运行请求的情况下得到 0 个打开的套接字，还是应该专注于请求持久性和池化？

为了清楚起见，我提供了一些可能相关的详细信息：

操作系统：Ubuntu 10.10

JRE：1.6.0_22

语言：Scala 2.8

示例代码：

val cleaner = Executors.newScheduledThreadPool(1) 
private val client = {
    val ssl_ctx = SSLContext.getInstance("TLS")
    val managers = Array[TrustManager](TrustingTrustManager)
    ssl_ctx.init(null, managers, new java.security.SecureRandom())
    val sslSf = new org.apache.http.conn.ssl.SSLSocketFactory(ssl_ctx, SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER)
    val schemeRegistry = new SchemeRegistry()
    schemeRegistry.register(new Scheme("https", 443, sslSf))
    val connection = new ThreadSafeClientConnManager(schemeRegistry)
    object clean extends Runnable{ 
        override def run = {
            connection.closeExpiredConnections
            connection.closeIdleConnections(30, SECONDS)
        }
    }
    cleaner.scheduleAtFixedRate(clean,10,10,SECONDS)
    val httpClient = new DefaultHttpClient(connection)
    httpClient.getCredentialsProvider().setCredentials(new AuthScope(AuthScope.ANY), new UsernamePasswordCredentials(username,password))
    httpClient
}
val get = new HttpGet(uri)
val entity = client.execute(get).getEntity
val stream = entity.getContent
val justForTheExample = IOUtils.toString(stream)
stream.close()

测试：netstat -a | grep {myInternalWebServiceName} | grep {myInternalWebServiceName} | grep {myInternalWebServiceName} grep CLOSE_WAIT

（列出我的进程处于 CLOSE_WAIT 状态的套接字）

发表评论讨论：

此代码现在演示了正确的用法。

Answer 1

人们需要主动从连接池中逐出过期/空闲的连接，因为在阻塞 I/O 模型中，连接无法对 I/O 事件做出反应，除非正在读取/写入它们。有关详细信息，请参阅

http://hc.apache.org/ httpcomponents-client-dev/tutorial/html/connmgmt.html#d4e631

Answer 2

我已将 oleg 的答案标记为正确，因为它突出显示了有关 HttpClient 连接池的重要使用点。

不过，要回答我最初的具体问题，即“我应该尝试解决 0 个未使用的套接字还是尝试最大化池化？”

现在池解决方案已就位并正常工作，应用程序吞吐量已增加了约 150%。我将此归因于不必重新协商 SSL 和多次握手，而是根据 HTTP 1.1 重用持久连接。

按预期利用池绝对值得努力，而不是尝试在每个请求后调用 ThreadSafeClientConnManager.shutdown() 等等。另一方面，如果您调用任意主机并且没有像我一样重用路由，您可能会很容易发现有必要进行此类黑客攻击，因为 JVM 可能会令您惊讶于 CLOSE_WAIT 指定套接字的长寿命，如果你不经常收集垃圾。

Answer 3

我遇到了同样的问题，并使用此处找到的建议解决了它：此处。作者介绍了一些 TCP 基础知识：

当 TCP 连接即将关闭时，其最终确定由双方协商确定。将其视为以文明方式违反合同。双方都在文件上签字，一切顺利。用极客的话来说，这是通过 FIN/ACK 消息完成的。 A 方发送 FIN 消息以表明它想要关闭套接字。 B 方发送 ACK 表示已收到消息并正在考虑需求。然后，B 方进行清理并向 A 方发送 FIN。A 方以 ACK 进行响应，然后所有人离开。

问题来了
当B没有发送FIN时。 A有点等不及了。它有
启动其最终确定序列并正在等待另一方
做同样的事情。

然后他提到 RFC 2616, 14.10 建议设置 http 标头解决这个问题：

postMethod.addHeader("Connection", "close");

老实说，我真的不知道设置这个标头的含义。但它确实阻止了我的单元测试中发生 CLOSE_WAIT。