2

我正在使用 PoolingClientConnectionManager 并且我怀疑我正在泄漏连接。我有一个打印出 PoolStats 的监控线程，如下所示：

[leased: 126; pending: 0; available: 14; max: 140]
..
[leased: 140; pending: 20; available: 0; max: 140]
..
[leased: 140; pending: 10; available: 0; max: 140]

我产生的线程数与池连接数（140）相同，所以我从没想过租用+挂起>最大值。这个假设有效吗？或者这是经理保持连接的情况？我不确定这种情况下连接是否归因于“租赁”或“可用”。

我注意到的是，如果在 DNS 解析期间 HttpClient 连接中断，则可能会发生连接泄漏。在这种情况下，租用的连接不会释放回池中。是否有建议的方法来取消分配适当的资源，以便将连接正确释放回池？

提前致谢。

4

1 回答 1

2

是的，似乎很可能存在连接泄漏。但是，DNS 查找不太可能导致它。HttpClient 应该在 i/o、协议或运行时异常的情况下自动释放连接。

就资源释放而言，规则应该相当简单：只要有一个实体与响应相关联，就必须确保其内容被完全使用。HttpClient 4.2 和 HttpClient 4.3 还为特殊情况下的资源释放提供了额外的保护措施：HttpUriRequest#releaseConnection在4.2和4.3CloseableHttpResponse#close中

您还可以尝试在打开连接管理上下文日志记录的情况下运行您的应用程序，如此处所述，看看这是否可以帮助您跟踪永远不会释放底层连接的请求。

于 2013-09-07T16:21:28.680 回答