为什么服务端会堆积大量 TIME_WAIT？Java 开发必须搞懂的这个 TCP 状态
如果你写过几年的 Java 服务端，一定见过这样的场景：线上某个接口偶尔超时，上去一看ss -ant输出里头 TIME_WAIT 状态的连接动辄几万个，红色警告直接刷屏。新人第一反应是"是不是谁把连接没关？"，老手则会先冷静下来——TIME_WAIT 多不一定代表内存泄漏，也不一定代表业务异常，它可能只是一个被误解得很深的正常状态。
这篇文章想跟你聊透两件事：第一，TCP 为什么非要设计出 TIME_WAIT 这个状态，它到底在保护什么；第二，当 Java 服务端出现大量 TIME_WAIT 时，真正的原因链路是什么，应该怎么一步步排查，以及哪些内核参数可以调、哪些千万别乱碰。如果你是正在准备面试的 Java 工程师，这两个问题也几乎是网络方向必考题，搞懂原理比背答案有用得多。
1. TIME_WAIT 的前世今生：四次挥手里那个"主动关闭方"的宿命
1.1 从三次握手说起，为什么挥手需要四次
TCP 是面向连接的可靠传输协议，建立一个连接需要三次握手，断开一个连接则需要四次挥手。很多人背过这个结论，但没想过为什么挥手比握手多一次。原因其实很直白：建立连接时，SYN 和 ACK 可以合并成一个包发给对端，所以三次就够了；但断开连接时，两个方向的数据通道是完全独立的，主动关闭方发 FIN 只是表示"我这边的数据发完了"，被动关闭方可能还有数据没发完，所以它要先回一个 ACK 确认收到 FIN，等自己的数据发完后再补一个 FIN。这一来一回，就比握手多了一次。
四次挥手的完整序列是这样的：
- 主动关闭方发送 FIN，进入 FIN_WAIT_1
- 被动关闭方回复 ACK，主动关闭方进入 FIN_WAIT_2
- 被动关闭方发送 FIN，主动关闭方进入 TIME_WAIT
- 主动关闭方回复最后一个 ACK，然后进入 TIME_WAIT 并等待 2MSL 后关闭
注意一个关键点：TIME_WAIT 只出现在主动关闭方这一侧。被动关闭方收到最后一个 ACK 后就直接进 CLOSED 了，它不需要等待任何东西。所以当你的 Java 服务端出现大量 TIME_WAIT，第一个要确认的事实就是——你的服务端在大量主动断开连接，而不是被对端断开。
1.2 TIME_WAIT 到底在"等"什么，这两个理由缺一不可
关于 TIME_WAIT 为什么存在，绝大多数人只记得一个理由："等最后一个 ACK 到达对端"，其实完整答案是两个，而且第二个理由在实际排查中反而更容易被忽略。
第一个理由：确保最后一个 ACK 能到达对端。最后一次挥手时，主动关闭方发出的 ACK 是有可能丢失的。如果这个 ACK 丢了，被动关闭方收不到，会认为自己的 FIN 没送达，于是超时重发 FIN。假如主动关闭方发完 ACK 后立刻关闭连接，这个重发的 FIN 就没人理了，被动关闭方会一直重试，直到连接被强制重置。所以 TIME_WAIT 的存在，相当于给最后一个 ACK 留了一条"确认窗口"。
第二个理由：让旧连接的延迟报文在网络中自然消亡。这个理由很多人想不到。网络状况不是理想的，一个连接里可能有一些数据包因为拥塞、路由变化等原因，在网络中滞留了较长时间。如果主动关闭方关闭连接后立刻用相同的四元组（源IP、源端口、目标IP、目标端口）新建连接，新连接可能会收到旧连接残留的迟到的数据包，导致数据错乱。TIME_WAIT 的 2MSL 等待，就是为了确保旧连接的报文在网络里彻底消失，不会再污染新连接。MSL 是报文最大生存时间，通常取 30 秒到 2 分钟，所以 2MSL 一般在 1 到 4 分钟之间。
打个比方你就明白了：TCP 关闭连接就像退租房子，TIME_WAIT 是最后的押金结算期。房东（被动关闭方）要确认你结清了账单（收到最后一个 ACK），同时你也要确认不会再有旧快递送到这个地址（旧报文消逝）。押金没结清就搬走，后续一定出事。
1.3 一个常见误区：TIME_WAIT 多 = 连接泄漏？
我面试过不少候选人，一看到服务端 TIME_WAIT 多就脱口而出"连接泄漏了"。这个结论很多时候是错的。连接泄漏通常表现为 ESTABLISHED 状态持续上涨，或者 CLOSE_WAIT 堆积，而不是 TIME_WAIT 堆积。TIME_WAIT 本身就是一个"正在优雅关闭"的中间状态，它的存在恰恰说明连接关闭流程走得是正常的，只是数量太多、太密集，把端口和内存资源占满了而已。
真正需要警惕的反而是 CLOSE_WAIT——它代表被动关闭方收到了对端的 FIN，但自己一直没调用 close()，也就是应用层没有释放连接。CLOSE_WAIT 堆积才是典型的"代码忘了关连接"的信号。TIME_WAIT 和 CLOSE_WAIT 一个是协议层的正常等待，一个是应用层的资源泄漏，两者一定要分清。
2. 服务端 TIME_WAIT 暴增的网络链路真相：谁在主动断开连接？
2.1 短连接是 TIME_WAIT 的第一大来源
想明白服务端为什么会有大量 TIME_WAIT，只需要想明白一个问题：谁在主动断开连接，谁就会背上 TIME_WAIT 的包袱。对 Java Web 服务来说，最典型的情景就是短连接。
假设你的 Java 服务直接面对客户端（比如移动 App 请求 API），客户端每次请求都新建 TCP 连接，请求完就断开。如果断开是由服务端发起的（比如服务端配置了比较短的 keep-alive 超时，或者干脆每个请求处理完就关闭连接），那么每一次请求都会产生一个 TIME_WAIT 状态。在高并发场景下，QPS 是 1 万，单机每秒就会产生 1 万个 TIME_WAIT，每个状态要等 2MSL（假设 120 秒），那稳态下同时存在的 TIME_WAIT 数量就是 1 万乘以 120，也就是 120 万个。这个数字已经远超默认的端口范围了。
当然实际场景没这么极端，因为现代架构里客户端一般不会直接打到 Java 应用层，中间会有负载均衡、网关、Nginx 等一层层接住，但这个公式的逻辑是成立的：短连接数 × 2MSL = 稳态下的 TIME_WAIT 总量。
2.2 反向代理架构下的隐性 TIME_WAIT 制造机
互联网应用的标准链路是：客户端 -> Nginx/负载均衡 -> Java 服务。这种架构下，TIME_WAIT 往往不是 Java 进程最多，而是最外层接海量客户端请求的接入层最多。因为客户端通常是短连接，请求完就走人，接入层作为被动关闭方其实不会产生 TIME_WAIT——等等，这里有个容易混淆的点。
接入层如果对客户端保持 keep-alive，客户端自己主动断开，那么客户端是主动关闭方，接入层是 CLOSE_WAIT 方，接入层的 TIME_WAIT 不会增加。但如果接入层配置了"空闲超时断开"，比如 Nginx 的 keepalive_timeout 设得比较短，空闲连接的客户端迟迟不发起新请求，Nginx 会替客户端主动关闭这个连接，那 Nginx 就变成了主动关闭方，大量 TIME_WAIT 就会堆积在 Nginx 上。这也是为什么很多运维同学发现 Nginx 上 TIME_WAIT 多，一查业务量并不大——很可能就是 keepalive_timeout 配太短，或者健康检查探针频繁建连又断开导致的。
那 Java 服务端什么时候会成为 TIME_WAIT 大户？最常见两种：第一种，下游调用方是短连接，且由 Java 服务主动关闭。比如 Java 服务作为 RPC 调用方，或者作为 HTTP Client 调外部接口，用完后自己 close，同时并发又高，本身就会产生大量 TIME_WAIT——这种情况下 Java 进程是主动关闭方，TIME_WAIT 全在自己身上，CPU 都花在了 TIME_WAIT 管理上；第二种，上游（如 Nginx）与 Java 服务之间是短连接，且 Nginx 不主动断开，Java 服务的 Web 容器（Tomcat、Netty 等）配置了 keep-alive 超时，超时后由 Java 服务主动关闭空闲连接，TIME_WAIT 就堆积在 Java 进程上。
2.3 健康检查、数据库连接池和任务调度也能凑热闹
除了主链路，还有一些"边角料"场景也会贡献不少 TIME_WAIT：负载均衡的健康检查。很多云负载均衡的 TCP 健康检查默认就是"建连-断开-再建连"，每检查一次就是一次完整的连接生命周期。如果健康检查频率高、后端数量多，负载均衡上会产生大量 TIME_WAIT，Java 服务端也会频繁经历连接建立和断开。数据库连接池、Redis 连接池同理，如果池里配置了"空闲连接回收"，回收时连接池会主动 close，也会产生 TIME_WAIT。任务调度框架如果每次调度都用短连接去调用别的服务，同样会产生 TIME_WAIT。
所以排查 TIME_WAIT 的时候，先别急着下结论。TIME_WAIT 多不是问题，问题是要确认它多在哪里、由谁产生的、是不是真的影响到了新连接建立。如果仅仅堆了一些 TIME_WAIT，但端口和内存都够用，业务也没有报错，那它可能只是"看起来吓人"。
3. 完整排查链路：从 ss 输出到抓包定位，还原一次 TIME_WAIT 排障全过程
3.1 第一步：先用 ss 统计，别再用 netstat 了
排查 TIME_WAIT 的第一步永远是统计和确认。出于性能考虑，我一般用ss而不是 netstat，特别是生产环境连接数非常多时，netstat 的-o和/proc遍历方式会慢到让人崩溃。
要看 TIME_WAIT 总量，直接执行：
ss -s这个命令会输出当前系统所有 TCP 状态的汇总，一眼就能看到 TIME_WAIT 有多少，相比起 netstat 一行行数到眼睛花，效率高一个量级。
如果发现 TIME_WAIT 数量确实异常，再细分看是哪些四元组在重复建立连接：
ss -tan | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n这条命令按对端 IP 统计连接数，能帮你快速看出 TIME_WAIT 主要集中在哪个下游对端。如果某个 IP 占了绝大多数 TIME_WAIT，那基本可以锁定是跟这个 IP 对应的服务（比如某个 Redis、某个 RPC 服务、某个 Nginx 转发源）之间存在大量短连接。
3.2 第二步：确认是哪个进程在主动断开连接
确认了 TIME_WAIT 数量之后，还要确认这些连接到底属于谁。注意一个坑：TIME_WAIT 状态的连接在进程退出或者连接关闭后，已经被内核接管，lsof和ss -p经常显示不出进程信息。这时候可以通过一个变通的手段——连接是由谁发起的，看它的四元组就能猜个大概。
我在实际排查中，一般分两步走：
# 查看当前处于 TIME_WAIT 的连接四元组分布 ss -tan '( state time-wait )' | head -50 # 查看 ESTABLISHED 状态未被释放的连接数量 ss -tan '( state established )'} | wc -l对比一下 ESTABLISHED 和 TIME_WAIT 两个状态的数量和比例。如果 ESTABLISHED 正常，TIME_WAIT 却异常多，说明连接建立和关闭都在高速进行中，活跃业务连接数不大——本质上是"短生命周期连接"的数量问题，不是"存量连接泄漏"的问题。
3.3 第三步：tcpdump 抓包还原挥手真相
如果还不放心，或者想搞清楚到底是"服务端主动关"还是"对端主动关"造成的 TIME_WAIT 堆积，tcpdump 是最直接的证据。生产环境条件允许的话，抓包分析一次完整的四次挥手过程：
tcpdump -i eth0 host 目标IP and port 8080 -w tw.cap然后分析.cap文件里的 FIN 包方向。简单规则：谁先发 FIN，谁就是主动关闭方，TIME_WAIT 就应该出现在谁那边。如果发现都是本机先发 FIN，那非常明确——是我们自己主动关的；如果大部分是本机收到对端的 FIN 后，本机在几十秒后才发出自己的 FIN（甚至一直不发，连接卡在 CLOSE_WAIT），那就是应用层释放连接的逻辑有问题。
3.4 第四步：按场景执行的四个分支排查
抓到抓包结果之后，按下面的场景分支去确认根因，能省不少时间：
分支 A：服务端直连海量客户端短连接。如果你的服务就是对外提供 API，客户端每次都新建连接，那么 TIME_WAIT 多是常态，考虑接入网关或开启 keep-alive 优化。
分支 B：服务端作为调用方访问外部/下游服务。这种场景里，Java 进程自己就是主动关闭方（每次 HTTP 调用用完就 close），TIME_WAIT 自然会堆在当前进程上。排查重点放在 HTTP Client 的连接管理——有没有复用连接池？连接池默认 idle 时间是否太短？很多默认配置是连接空闲 5 秒就回收，QPS 高的应用每一秒都在产生 TIME_WAIT。
分支 C：上游 Nginx 与 Java 服务的连接频繁断开。如果 Java 服务是被 Nginx 反代的，就去看 Nginx 的 upstream keepalive 配置。Nginx 默认向 upstream 发短连接，也就是每个请求到 Java 服务都是新连接，Nginx 作为客户端每次请求完主动断开。这时候 TIME_WAIT 明明在 Nginx 上更多，Java 服务虽然也会有一些 TIME_WAIT（如果 Tomcat 主动释放空闲连接），但主力在 Nginx。要优化的是 Nginx 的upstream keepalive。
分支 D：负载均衡健康检查太频繁。把健康检查的间隔拉长、把 TCP check 换成 HTTP check，TIME_WAIT 会显著下降。
我自己的经验是，十次 TIME_WAIT 排查里，至少七次是分支 B 和分支 C 的组合——要么是团队里有人直接 new 了 HttpClient 没用连接池，要么是 Nginx 没配 upstream keepalive。真正需要调内核参数的场景，反而少之又少。
4. 内核参数调优：能调的只有那几项，别把系统搞成定时炸弹
4.1 tcp_tw_reuse：唯一还算推荐的内核开关，但只对客户端有效
Linux 内核里有一个经典参数net.ipv4.tcp_tw_reuse，作用是允许内核在安全的前提下，把处于 TIME_WAIT 状态的连接的四元组拿出来重新用于新连接。注意关键字：安全的前提下。内核会检查新连接的时间戳，确保旧连接残留报文不会再被新连接收到，所以复用不算激进。
但有一个大坑必须讲清楚：tcp_tw_reuse只对"出站连接"——也就是本机作为客户端发起的新连接——有效。如果你的 Java 服务是服务端，等待别人来连，TIME_WAIT 堆积在监听 socket 上，这个参数是不生效的。很多朋友踩过这个坑：改完 sysctl 重启服务，一看 TIME_WAIT 还是几千几万纹丝不动，就是这个原因。
所以tcp_tw_reuse真正的适用场景是：你的 Java 服务主动作为调用方，大量短连接访问下游，TIME_WAIT 堆积在自己的出站连接上。这时候开tcp_tw_reuse可以明显改善端口复用的情况。修改方式：
# 临时生效 sysctl -w net.ipv4.tcp_tw_reuse=1 # 永久生效，写入 /etc/sysctl.conf net.ipv4.tcp_tw_reuse = 1还有一个前提条件：时间戳选项必须打开。检查一下net.ipv4.tcp_timestamps是否为 1，一般现代 Linux 发行版默认都是 1，但如果被调过关掉了，tcp_tw_reuse不会生效。
顺带说一句，tcp_tw_recycle这个参数在很长一段时间里被误传为"TIME_WAIT 优化利器"，但它存在严重的坑：它假设同一个源 IP 的请求时间戳单调递增，NAT 后面多个客户端会互相干扰，导致部分连接被直接丢弃。这参数在 Linux 4.12 之后的内核里已经被删除了，网上还能搜到大量老文章教人开这个，千万别照着做。见到建议开 tw_recycle 的文章，直接划走。
4.2 tcp_max_tw_buckets：系统保护阈值，不是让你瞎调大的
net.ipv4.tcp_max_tw_buckets是内核限制 TIME_WAIT 状态连接数量的保护阈值，默认值一般是 180000（不同内核版本有差异）。超过这个值后，内核不会继续维护 TIME_WAIT 状态，新的连接会被直接关闭，然后系统日志里会打印类似TCP: time wait bucket table overflow的告警。
很多人的第一反应是把tcp_max_tw_buckets调大，让系统容纳更多 TIME_WAIT。这是一个值得商榷的操作。TIME_WAIT 本身就是一种资源保护机制，硬性把它截断虽然能避免表溢出，但会让处于 TIME_WAIT 的连接没有机会完成 2MSL 等待，极端情况下可能导致对端重发的 FIN 没人回 ACK，进而出现连接重置或数据异常。正确思路是：这个参数是"最后一道保险"，让它兜底就够了，一般不要去动。如果频繁出现 overflow 告警，说明你没在应用层解决连接生命周期问题，内核帮你续命也只是延缓症状。
4.3 端口范围、keep-alive 以及"改参数前必须想清楚的事"
TIME_WAIT 过多最直接的资源压力是本地端口耗尽。每个 TCP 连接在主动发起方一侧都会占用一个临时端口，范围由net.ipv4.ip_local_port_range控制，默认一般是 32768 到 60999，合起来大概 28000 个端口。如果短连接建立速度快于端口释放速度，端口就可能被占满，新连接报Cannot assign requested address。
这时候可以看情况拉大这个范围：
sysctl -w net.ipv4.ip_local_port_range="1024 65535"但端口范围从 32768 扩到 1024 开始，只是把缓冲池拉大了，治标不治本。连接生命周期问题不解决，总有一天端口还是会耗尽，只是时间轴往后拉长了一点。内核原生还提供了tcp_fin_timeout参数（默认 60 秒），这个参数控制 FIN_WAIT_2 状态在主动关闭方的持续时间。如果你的系统里 FIN_WAIT_2 也很多，可以适当调小，但同样是缓解方案，不是根因解法。
我自己判断是否调内核参数时，会先回答三个问题：
- 这个 TIME_WAIT 是因为业务特点（比如极高频短连接 API）导致的，还是因为代码/配置没做好连接复用？
- 如果我调了参数，会不会掩盖掉真正的代码缺陷？
- 调参影响的是当前进程，还是整机上的所有应用？
如果答案是"代码/配置能解决"，我绝对不动内核参数。线上环境多一个参数就多一个不稳定因子，能不动就不动。
4.4 从协议设计角度思考：能不能让 TIME_WAIT 根本不出现？
既然短连接是 TIME_WAIT 的根源，最彻底的解法其实是"不要频繁断开连接"。HTTP/1.1 的 keep-alive、HTTP/2 的多路复用、TCP 长连接池、RPC 框架的内部连接复用，本质都是在做同一件事：把"一次业务请求一次 TCP 连接"改成"多条业务请求共享一条 TCP 连接"。连接一旦不需要反复建立和断开，TIME_WAIT 自然就没有了。
所以调参永远只是临时的止痛药，真正的长期方案是：
- 对外接口前面加网关/接入层，让客户端与网关之间保持长连接
- Nginx 与后端 Java 服务之间开启
upstream keepalive - Java 内部所有 HTTP/RPC 调用必须走连接池，禁止裸 new Connection
- 数据库、Redis 连接池的 maxIdle 和 idleTimeout 按业务波峰波谷合理设置，避免空闲回收过于频繁
5. Java 应用层的联动优化：连接池、Web 容器与代码习惯的配合
5.1 Tomcat/Spring Boot 的 keep-alive 参数：既要复用，又要有上限
Spring Boot 默认内嵌 Tomcat，它本身是支持 keep-alive 的，客户端可以复用同一 TCP 连接发多个请求。但默认配置下，Tomcat 的 keep-alive 超时时间是 60 秒，也就是连接空闲超过 60 秒，Tomcat 就会主动 close 这个连接，此时 Tomcat 就成了 TIME_WAIT 的制造者。
在高并发短请求场景，如果 60 秒内大量连接都是"连上-发一个请求-闲置-被超时关闭"，TIME_WAIT 就会以每秒吞吐量的速度累计。一个常见优化是调整server.tomcat.keep-alive-timeout（Spring Boot 2.x 后server.tomcat.keep-alive-timeout直接可用）
server.tomcat.keep-alive-timeout=120s server.tomcat.max-keep-alive-requests=10000max-keep-alive-requests也很关键，它限制了一条 keep-alive 连接上最多处理多少个请求。默认值 100 左右，如果客户端长连接复用了很多次，超过上限后 Tomcat 会主动断开，也会产生 TIME_WAIT。把它适当调大，能减少连接断开次数。但注意不要调到无穷大，极端情况下一条连接被某个客户端长期霸占，反而不利于负载均衡和连接公平性。
5.2 HTTP 客户端的连接池是"重灾区"，很多人在这里裸奔
如果说服务端自己产生的 TIME_WAIT 还能靠 Web 容器配置缓解，那么 Java 进程作为调用方产生的 TIME_WAIT，绝大多数时候是代码习惯问题。Apache HttpClient、OkHttp、Spring RestTemplate 其实都支持连接池，但很多人图省事直接每次 new 一个 Client，或者用 RestTemplate 时不配置连接池，底层就会变成每次请求新建连接、用完关闭。
具体到代码层面，几个值得检查的点：
HttpClient 连接池的存活时间。连接池里空闲连接的默认 evict 时间如果设置得太短（比如 5 秒），空闲连接很快会被回收，下一次请求又重新建连。高并发下，这等于把每一条连接的生命周期压到几秒，TIME_WAIT 必然堆积。
maxConnPerRoute 要大于单路由的峰值并发。如果并发超过连接池上限，HttpClient 会排队等待，却不会新建连接，不会产生 TIME_WAIT——这个方向反而是请求延迟上升。但如果连接池上限设得过大，空闲连接过多，回收时又会集中产生一批 TIME_WAIT。所以连接池不是越大越好，而是要和 QPS、下游 RT 匹配。
我的建议是：写一个简单的监控点，把连接池的getConnectionCount()和getPendingConnectionCount()打到监控系统，观察波峰波谷，再反推 idle 时间和最大连接数。不要拍脑袋配。
5.3 RPC 框架天然更优：为什么 Dubbo/gRPC 很少被 TIME_WAIT 困扰
绝大多数 Java 团队内部链路用的是 Dubbo 或 gRPC 这类 RPC 框架，它们天然就是长连接设计。Dubbo 的 Netty 连接默认是懒建立的，建起来之后一直复用，不会频繁断开。gRPC 的 HTTP/2 更是可以在一张 TCP 连接上跑成千上万个并发请求，TIME_WAIT 在这种链路上基本不存在。
所以当你看到一个 Java 服务 TIME_WAIT 高，却发现内部 RPC 链路是长连接，那可以先排查是不是有业务代码绕过 RPC 框架直接用了 HTTP 调用、或者每次调用动态创建了新的 Client。我在实际项目里遇到过不止一次：核心链路全是 Dubbo，但某个监控上报模块每次用原始 Socket 发数据到日志平台，QPS 不高但上报频率很密，硬生生给服务造了几万个 TIME_WAIT。
5.4 代码层面的习惯：用 try-with-resources 不等于可以随便 new
很多 Java 开发者有个根深蒂固的习惯：既然连接要 release，那我每次用 try-with-resources 关掉就好了。这个习惯在数据库连接池的场景是对的，但在 HTTP/TCP 客户端的场景下容易变成灾难。close()一个连接池管理的连接，和close()一个裸连接，语义完全不同。前者是把连接还给池子，后者是把连接彻底销毁。
如果你使用的是连接池管理的 HttpClient，正确做法是不要反复 close 整个 Client，而是借用池里的连接，用完归还。频繁client.close()+new HttpClient()是最典型的 TIME_WAIT 制造机，而且这种行为不容易在测试环境暴露——因为测试环境并发低，端口根本不够用的时候早就出事了。线上并发一起来，TIME_WAIT 表直接打满。
6. 一次真实的 Java 服务 TIME_WAIT 排障复盘：从 5 万降到 2000
6.1 现象：QPS 正常，但接口偶尔超时且 TIME_WAIT 高居不下
去年帮一个团队排查过类似问题。他们的业务是一个 OAuth 授权服务，请求量并不算特别高，平均 QPS 只有 800 左右，但ss -s显示 TIME_WAIT 常年在 5 万以上。现象是偶发超时，超时请求的日志里能看到Cannot assign requested address字样，非常典型的端口耗尽。
由于端口范围默认只有大约 28000 个可用端口，5 万个 TIME_WAIT 意味着有一大半连接已经在等待状态了，新连接无法获取端口。但奇怪的是，如果 QPS 只有 800，即使全部是短连接，2MSL 为 60 秒，稳态 TIME_WAIT 也就 48000 左右。数字基本对得上，说明每笔请求都是全新的 TCP 连接，没有做任何复用。
6.2 排查过程：先抓包，再盯代码，最后才看参数
第一轮排查先看连接是谁发起的。抓包发现，TIME_WAIT 四元组里目标端口都是 MySQL 3306。这个授权服务每次请求都要查数据库，而数据库访问层用的是非常原始的 JDBC 直连——每笔请求都DriverManager.getConnection()，用完就 close。这就是根因：每笔业务请求对应一次完整的 MySQL 建连和断连，连接数完全随 QPS 线性增长。
第二轮确认代码逻辑，发现项目里数据库连接池虽然引入了 HikariCP，但某个历史版本把连接池从核心路径上绕过去了，只有部分业务走了连接池，另一部分直接裸 JDBC。我建议直接统一改成 HikariCP 连接池，配置了maximumPoolSize=50，同时把idleTimeout设为 300 秒，避免空闲回收太频繁。
第三轮处理显性的历史遗留 bug：有一个定时任务每 30 秒跑一次，每次创建新的 RestTemplate 调用外部服务，用完整连接用完就丢。把这段改成单例 RestTemplate + 连接池配置。
6.3 优化效果与后续监控
改造完成后，同一个服务在同一 QPS 下，TIME_WAIT 从 5 万降到了 2000 左右，接口超时完全消失。而这个 2000 是哪儿来的？主要是负载均衡健康检查造成的，已经属于正常范围。整个过程没有改任何内核参数，纯粹是应用层的连接生命周期管理修复。
复盘下来，这个问题的本质很简单：连接复用做没做好，直接决定了 TIME_WAIT 的堆叠高度。内核参数只是延迟了端口耗尽的发生时间，根本解决不了并发量上来后的必然结果。
6.4 面试里怎么谈 TIME_WAIT，才算答到点子上
如果你是准备面试的 Java 工程师，关于 TIME_WAIT 这个问题，我建议你回答得"下沉"一点，而不是只背概念。一个完整的回答框架可以是这样：
第一层，说清楚 TIME_WAIT 为什么存在（两个理由：最后 ACK 的可靠性保证、让旧报文消逝防串扰），确认自己懂原理。第二层，说清楚它为什么会堆积（主动关闭方 + 短连接模式 + QPS 越高堆积越快），展示自己懂排查方向。第三层，说清楚怎么排查和解决（ss 统计、tcpdump 抓包、连接池/长连接改造、tcp_tw_reuse 的适用边界，以及 tw_recycle 已经废了的现状），展示自己是干过实际项目的，不是背书的。
我之前面过几个候选人，说到 TIME_WAIT 都能把状态迁移图背得滚瓜烂熟，但一问到"如果你的服务是服务端，TIME_WAIT 多，改 tcp_tw_reuse 有没有用"，就卡壳了。这其实就是对原理理解不够透彻的表现——TIME_WAIT 属于主动关闭方，服务端如果是被动关闭方，TIME_WAIT 根本不会出现在服务端。
7. 最后再分享两个小经验
7.1 监控 TIME_WAIT 比治理 TIME_WAIT 更关键
TIME_WAIT 数量不一定要压到零，它更像是一个系统健康指标。如果业务本身就是高频短连接模型，TIME_WAIT 有存在是必然的，问题只在于它有没有突破端口范围、有没有触发 bucket overflow、有没有导致新建连接失败。所以在监控系统里把ss -s输出的 TIME_WAIT 数量、端口占用率、connection timeout 事件串起来看，比单纯盯着某个数字更有效。
7.2 尽量别在生产环境直接抓包
如果非要抓包，用-c限制包数量、用过滤条件缩小范围，抓完立刻停。线上环境抓包产生的 CPU 和磁盘开销在大流量下是不可忽略的。我一般是先在测试环境吹流量复现问题，再决定是否在线上抓包。实在要在线上抓，也选择低峰期，同时只针对具体四元组过滤，而不是全端口全流量。
TCP 的 TIME_WAIT 状态确实让人困惑，但它不是一个"错误"，而是协议为了保证可靠性设计出来的必要机制。搞懂它，你就搞懂了 TCP 一半的状态机设计思路。对做 Java 服务端的同学来说，理解了 TIME_WAIT 的来龙去脉，排网络问题的时候会少走很多弯路。下次再看到 TIME_WAIT 爆表，记住先问自己一句：谁在主动断开连接？答案往往藏在这句话里。
