流浪小鱼凌晨两点，监控大屏突然飘红，线上 Java 服务批量报错，日志里刷满了同一行异常：
text复制java.net.SocketException: No buffer space available (maximum connections reached?): connect
如果你在 Windows Server 上跑过 Tomcat、Spring Boot 或者微服务，大概率见过这个报错。第一次遇到时很容易慌，因为这行字既不像业务异常，也不是常见的连接超时，而是带着一个让人摸不着头脑的问句——maximum connections reached? 连错误信息自己都在猜。
这个报错的核心问题不在 Java 代码，而在操作系统底层的网络协议栈。Windows 上每个进程发起 TCP 连接时，系统都会从动态端口范围里分配一个临时端口，用完要等一段时间才能复用。当短连接请求量猛增、端口回收速度跟不上分配速度时，就会出现这种“缓冲区不足”的假象。说白了就是：Windows 这个网络调度员手上临时端口不够发了，于是 Java 应用创建 Socket 时报错。
这篇文章会带你搞清楚这个报错背后的完整链路，从错误本质到排查命令，从我实际改过的注册表参数到代码层面的连接池优化，全部摊开讲。适合正在被这个报错折磨的 Java 后端开发、SRE 运维，以及那些在 Windows 上跑测试环境但压测一上去就崩的团队。
1. 先弄明白这个报错到底在说什么
1.1 错误 ID 为 10055：不是 Java 的锅，是 Windows 网络栈在喊“没货了”
Java 抛出 SocketException: No buffer space available，对应的 Windows Winsock 错误码是 10055，官方解释是“由于系统缺少足够的缓冲区空间或其他队列，请求的套接字操作失败”。听起来很底层，但实际触发原因大部分时候只有一个：TCP 临时端口被耗尽。
Windows 为了区分同一个本机进程发的不同 TCP 连接，每个连接要占用一个唯一的四元组组合，其中源端口就是那个临时端口。打开命令行执行：
powershell复制netsh int ipv4 show dynamicport tcp
你会看到默认输出类似这样：
text复制Protocol tcp Dynamic Port Range
---------------------------------
Start Port : 49152
Number of Ports : 16384
意思是从 49152 到 65535，一共 16384 个动态端口可供应用使用。听上去不少对吧？但如果你的服务用短连接模式大量访问外部接口，每个请求都新建连接、用完就关，那么每次关闭连接后，这个端口会进入 TIME_WAIT 状态，默认要等 240 秒（4 分钟）才能重新分配。
算一笔账：假设单机压测 QPS 是 500，每个请求一个短连接，4 分钟内会产生 500 × 240 = 120000 个 TIME_WAIT 连接，远超 16384。此时新连接再想找端口，系统只能回答“没有可用缓冲区空间”，Java 拿到这个错误后原样打印出来。所谓“maximum connections reached?”，实际是“临时端口分配到达上限”。
1.2 用酒店订房的逻辑理解 TIME_WAIT 和端口复用
你可以把 Windows 的 TCP 临时端口想象成一家拥有 16384 个房间的酒店。客人（网络连接）入住时领一把钥匙（临时端口），退房（断开连接）后，房间不能马上给下一位客人入住，因为保洁阿姨需要时间打扫并确认客人物品没有遗留——这个打扫期就是 TIME_WAIT，默认 240 秒。
酒店本身住满 16384 人没有关系，那是并发连接数。真正的问题是退房后那 240 秒的打扫期里，房间被锁住了。如果每秒入住 500 人，打扫期 4 分钟，那么同时处于“锁房待清理”状态的房间会达到 12 万间，远超过酒店房间总数。于是前台只能对下一位客人的入住要求回复：没房间了。
理解了这个模型，你就知道解决方向其实就两条路：要么增加酒店房间数（扩大动态端口范围），要么缩短打扫时间（减少 TIME_WAIT 保留时长）。两条路在 Windows 上都能做，但细节和副作用不一样，第二节和第三节会分别讲。
还有一个容易踩的认知误区：有人看到 No buffer space available 以为是内存不足，直接给服务器加内存，结果毫无用处。这个问题和物理内存关系不大，真实瓶颈在 TCP 协议栈的连接跟踪表和定时器列表，这些表项受端口数量、TIME_WAIT 数量和注册表参数共同限制。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 别急着改参数，先做一套标准排查动作
2.1 四步确认法：从全局到局部，定位真正被耗尽的对象
遇到这个报错，第一反应不要是改注册表，而是先确认问题确实出在端口耗尽上，否则改了也白改。我的标准排查流程是：
第一步，看报错上下文。如果异常出现在连接外部数据库、调用外部 HTTP 接口、或者连接 Redis/MQ 时，且异常前面往往跟着一系列 connect 字样，基本锁定是出方向连接创建失败。
第二步，统计当前 TCP 连接状态分布。在服务器上新开一个管理员命令行，执行：
powershell复制netstat -ano | find /c "TIME_WAIT"
如果返回值是几万甚至十几万，说明问题已经非常明显。还可以用 PowerShell 按状态分组统计：
powershell复制netstat -ano | Select-String "^TCP" | ForEach-Object { ($_ -split '\s+')[3] } | Group-Object | Sort-Object Count -Descending
正常状态分布应该是：ESTABLISHED 是当前健康的活跃连接，TIME_WAIT 越多说明短连接越多。如果 TIME_WAIT 数量超过动态端口总数的一半，后续大量新连接必然开始报错。
第三步，确认动态端口当前剩余空间。Windows 没有直接命令显示“当前还剩多少端口”，但可以通过对比估算。先看动态端口范围大小，再统计 TIME_WAIT + CLOSE_WAIT + ESTABLISHED 的总量，两者相减就是当前紧缺程度。如果端口范围 16384 而 TIME_WAIT 已经 15000+，那答案已经揭晓。
第四步，也是很容易漏的一步：翻系统事件日志。打开事件查看器，在 Windows 日志 - 系统 下，如果能看到事件 ID 4227（TCP/IP 连接失败）或 4231，基本可以实锤 TCP 端口耗尽。这些日志会给具体进程名和 PID，能帮你进一步确定是 Java 进程还是别的服务在疯狂建连。
2.2 分清出方向耗尽与入方向耗尽，还有连接池未释放这个隐性因素
TCP 连接耗尽要区分方向。大多数情况下我们遇到的是出方向端口耗尽——也就是本机作为客户端去 connect 外部服务，此时本机随机占用一个动态端口。但还有一种情况：Java 应用作为服务器，外部刷入大量短连接，本机作为被动接受方，此时占用的其实是监听端口的连接表项，报错多为 accept 阶段的问题，而不是 connect 阶段。
所以看到报错里的 : connect 字样，要先判断这段代码是发起方。比如用 RestTemplate、HttpClient、Jedis、原生 Socket、数据库 JDBC 驱动去连别人，都属于出方向连接。
还有一个隐蔽场景：应用连接池大小配置不合理。很多框架默认线程池和连接池的上限是几十，不会撑爆端口。真正的风险点在那些未正确关闭的 IO 流和 Socket。我排查过的一个现场，是因为 HttpClient 发请求后没有 release connection，每个请求泄漏一个 Socket，连接进入 CLOSE_WAIT 后既不消失也不复用，最终占满所有可用端口。这时你看到的 TIME_WAIT 可能不多，但 CLOSE_WAIT 数量异常多。
提示：如果 netstat 统计结果里 CLOSE_WAIT 数量占比异常，优先查代码里的资源释放问题，而不是调操作系统参数。改完注册表也不可能回收泄漏的连接。
2.3 用一条命令快速把 Java 进程和占用端口量关联起来
定位到端口耗尽后，还需要快速知道是不是自己的 Java 进程干的。用下面这条 PowerShell 把所有 TCP 连接按 PID 汇总：
powershell复制netstat -ano | Select-String "^TCP" | ForEach-Object { $parts = ($_ -split '\s+'); [PSCustomObject]@{ PID = $parts[-1]; State = $parts[3] } } | Group-Object PID | ForEach-Object { [PSCustomObject]@{ PID = $_.Name; ProcessName = (Get-Process -Id $_.Name -ErrorAction SilentlyContinue).ProcessName; Count = $_.Count } } | Sort-Object Count -Descending | Select-Object -First 10
执行完可以看到 PID、进程名和连接数量排行。如果排在第一位的就是你的 Java 服务，且连接数高达几万，那么代码层面的短连接风暴就是主因。这里也能顺便对比一下 JVM 的线程数，用 jstack 导出线程快照，看看是否存在大量线程同时执行 connect 操作。
3. 实操：两大类七种解法，我验证过的方案全在这里
3.1 方案 A：扩大动态端口范围（热生效，即时缓解）
既然默认只有 16384 个动态端口，最直接的办法就是扩大范围。Windows 允许把动态端口范围扩到 1025 到 65535 之间，也就是 64510 个端口，直接翻了近 4 倍。管理员权限命令行执行：
powershell复制netsh int ipv4 set dynamicport tcp start=1025 num=64510
netsh int ipv6 set dynamicport tcp start=1025 num=64510
注意两件事：start 不能低于 1025，因为 1024 以下是保留端口；num 可以按实际调整，比如 num=60000。这个操作是动态生效的，不需要重启系统，但已经在运行的存量连接不受影响，新发起的连接才会用到新端口范围。
执行后再用前面的命令验证：
powershell复制netsh int ipv4 show dynamicport tcp
输出会变成：
text复制Start Port : 1025
Number of Ports : 64510
这个方案是我在大促压测期间用得最多的“救火手段”，因为它不需要改动代码、不需要重启服务、立刻就能缓解端口不够的问题。但注意，它只解决了端口数量上限，没有解决 TIME_WAIT 堆积本身。4 分钟内冲到 6 万个 TIME_WAIT 的服务，扩大端口后可能只是把“崩溃时间”从 1 小时推迟到 3 小时，治标不治本。所以救火之后一定要接着做 3.2 和第三节里的代码优化。
另一件小事：如果你装了 Docker Desktop for Windows，它会创建一张虚拟网卡并占用一些端口，偶尔会影响动态端口范围变化。改完动态端口后如果 Docker 连接异常，重启一下 Docker 服务就好。这个报错在热词里频繁出现“failed to connect to the docker api at npipe:////./pipe/docker_engine”，本质上是 Docker 客户端连不上引擎的守护进程，和本文的端口耗尽不是同一个问题，但要注意不要混淆排查方向。
3.2 方案 B：缩短 TIME_WAIT 保留时长（修改注册表，需重启）
这是第二板斧，目的是让端口更快进入可复用状态。TIME_WAIT 的保持时间由注册表项 TcpTimedWaitDelay 控制，默认值是 240 秒，单位是秒。把它改成 30 到 60 秒，可以让端口回收速度提升 4 到 8 倍。
在注册表编辑器（regedit）里定位：
text复制HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
新建一个 DWORD 值，名称 TcpTimedWaitDelay，数据类型选十进制，填入 30 或 60。修改后必须重启操作系统才能生效，这也是为什么建议先做 3.1 的 netsh 调整做“救火”，再挑维护窗口做这个改动。
改这个值有没有风险？有。TCP 协议的 TIME_WAIT 设计初衷是防止旧连接的延迟数据包干扰新连接。如果保留时间过短，个别极端情况下可能出现旧连接的残留报文被当成新连接数据，触发偶发性的数据错乱或连接重置。所以我不建议低于 30 秒，网络质量较差的公网环境更不要低于 60 秒。
还有一个配套参数 TcpMaxDataRetransmissions，控制 TCP 数据包重传次数，默认值 5。如果连接的瞬间网络抖动，重传次数太少会提前判定失败并释放端口，导致应用侧看到更多瞬时错误；太多则会加长连接失败探测时间。一般保持默认就好，不用动。
3.3 方案 C：修改 MaxUserPort 与 TcpNumConnections（老系统上的补充项）
老一点的 Windows Server 版本上，还需要检查 MaxUserPort 这个注册表项，它直接控制单个进程最多可用的用户端口上限。默认未设置时取动态端口范围值，但某些安全加固过的服务器上可能被设得很小。同样在 Tcpip\Parameters 下新建 DWORD，名称 MaxUserPort，填十进制 65534。
还有一个 TcpNumConnections，控制整个系统可以同时建立的 TCP 连接总数上限，默认 16777214，一般不用改。只有当报错同时伴随事件 ID 4226（TCP/IP 连接尝试次数过多）时才需要关注。这个事件通常和防火墙、第三方安全软件限流有关，跟端口耗尽没有直接关系。
提示：改完注册表后，建议分两次重启。第一次重启后观察动态端口分配与连接状态，不要马上把 TcpTimedWaitDelay 改到极端值。我见过有人直接把 TIME_WAIT 改成 0，排障了一个星期才定位到一个 TCP 互通偶发错乱的问题，最后把值调回 30 秒才稳定下来。
3.4 方案 D：优先出方向的连接池化与连接复用改造
如果说前三个方案是给系统“扩容”，那代码层面的优化就是“减负”。能不做短连接就不做短连接，这是治本之道。
Java 里最典型的短连接场景就是用原生 Socket 直接 connect，用法正确但没走连接池。以 HttpClient 为例，应该用连接池管理器代替手动创建 Client：
java复制PoolingHttpClientConnectionManager manager = PoolingHttpClientConnectionManagerBuilder.create()
.setMaxConnTotal(200)
.setMaxConnPerRoute(200)
.build();
CloseableHttpClient client = HttpClients.custom()
.setConnectionManager(manager)
.setConnectionManagerShared(true)
.evictExpiredConnections()
.evictIdleConnections(60, TimeUnit.SECONDS)
.build();
几个参数是配套的：setMaxConnTotal 控制整个客户端最多多少个连接，setMaxConnPerRoute 控制到单个目标地址的连接数上限。这两个值不宜拍脑袋，要根据压测结果观察平均同时并发数来定。200 是一个比较稳妥的起步值，如果目标服务能力足够，可以放宽到 500，但连接太多也会增加服务端压力。
对数据库连接池来说，最需要在意的三个参数是 maximumPoolSize、minimumIdle 和 connectionTimeout。很多事故背后是 maximumPoolSize 设置到 500 但服务端 MySQL 的 max_connections 只有 300，等于一部分连接一直在排队失败，报的错却不是端口耗尽而是连接超时。这里提醒一点：排查“No buffer space available”时，一定要同时看本机到数据库之间的连接数、数据库侧的连接数和 JDBC 驱动抛出的是 SocketException 还是 SQLTransientConnectionException，这两类错对应两个完全不同的排障路径。
还有一类设计上的优化：把一次性请求合并成批量请求，或者把同步调用改成异步批处理。比如原来 1 秒内发 100 个独立 HTTP 请求，改成 batch 接口一次收 100 个数据点，连接数能从 100 降到 1。这套思路对冲端口压力的效果是最明显的，但需要上游接口配合。
Timeout 参数也很关键。connectTimeout 如果设成 30 秒，当服务端负载高时，连接会一直挂在 SYN_SENT 状态，占着端口不释放。实践中建议把出方向的 connectTimeout 压到 3 到 5 秒，读超时根据业务容忍度单独设置，避免一堆半开连接堆积。
3.5 方案 E：服务网格和网关层的优雅降级，避免瞬时连接风暴打垮下游
微服务架构里还有一种常见场景：本服务同时连接多个下游服务，比如用户中心、订单中心、消息中心。当其中一个下游发生抖动，调用方会重试三次，重试又叠加一轮新的短连接。如果每个下游都默认用短连接且重试策略是盲目重试，那么瞬时连接风暴会在几分钟内把本机和下游打成端口耗尽。
解决思路是给每个下游单独建连接池，而不是共用一个大的连接池。单独建池的好处是隔离故障——A 下游挂了，它的重试风暴只会打满 A 的池子，不会把 B、C 的可用连接也占掉。
网关层还可以加一个简单的并发令牌桶，限制单秒内发往某个下游的最大连接建立数。令牌桶算法在 Java 里可以用 Guava 的 RateLimiter 或 Resillience4j 的 Bulkhead 实现。这个保护措施不复杂，但效果极其明显，亲测能把 TimeoutException 和端口耗尽同时压下来。
3.6 方案 F：确认不是 Windows 防火墙与 NAT 场景叠加
有一种容易被遗漏的情况：服务器的网卡启用了网络安全过滤，或者上面跑着第三方安全软件，它们会默默限制 TCP 连接创建速率。报错之后的系统日志里如果同时出现大量 filtered 状态，要先把安全软件排除掉再谈调参。
更隐蔽的是 NAT 环境。如果应用通过 NAT 网关访问公网，那么端口耗尽可能不出现在应用服务器上，而是出现在 NAT 网关上。每一条 TCP 映射都要占 NAT 表的一项，这个表容量比操作系统的动态端口数还小。典型表现是应用服务器 netstat 完全正常，TIME_WAIT 才几千个，但外部连接就是建不起来。遇到这种场景，看谁的网络路径上有 NAT，就在那一层查它的连接表。我调过一个客户现场的问题，最后发现是公司出口防火墙的 NAT 表项满了，跟应用服务器完全无关。
3.7 方案 G：引入监控与告警，让端口耗尽死在前头
最后这点虽然不是直接排障手段，但我强烈建议加到每一台 Windows 应用服务器上。用 PowerShell 脚本把 netstat 连接状态分布定时拉出来，写入本地日志或推送到监控系统，把 TIME_WAIT 数量、动态端口剩余量作为指标配置告警：
powershell复制while ($true) {
$timeWait = (netstat -ano | Select-String "TIME_WAIT").Count
$est = (netstat -ano | Select-String "ESTABLISHED").Count
("{0} TIME_WAIT={1} ESTABLISHED={2}" -f (Get-Date -Format "yyyy-MM-dd HH:mm:ss"), $timeWait, $est) | Out-File -FilePath D:\tcp_monitor.log -Append -Encoding utf8
Start-Sleep -Seconds 30
}
实测下来，当 TIME_WAIT 数量超过动态端口总量 70% 时，提前写告警规则，基本能在服务崩掉之前 10 到 20 分钟收到提醒。这个时间窗口足够你执行第一部分 netsh 命令救火，也足够你通知团队准备代码修复。爬坑爬多了你就会明白，这种底层的系统资源问题，靠人盯日志是不可持续的，必须交给监控。
4. 常见问题与排查技巧实录（含一套速查表）
4.1 报错只出现在某台机器，集群其他机器正常，为什么
最常见的原因是数量不对称。比如 Nginx 负载均衡后面挂了 5 台应用，其中一台机器既要处理流量，又要额外承担某种定时任务，比如每日凌晨批量同步数据。定时任务一跑起来，这台机器就会叠加到接近阈值的连接数量上，其他机器流量相同却没有额外任务，自然不报错。
遇到这种情况不要慌着调全部机器的配置，先在出问题的机器上确认定时任务时间窗口与报错起始时间是否重合。用 jstack 的 dump 可以看到定时任务线程的 socket 调用路径，再用第一节的方法确认连接总量，就能把问题范围缩小到一个任务线程。我处理过一个案例，最后定位是凌晨的报表导出的 SQL 做全表扫描，单线程慢查询导致连接池占满，牵连了正常请求。
4.2 从 Java 进程视角怎么确认连接在哪个代码路径被创建
这是最多人问的：报错日志只给我一个 SocketException 的堆栈，怎么知道是哪个模块创建的连接？
如果堆栈里能直接看到 org.apache.http.impl.conn.PoolingHttpClientConnectionManager 或 java.net.Socket.connect，说明是出方向的 HTTP 调用。但很多时候堆栈被框架包装了一层，显示为 Caused by: java.net.SocketException 只有一行。
我的经验是：先看日志里出现这个异常之前的完整上下文。如果是数据库操作前后爆出来的，十有八九是连接池管理的连接不够用；如果是往外部接口发请求前后爆出来的，就是对外调用链路的连接池或端口问题。再配合 netstat -ano | findstr <JavaPID> 看当前进程连接的外部地址端口分布，基本可以锁定是全部上游还是某一个上游占大头。
一个实操技巧：把 netstat 输出按远程端口聚合一下，如果排行第一的远程端口对应 3306（MySQL）或 6379（Redis），则说明数据库连接占大头；如果对应一堆 8080 或 443，则是外部接口调用占大头。这个数据能帮你决定优先优化哪个模块的池化策略。
4.3 常见问题速查表
| 现场特征 | 初步定位 | 推荐处理顺序 |
|---|---|---|
| TIME_WAIT 高达数万，错误在出方向 connect 阶段 | TCP 动态端口耗尽 | 先扩端口救火，再缩 TIME_WAIT，最后做连接池改造 |
| CLOSE_WAIT 大量堆积 | 应用未正确关闭 Socket 或连接池泄漏 | 检查 IO 流释放逻辑、HttpClient releaseConnection、JDBC 连接归还 |
| SYN_SENT 大量堆积 | 目标服务负载高或网络不可达 | 检查目标服务健康状态，优化 connectTimeout，增加重试退避 |
| netstat 连接量正常，但外部连接失败 | NAT 网关表项满，或安全软件/防火墙限流 | 检查 NAT 映射数、安全软件连接限制策略 |
| Java 服务刚重启即复现 | 端口处于系统服务占用或显式配置了限流 | 确认 Java 监听端口绑定是否冲突，检查 JDK 自带连接缓存参数 |
| 多个下游同时调用时才报错 | 每个下游连接数叠加，总量超出端口阈值 | 改为每下游独立连接池，加并发令牌桶保护 |
4.4 调完参数后必须做的验证动作
改完端口范围和 TIME_WAIT，不能只看报错消失就收工，需要做一轮完整的回归验证，否则可能留下隐患。
第一项，验证长连接稳定性。在改动后的窗口内观察 TD 之间的数据是否有偶发重置，方法是在日志中统计 SocketException: Connection reset 出现的频率。如果明显上升，说明 TIME_WAIT 值调得太短或者网络设备上存在不兼容策略，需要把值调大一点。
第二项，验证压测结果的资源曲线。重启后跑一轮之前会崩的压测场景，重点看三个指标：TIME_WAIT 最大值、动态端口清空后的剩余极限、CPU 系统态占比。网络栈处理大量连接时会有一定的 CPU 开销，如果系统态 CPU 超过 40%，说明连接风暴的问题虽然被容量兜底了，但对 CPU 的消耗仍然存在，代码层面还得继续优化。
第三项，建议把改动记录写到变更文档里。这种问题一般不是只发生一次，运维手册里如果没有记录，下次新同学接手又要从零开始挖一遍坑。
5. 我踩过几次坑之后的经验总结
说几个常规文档里不会写但实际特别关键的细节。
第一点：Windows 在做这些网络参数调整时，要同时注意 IPv4 和 IPv6 两套动态端口配置。Java 默认优先 IPv4，但有的连接池框架会对 IPv6 地址发起连接，IPv6 端口范围一旦没扩，问题依然存在。所以刚才 netsh 里两条命令我都列了，缺一不可。
第二点：在 Windows 环境跑 JMeter 压测时，JMeter 本身也会消耗临时端口。如果你是在压测机上跑 JMeter、被测服务在另一台 Windows 上，两边都可能报“No buffer space available”。不要只盯服务端，压测机的连接数在压力大的时候也会把自己憋死。JMeter 的 HTTP Sampler 配置 KeepAlive 并把线程数控制在合理范围，经常比调服务端参数更有效。
第三点：如果你用的连接池是 HikariCP，它在初始化时会预创建 minimumIdle 个连接，在连接被持续借用时还会触发动态扩缩容。当目标数据库恰好不接受更多连接时，HikariCP 会在应用侧疯狂重试连接建立，造成大量 Connection is not available 或底层 SocketException。这时候把 maximumPoolSize 调低、把 connectionTimeout 调高，反而比调任何系统参数都解决问题。
我在实际排查中体会最深的一点：这个报错之所以让人头疼，是因为它的表面原因在操作系统，但根本原因几乎总在应用设计上。如果你只靠改注册表和 netsh 把容量扩大了，而代码里的短连接模式还在，那只是把故障从 “2 天崩一次” 推迟到 “两周崩一次”。真正治得住的办法，是在扩容腾出的窗口期里，把连接池化、连接复用和重试策略彻底改好。
最后再分享一个小经验：遇到这种底层报错，第一件事别急着搜索，先把报错原文、时间点、网络拓扑和 Java 进程的完整传入参数记下来。排查这类问题，工单里多一行 netstat 输出，就少花一小时猜原因。这一行往往就是定位“是不是端口耗尽”的证据，也是从“救火”迈向“治理”的第一步。