阿丁的猫Java 应用联调测试跑到一半，日志里突然刷出一排 No buffer space available (maximum connections reached?): connect，一开始我还没当回事，以为是对方服务挂了。结果连续几个环境都出现同样的报错，而且都是 Java 进程报出来的，这才意识到问题出在客户端，而且是操作系统层面的资源耗尽。
这个报错在 Windows 服务器上特别典型，Linux 上偶尔也会遇到。它并不是说你的 Java 代码写错了，也不是对方接口拒绝了你，而是底层 connect() 连接创建失败——操作系统已经分配不出新的网络连接所需的内存缓冲区或者端口资源了。报错文本里的 (maximum connections reached?) 其实是系统网络栈给出的提示，意思是"可能达到了最大连接数"。
这篇内容不是单纯贴一段异常日志，而是把我在排查这个报错过程中踩过的坑、确认过的原理、操作过的调优命令都整理出来。不管你用的是 Spring Boot、Netty 还是原生 Socket，只要在 Windows/Linux 上部署 Java 服务，这篇排查记录都能直接拿来参考。
1. 这个报错到底在说什么
很多开发看到 No buffer space available 第一反应是内存不足，其实这个误区很常见。"buffer space" 指的是网络协议栈用来管理连接的内存缓冲区，不是 JVM 堆内存。Java 应用发起一个 TCP 连接时，操作系统内核要为新连接分配 socket 结构体、发送/接收缓冲区，这些资源都在内核态，和堆内存在完全不同的两个池子里。
1.1 错误产生的底层过程
以 Java 客户端连接 MySQL 为例，代码执行到 DriverManager.getConnection()，JDBC 驱动会创建一个 Socket，底层调用操作系统提供的连接接口。在 Windows 上，这个过程走的是 Winsock；在 Linux 上，走的是 glibc 的 connect() 系统调用。
内核接到连接请求后要完成几件事：分配文件描述符、分配 TCP 控制块（TCB）、分配收发缓冲区内存。任何一个环节失败，都会返回错误。当错误是 ENOBUFS（对应 Windows 的 WSAENOBUFS）时，说明内核的网络资源池已经见底了。
报错文本中的 (maximum connections reached?) 是系统对错误原因的一种猜测性提示。Windows 的网络驱动在不同场景下触发 ENOBUFS 有几种可能：动态端口范围耗尽、非分页缓冲池不足、TCP 连接控制块数量达到上限。这几种情况在日志里看到的文本几乎一样，所以排查的时候不能只看错误文本，要结合系统状态来判断。
1.2 生活化类比
可以把操作系统的网络连接能力想象成一家餐厅的"翻台机制"。每个 TCP 连接就是一张餐桌，客户端的临时端口就是桌号。Java 应用每发起一个 HTTP 请求，相当于派一个客户进店，要分配一个桌号（临时端口）。请求完成后餐桌要进入"收尾清理"状态，Windows 默认清理时间约 2 到 4 分钟。
如果业务量一大，瞬间来了 16000 个客户（Windows 默认临时端口池大约是这个数），而且上一波客户还没"清理走"，新客户就没有桌号可用。这时候不是餐厅（服务器）拒绝你，而是门口的取号机（客户端操作系统）已经发不出号了。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 根因拆解：连接数、端口与 TIME_WAIT
要把这个问题彻底吃透，三个关键概念必须理清楚：临时端口范围、TIME_WAIT 状态、非分页缓冲池。这三个因素单独看都能触发报错，实际生产环境里往往是两三个叠加。
2.1 临时端口范围
每个 TCP 连接在建立时，客户端会从操作系统的动态端口范围里挑一个空闲端口作为源端口。服务器端当然也有端口消耗，但通常监听固定端口，真正海量消耗的是客户端端口。
Windows 默认动态端口范围从 49152 到 65535，总共 16384 个端口。看起来不少，但对一个高并发的 Java 网关或爬虫程序来说，瞬间开启 16000 个短连接是非常容易的。如果每个连接平均占用 30 秒，那么理论上每秒只能新开约 546 个连接（16384/30），超过这个阈值就开始报错。
Linux 上默认动态端口范围通常是 32768 到 60999，约 28232 个端口，比 Windows 宽松一些，但在极端高并发短连接场景下同样会撞墙。
查看 Windows 动态端口范围：
code复制netsh int ipv4 show dynamicport tcp
查看 Linux 动态端口范围：
code复制cat /proc/sys/net/ipv4/ip_local_port_range
2.2 TIME_WAIT 为什么是大头
TIME_WAIT 是 TCP 协议设计中的"安全守门员"。当主动关闭连接的一方在发送完最后一个 ACK 后，必须等待 2 个最大段生命周期（2MSL）才能彻底回收这个连接，防止迟到的数据包进入新建的连接里造成数据错乱。
问题在于，Java 应用如果用短连接模式，每次数据库查询、每次 HTTP 调用都建连接再关闭，那么连接关闭后端口要停留在 TIME_WAIT 状态，Windows 上是 120 秒默认值，Linux 上是 60 秒。假设你的应用平均每秒创建 100 个短连接，两分钟后就有 12000 个连接卡在 TIME_WAIT，一直占着端口不放。
这时候动态端口范围只有 16384 个，扣除正常处于 ESTABLISHED 状态的连接和少量其他状态，不到 3 分钟端口池就彻底满了。接下来再调 connect() 就会报 ENOBUFS。
查看 Windows 当前连接状态统计：
code复制netstat -ano | findstr /c:"TIME_WAIT" /c:"ESTABLISHED"
统计某个本地端口上的连接数：
code复制netstat -ano | findstr "192.168.1.100:8080" | find /c /v ""
2.3 非分页缓冲池耗尽
除了端口，还有一层限制容易被忽略——非分页缓冲池。Windows 内核为每个 TCP 连接分配的存储在非分页池中，这部分内存不能换页到磁盘。如果系统物理内存配置不当，或者机器上跑了多个高并发网络服务，非分页池耗尽时也会报 ENOBUFS。
这个情况在物理内存 4GB 以下的 Windows Server 老机器上尤其常见。Java 应用本身占了大量物理内存，留给内核的余地就小，连接一多，内核想分配缓冲区却没有连续的物理内存页可用，连接也就建不起来。
Linux 上对应的概念是内存碎片和 vm.max_map_count 之类的内核参数，但触发机制和表现有些差异。Linux 上更常见的是 "Cannot assign requested address"（端口耗尽）或 "Too many open files"（文件描述符耗尽），与 Windows 的 ENOBUFS 属于同一类问题的不同表现。
2.4 常见误区：不是真正的"连接数上限"
报错信息里的 (maximum connections reached?) 带了一个问号，说明系统自己也不确定。实际排查中发现，很多人以为是服务端 tomcat 的 maxThreads 满了，但看服务端指标完全没到上限，问题全在客户端。
服务端的连接上限指并发连接的处理能力，客户端的动态端口范围指发起连接的能力上限，这是两个不同的概念。只要理解了这一点，排查方向就不会跑偏。
3. 排查实操：一步步定位资源瓶颈
遇到报错先别急着改代码，先用系统命令确认资源状况。我习惯按"两点一线"的思路排查——先确认是不是端口耗尽，再看是不是缓冲区内存不足，最后看代码是否有连接泄漏。
3.1 第一步：确认动态端口使用率
登录到报错应用所在的服务器上，先看看端口池还有多少余量。在 Windows 上，简单粗暴的方式是用下面这段 PowerShell 统计当前 TCP 连接按状态分组：
powershell复制Get-NetTCPConnection -State * | Group-Object -Property State | Sort-Object Count -Descending | Format-Table Count, Name -AutoSize
这个命令的输出会直接告诉你当前有多少 TIME_WAIT、ESTABLISHED、CLOSE_WAIT。如果 TIME_WAIT 上万，基本确认端口紧张。
接下来看看动态端口范围还剩多少可以用：
code复制netsh int ipv4 show dynamicport tcp
已知端口池总数为 16384，当前被占用数量可以用下面的方式估算：
powershell复制(Get-NetTCPConnection).Count
对比端口池总数，如果占用数超过 13000，就需要警惕了。此时再点开任务管理器，看"性能"标签页中的非分页缓冲池数值。非分页池持续走高不回落，说明有句柄或者连接对象泄漏。
3.2 第二步：定位是哪些连接占的资源
端口耗尽时不会无差别报错，通常是某个业务模块的流量特别大。用 netstat 按本机端口分组统计，找到连接数最多的端口位：
code复制netstat -ano | awk '{print $5}' | sort | uniq -c | sort -rn | head -20
这个命令在 Linux 上按对端地址统计连接数；Windows 10/Server 2016 以上的 PowerShell 环境也可以直接跑，如果 awk 不可用就换成：
powershell复制netstat -ano | ForEach-Object { ($_ -split '\s+')[4] } | Group-Object | Sort-Object Count -Descending | Select-Object -First 20
输出结果里如果某个目标 IP:端口连接数几千上万，问题基本锁定了。我记得有一次排查发现，某个模块对 Redis 的访问没有走连接池，每个线程每次操作都新建连接，高峰时段 30 秒内开了 9000 个连接，直接把端口池干穿了。
3.3 第三步：检查代码层面的连接管理
系统命令只能告诉你"发生了什么"，还得通过代码确认"为什么发生"。检查三处：连接池配置、连接关闭逻辑、线程池大小。
数据库连接池（Druid/HikariCP）确认 maximumPoolSize 是否合理；HTTP 客户端确认开启了连接复用；最容易被忽视的是手动创建 Socket/HttpURLConnection 的地方，确认是否在 finally 或 try-with-resources 里正确关闭。
示例：一个典型的资源泄漏写法：
java复制public String callRemote(String url) {
// 没有 try-with-resources，异常时连接不关闭
HttpURLConnection conn = (HttpURLConnection) new URL(url).openConnection();
conn.setConnectTimeout(5000);
return readResponse(conn.getInputStream());
}
正确写法：
java复制public String callRemote(String url) {
try (InputStream is = new URL(url).openStream()) {
// 使用 is 后自动关闭
return readResponse(is);
} catch (IOException e) {
throw new RuntimeException("调用失败", e);
}
}
如果代码里大量出现第一种写法，连接泄漏就是必然的。这个不太好直接"看到"，需要结合 3.2 的连接数持续监控来反推。如果 netstat 统计显示 ESTABLISHED 连接数随时间只增不减，说明连接建立了但从未被回收，那基本就是代码里的连接泄漏。
3.4 Linux 上的对照排查
如果应用部署在 Linux，排查命令有所不同但思路一致：
code复制ss -s
ss -ant | awk '{print $1}' | sort | uniq -c
ss -s 会输出当前 socket 统计，ss -ant 加上 awk 统计能得到同样的状态分布。再看文件描述符使用率：
code复制cat /proc/sys/fs/file-nr
file-nr 的三个数值分别是已分配、未使用、总限额。如果第一个数接近第三个数，说明文件描述符也紧张了，这时候要修改 /etc/security/limits.conf 中的 nofile 限制。
4. 解决方案与参数调优
问题定位清楚后，解决方案就有针对性了。我按"应急处理-代码改造-系统调优"三层来给出具体操作。每层对应不同的适用场景：线上事故先应急，短期方案做代码改造，长期才动系统参数。
4.1 应急处理：先恢复服务
最快的办法其实就是等 TIME_WAIT 连接自然释放，但这在业务高峰期跟本不现实。更实操的做法是确认代码确实存在连接泄漏后，先通过重启应用的方式释放所有占用的端口。Java 进程重启后，操作系统会回收该进程持有的所有网络资源，端口池立刻恢复。我在生产环境用过这个操作，重启后报错马上消失。
这种做法只能撑几个小时，必须同时准备代码改造和系统调优，否则高峰期又会复现。
4.2 代码层面改造：连接池与复用是核心
治本的第一步是消灭短连接。Java 生态里做网络调用，要尽量复用连接。
- HttpClient 使用连接池管理器：
java复制PoolingHttpClientConnectionManager cm = new PoolingHttpClientConnectionManager();
cm.setMaxTotal(200);
cm.setDefaultMaxPerRoute(200);
CloseableHttpClient client = HttpClients.custom()
.setConnectionManager(cm)
.setConnectionTimeToLive(30, TimeUnit.SECONDS)
.build();
- RestTemplate 使用工厂模式创建，内部复用 HttpClient 连接池：
java复制@Bean
public RestTemplate restTemplate() {
HttpComponentsClientHttpRequestFactory factory = new HttpComponentsClientHttpRequestFactory();
factory.setConnectTimeout(5000);
factory.setReadTimeout(5000);
return new RestTemplate(factory);
}
这里连接池大小的设置有几个计算维度。核心公式是：连接池大小 = 目标 TPS × 单连接事务平均耗时（秒）。比如系统目标是 500 TPS，每次调用数据库平均耗时 80ms，那么连接池至少需要 500 × 0.08 = 40 个连接，再考虑峰值波动和多个线程同时取连接时的等待，实际操作时会乘一个系数（通常 2 到 3 倍），设到 100 左右。
对于系统默认的 HikariCP，配置类似：
yaml复制spring:
datasource:
hikari:
maximum-pool-size: 100
minimum-idle: 10
idle-timeout: 600000
max-lifetime: 1800000
connection-timeout: 30000
另外一个很多人忽略的低级问题——JDBC 驱动版本。老版本的 MySQL Connector/J 5.x 系列在连接关闭时如果清理资源不彻底，也容易导致 TIME_WAIT 堆积。升级到 8.x 系列后，配合 useTcpKeepAlive=true 等参数，短连接时代的 TIME_WAIT 问题会明显改善。
还有 Dubbo/gRPC 这类 RPC 框架，本身就使用长连接，一般不会遇到这个报错。如果你用的是普通 HTTP 接口在网关层做转发，那重点还是把连接池配好。
4.3 Windows 系统层调优
代码改完之后，顺手把系统参数也调一调，这样即使某个模块没走连接池，也不至于马上把端口池打爆。
Windows 上扩大临时端口范围，用管理员权限执行：
code复制netsh int ipv4 set dynamicport tcp start=1024 num=64511
这条命令把动态端口范围改为从 1024 开始，总数 64511 个，比默认的 16384 大了约 4 倍。执行后即时生效，不需要重启服务器，但会短暂中断现有 TCP 连接。生产环境变更需要选维护窗口。
缩短 TIME_WAIT 等待时间，需要改注册表。打开注册表编辑器定位到：
code复制HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
新增 DWORD 值 TcpTimedWaitDelay，数据设为 30（单位秒），这个值代表连接关闭后 TIMED_WAIT 状态的持续时间。默认无此键值时 Windows 使用 120 秒，设为 30 后端口释放速度快 4 倍，效果立竿见影。
再新增 DWORD 值 MaxUserPort，设置为 65534，允许应用使用的最大端口号。改完重启系统生效。
需要注意：TcpTimedWaitDelay 设得太小（比如低于 30 秒）在极端的网络环境下可能有数据包过期风险，但内网应用基本无感。外网生产环境我建议保守一点，设 45 秒比较平衡。
4.4 Linux 系统层调优
Linux 上的对应优化点略有不同，核心是调整内核参数。编辑 /etc/sysctl.conf：
code复制net.ipv4.ip_local_port_range = 1024 65535
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 30
tcp_tw_reuse 允许内核在 TIME_WAIT 状态下复用连接，前提是设置了时间戳。tcp_fin_timeout 控制连接进入 FIN_WAIT_2 后等待的时间。执行 sysctl -p 生效。
补充一下，还有文件描述符上限的问题。高并发下 Java 进程打开的 socket 文件描述符很容易超过 Linux 默认的 1024 限制，报 "Too many open files"。修改 /etc/security/limits.conf ：
code复制* soft nofile 65535
* hard nofile 65535
然后确认 JVM 启动参数里没有主动调低这个限制。如果你用 systemd 管理服务进程，还要在 service 文件里加：
code复制LimitNOFILE=65535
4.5 JVM 层面可调的地方
不少人在这个报错出现后第一时间想到加大 JVM 堆内存 -Xmx，这其实是驴头不对马嘴。JVM 堆内存和内核网络缓冲区是两套资源池，加大堆内存反而可能压缩内核可用的物理内存空间，让问题更严重。
JVM 层面真正值得关注的是 NIO 相关参数：-Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.WindowsSelectorProviderImpl 这类选择器配置一般不常用，但对 Netty 应用会有影响。
如果你用的是 Netty，需要关注 io.netty.maxThreads 和 io.netty.availableProcessors 以及 boss/worker 线程数配置。这些参数不会直接导致 ENOBUFS，但会通过并发能力间接影响瞬时连接数，配置得当能削峰。
Spring Boot 内置 Tomcat 配置方面，server.tomcat.max-connections 默认 8192，accept-count 默认 100，max-threads 默认 200。如果外部流量打进来导致服务端连接骤增，这个值也需要配合调整，虽然本问题更像客户端报错，但如果这道题发生在一个反向代理/网关服务上，Tomcat 的 max-connections 反而是瓶颈所在。
5. 从架构层面预防：别等报错才想起来看资源
系统调优和代码连接池是解决问题的最后一公里，但在架构设计层面如果提前规划好，这个报错根本不会出现在生产日志里。
5.1 连接数监控与告警
最关键的一步是建好连接数监控。Windows 环境下用性能监视器（perfmon）跟踪以下计数器：
- TCP 连接数中的 "Established" 计数
- "IPv4 数据报/秒"
- 非分页池字节数
或者写一个简单的批处理脚本，定时把 netstat 统计结果追加到日志文件：
batch复制@echo off
:loop
netstat -ano | find /c "ESTABLISHED" >> conn_est.log
time /t >> conn_est.log
timeout /t 60 /nobreak > nul
goto loop
稍微正式一点的方式是接入 Prometheus + Grafana。Windows 上用 windows_exporter 采集，Linux 上用 node_exporter，JMX exporter 负责 JVM 层指标，网络指标通过 node_network_* 系列采集。TCP 连接数、TIME_WAIT 数量、动态端口剩余量这些指标直接画在 Grafana Dashboard 上，阈值超过 70% 时告警，留足处理时间，不会等到端口池清零才被一脸懵地叫起来。
5.2 压测阶段就要验证连接复用
接这个报错的人很多是在压测阶段发现的，这其实是好事。压测脚本跑到一半报 ENOBUFS，说明一定要检查压测工具本身是不是在持续创建新连接。比如 JMeter 如果不启用 keep-alive，每个请求都会新建 TCP 连接，压测机的端口池先被打爆，服务端资源还远没到瓶颈。
JMeter 的 HTTP 采样器默认在 "HTTP 请求默认值" 里有 "keep-alive" 选项，打勾启用即可。压测 JDBC 时，连接池的 maximumPoolSize 也要和实际压测并发线程数匹配。如果压测并发 500，连接池只有 50，压测结果会严重失真。
5.3 短连接转长连接：架构层面的治本策略
如果你的业务是高频 API 调用，且每次都走 HTTP 短连接（请求结束后立即关闭），那么迟早会被这个报错缠上。上策是把 HTTP 调用模式从"每次新建连接"改成"连接池复用"。中策是换用支持多路复用的协议（比如 gRPC over HTTP/2），一份连接可以承载多个并发请求，从根上减少连接数量。下策才是把动态端口范围调到最大——这样治标不治本，端口终归有限，只是把爆炸时间点延后了。
我会优先推动前两种架构层面的改造。以 gRPC 为例，Netty 通道天生支持连接复用，单个 TCP 连接可以承载成千上万个请求，实际生产中用 gRPC 之后，TIME_WAIT 数量直接降到原来的几十分之一。
5.4 配置管理：让调优参数持久化
系统调优参数修改完毕之后，一定要固化到配置管理工具里，避免服务器重启后参数被恢复。Windows 注册表修改最好导出 .reg 文件放仓库里；Linux 的 sysctl.conf 变更要纳入版本管理；JVM 启动参数统一写入应用部署脚本。
我在团队内部推进过一个项目：所有需要调系统的服务都必须附上"调优变更记录"，内容包括修改项、修改前值、修改后值、变更原因、影响范围。这个习惯帮我们在服务器重启后快速恢复环境，不用每次排查问题都重新翻一遍旧命令。
6. 常见问题速查表与避坑补充
把这个报错从出现到解决的过程完整走一遍之后，最后整理一版常见问题速查表和几个容易踩的坑，方便你排查时对照。
| 症状 | 直接原因 | 排查命令 | 解决方向 |
|---|---|---|---|
| Java 报 No buffer space available | 动态端口耗尽 / TIME_WAIT 堆积 | netstat 统计 TIME_WAIT 数量 | 缩短 TcpTimedWaitDelay、扩大端口池 |
| 非 Windows 环境报 Address already in use | TIME_WAIT 端口占用 | ss -ant 查看 TIME_WAIT | tcp_tw_reuse、tcp_fin_timeout |
| 连接数随时间只增不减 | 代码连接泄漏 | 对比 ESTABLISHED 曲线 | 修复 try-with-resources 或连接池 |
| 容器环境里同样报错 | NAT 表端口耗尽 | 宿主机 conntrack 统计 | 扩大 net.netfilter.nf_conntrack_max |
| 提示内存不足但物理内存充足 | 非分页缓冲池不足 | 任务管理器查看非分页池 | 升级内存或排查句柄泄漏 |
再补充几个实际排查过程中容易被忽略的点。
第一，Windows 的防病毒软件对网络连接有过滤机制。某些企业版安全软件会拦截 TCP 连接并占用额外缓冲区资源。如果调完所有参数依然偶尔报错，可以临时卸载或停用安全软件做 AB 测试，确认是否为第三方防火墙造成。
第二，容器化部署时需要注意，Docker Desktop 在 Windows 上运行 Linux 容器，NAT 网络的端口映射有独立限额，宿主机动态端口耗尽不等于容器内端口耗尽。我遇到过容器内 Java 应用报错，但登进去看 ip_local_port_range 还很宽裕，实际是宿主机侧 conntrack 表满了。这种情况要跑到宿主机上去调整，不能只盯着容器内部。
第三，JDK 版本差异也会影响表面现象。JDK 8 和 JDK 17 在相同的资源限制下报错方式可能不同，JDK 11+ 对 NIO 的错误处理更友好，但底层资源占用规则没变，切换 JDK 版本不是解决方案。我在生产环境做过对比测试，同样代码在 JDK 8 上报 ENOBUFS，换到 JDK 17 后报错变成了 "IOException: 无法从套接字读取更多数据"——错误名不同，本质还是一个，不要被误导。
第四，数据库连接池参数配置要合理。HikariCP 的 maximumPoolSize 并不是越大越好，超过一定值后由于数据库连接数有限，反而会因为竞争加剧导致等待，而且连接数的增加直接对应 OS 资源消耗。对于 PostgreSQL 官方推荐的计算公式是：连接数 = 核心数 × 2 + 有效磁盘数量。MySQL 则要根据业务类型确认，常规经验是 50 到 200 之间，过大只会加快端口与内存消耗。
第五，不要只在应用层打日志。这类资源耗尽问题的根因往往在操作系统层，光看 Java 堆栈调用链是不够的，必须结合系统命令收集的现场数据。建议在部署脚本里预置一套"网络诊断一键脚本"，把 netstat 状态分布、动态端口范围、非分页池数值、文件描述符使用情况一次性输出，问题出现时直接甩出这份报告，省去反复登录服务器敲命令的功夫。
我在实际项目里看过一个典型的案例：某金融客户的支付网关用了 HTTP 短连接调用外部服务，高峰期请求量 3000 TPS，每笔交易 3 个外部调用，换算下来每秒要新建约 9000 个连接，默认的 16384 个动态端口在 10 秒内就被占光了。最终解决方案是三步走：外部调用统一走连接池（占比 90%），操作系统临时端口范围调大（兜底 10% 未覆盖的极端流量），再加上监控图表把 TIME_WAIT 数量控制在 2000 以下。这个组合拳上线后，再也没收到过类似的报错。
最后再分享一个调优小技巧：在 Windows 服务器上修改完动态端口范围之后，可以用一个简单的 Java 程序直接验证剩余可用端口数：
java复制import java.io.IOException;
import java.net.ServerSocket;
public class PortChecker {
public static void main(String[] args) throws IOException {
int count = 0;
for (int port = 1024; port <= 65535; port++) {
try (ServerSocket ignored = new ServerSocket(port)) {
count++;
} catch (IOException e) {
// 端口已被占用，跳过
}
}
System.out.println("当前剩余可用端口: " + count);
}
}
注意这个程序本身会占用端口，验证完后进程立即退出，端口也会被释放，不影响后续运行。在压测环境里跑一下这个程序，能直观地看到你配置的端口池还有多少余量，比对着公式估算要准确得多。
这个报错从出现到彻底解决，我在多个环境里前后折腾了一周时间，中间走偏过方向（一度以为是 DNS 问题，其实完全无关），也踩过坑（直接改注册表导致系统网络短暂中断）。整理出来的核心结论就一句话：Java 应用报这个错，优先检查客户端的端口池和 TIME_WAIT 堆积，而不是服务端连接上限。 沿着这个思路走，大概率半天内能给出解决方案。