Java 应用报错 No buffer space available 排查与解决

输出片段：

TCP 192.168.1.100:54995 203.0.113.5:8080 CLOSE_WAIT 12345
TCP 192.168.1.100:54996 203.0.113.5:8080 CLOSE_WAIT 12345
TCP 192.168.1.100:54997 203.0.113.5:8080 CLOSE_WAIT 12345
...

• 本地地址：192.168.1.100（应用服务器）
• 远程地址：203.0.113.5:8080（固定的目标服务）
• 状态：CLOSE_WAIT
• 进程 PID：12345（与 Java 应用 PID 一致）

结论：应用程序作为 TCP 客户端，向 203.0.113.5:8080 发起大量连接，但未正确关闭，导致连接堆积在 CLOSE_WAIT 状态，最终耗尽临时端口。

四、根本原因分析

当 TCP 连接被对端主动关闭后，本地会进入 CLOSE_WAIT 状态，此时应用程序必须调用 close() 释放 socket 资源。如果应用程序未关闭 socket，连接将永远停留在 CLOSE_WAIT，占用端口和句柄。

根据 netstat 信息，本应用频繁连接 203.0.113.5:8080，但代码中未正确释放连接资源。经代码审查，发现应用使用 Apache HttpClient 发送 HTTP 请求，但未关闭 CloseableHttpResponse 对象，导致底层 TCP 连接无法释放。

五、解决方案

1. 修复代码：确保资源正确关闭

错误示例（导致泄漏）

CloseableHttpClient httpClient = HttpClients.createDefault();
HttpGet request = new HttpGet("http://203.0.113.5:8080/api");
CloseableHttpResponse response = httpClient.execute(request);
// 处理响应... 但忘记关闭 response
String result = EntityUtils.toString(response.getEntity());
// 没有 response.close()

正确示例（使用 try-with-resources）

// 复用同一个 HttpClient 实例（连接池）
private static final CloseableHttpClient httpClient = HttpClients.custom()
    .setMaxConnTotal(200)
    .setMaxConnPerRoute(50)
    .build();

public String callRemoteApi() {
    HttpGet request = new HttpGet("http://203.0.113.5:8080/api");
    // 自动关闭 response
    try (CloseableHttpResponse response = httpClient.execute(request)) {
        // 必须消费响应体，否则连接无法释放
        return EntityUtils.toString(response.getEntity());
    } catch (IOException e) {
        // 异常处理
    }
}

// 应用关闭时释放连接池
public void destroy() {
    try { httpClient.close(); } catch (IOException e) { /* log error */ }
}

关键点：

• 每次 execute() 返回的 CloseableHttpResponse 必须关闭。
• 使用连接池（复用 CloseableHttpClient）减少连接创建开销。
• 确保消费响应体（如 EntityUtils.toString()），否则连接可能无法释放。

2. 调整 Windows 动态端口范围（临时缓解）

在代码修复上线前，可扩大端口范围以延缓耗尽：

netsh int ipv4 set dynamicport tcp start=1024 num=64512 

此命令将动态端口范围设为 1024~65535（共 64512 个），修改后立即生效，无需重启。

3. 缩短 TIME_WAIT 延迟（非必需，但可优化）

如果存在大量短连接，可缩短 TIME_WAIT 时长（默认 240 秒），加速端口回收。通过注册表调整：

• 打开注册表编辑器：regedit
• 定位到：HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
• 新建 DWORD（32 位）值，名称为 TcpTimedWaitDelay，数值数据输入 30（十进制），表示 30 秒。
• 重启生效。

六、验证修复效果

1. 重启应用。
2. 监控 CLOSE_WAIT 数量：

netstat -an | find /c "CLOSE_WAIT" 

应保持稳定且较低（例如几十到几百，取决于并发请求数）。 3. 监控总连接数，不应持续增长。

七、预防措施

1. 代码规范：所有网络资源（Socket、HttpResponse、数据库连接等）必须在 finally 块或 try-with-resources 中关闭。
2. 连接池化：使用连接池管理 HTTP 连接、数据库连接，避免为每个请求创建新连接。
3. 监控告警：定期检查系统 CLOSE_WAIT 数量，设置阈值告警（例如超过 1000 触发报警）。
4. 压力测试：上线前进行压力测试，观察连接数是否稳定。
5. 日志记录：在关键网络操作处添加日志，便于追踪未关闭的连接。

八、总结

本次故障源于应用程序作为 HTTP 客户端未正确关闭连接，导致海量 CLOSE_WAIT 连接堆积，最终耗尽系统临时端口。通过代码修复（确保资源释放）和连接池优化，彻底解决了问题。Windows 环境下 netstat 是排查网络问题的利器，结合进程 PID 可快速定位泄漏源。希望本文能帮助读者避免类似问题，提升应用稳定性。

附：一键复制命令 以下命令可直接复制使用：

:: 查看 TCP 连接总数
netstat -an | find /c "TCP"
:: 查看 CLOSE_WAIT 数量
netstat -an | find /c "CLOSE_WAIT"
:: 查看 CLOSE_WAIT 详细信息
netstat -ano | findstr CLOSE_WAIT
:: 扩大动态端口范围
netsh int ipv4 set dynamicport tcp start=1024 num=64512
:: 查看动态端口范围
netsh int ipv4 show dynamicport tcp