根本原因是Java客户端主动调用Connection.close()触发TCP主动关闭，导致本机大量TIME_WAIT；Oracle服务端被动关闭不进入该状态，问题根源在连接池配置不当与内核参数未优化。
Java 应用访问 Oracle 产生大量 TIME_WAIT，根本原因不是 Oracle 服务端主动关闭连接，而是 Java 客户端（即你的应用）在每次数据库操作后主动调用 Connection.close()，触发了 TCP 四次挥手中的“主动关闭”行为——谁先发 FIN，谁进 TIME_WAIT。
为什么是 Java 客户端而不是 Oracle 服务端在占端口
Oracle 数据库默认配置下，监听器（tnslsnr）收到客户端断连请求后，会被动关闭连接，自身进入 CLOSED 状态，不经过 TIME_WAIT。而 Java 应用使用 JDBC 驱动（如 ojdbc8.jar）发起连接后，若未复用连接、或连接池配置不当（如 c3p0 的 maxIdleTime 过短、checkoutTimeout 触发强制回收），就会频繁执行 close()，导致本机（Java 所在机器）对 Oracle 服务器 IP:1521 发起主动断连。
- 每条连接由四元组唯一标识：
本地IP:本地临时端口 → 远程IP:1521 - Linux 默认临时端口范围通常是
32768–60999（约 28232 个），60 秒内最多建立约 28k 条新连接 - 若应用每秒新建并关闭 500 个连接，稳态
TIME_WAIT数量 ≈500 × 60 = 30000，超出端口池上限，后续connect()就会失败，报Cannot assign requested address
常见触发场景：连接池配置失当
很多 Java 应用用 c3p0 或 Druid，但没意识到“连接空闲释放”和“连接物理关闭”是两回事。例如：
-
c3p0.maxIdleTime=30：连接空闲 30 秒就从池中移除 → 调用realConnection.close()→ 主动断开 TCP → 进入TIME_WAIT -
Druid中minIdle=0+removeAbandonedOnBorrow=true：借连接时发现闲置太久，直接 close 掉 → 同样触发主动断连 - Spring Boot 默认 HikariCP 的
connection-timeout和idle-timeout若设得太激进，也会放大问题
这些配置本身没错，但在高并发短查询场景下，等于把“连接复用”变成了“连接速建速毁”，把压力从数据库转移到了本机 TCP 栈。
立即学习“Java免费学习笔记（深入）”；
如何快速确认是 Java 主动关闭导致的
别只看 Oracle 服务器上的 netstat -an | grep :1521 | grep TIME_WAIT ——那基本为 0。真正要看的是 Java 应用所在机器：
-
ss -tan state time-wait | awk '{print $5}' | sort | uniq -c | sort -nr | head -5：看是否大量指向 Oracle 服务器 IP:1521 -
ss -s输出中关注time-wait行数字，再对比net.ipv4.ip_local_port_range差值（如60999 - 32768 + 1 = 28232）；若前者持续 > 25000，端口耗尽风险极高 - 抓包验证：
tcpdump -i any 'tcp[tcpflags] & (tcp-fin|tcp-rst) != 0 and host <oracle-ip>'</oracle-ip>，过滤出 FIN 包的源 IP —— 如果是你的 Java 机器发的，就坐实了
关键修复点不在 Oracle，而在 Java 连接池和内核参数协同
单纯调大 Oracle 的 processes 或 sessions 没用；重点是让 Java 少发 FIN，或者让 FIN 发了之后端口还能复用：
- 连接池层面：把
maxIdleTime（c3p0）或idle-timeout（HikariCP）设为 0 或 ≥ 300（5 分钟），避免频繁驱逐；确保min-idle> 0，维持常驻连接 - 内核层面（Java 机器上）：
net.ipv4.tcp_tw_reuse = 1必须开启，且依赖net.ipv4.tcp_timestamps = 1（现代 Linux 默认已开）；它允许内核把处于TIME_WAIT的 socket 用于新 outbound 连接（仅限客户端场景） - 禁用
net.ipv4.tcp_tw_recycle = 0（必须为 0！该参数在任何有 NAT 的环境都会导致连接失败，Linux 4.12+ 已移除，但旧系统仍可能残留） - 慎用
net.ipv4.tcp_fin_timeout：设为 30 可缩短等待时间，但不能低于 30，否则可能影响可靠性
最易被忽略的一点：Java 应用重启后，旧连接的 TIME_WAIT 不会立刻消失，它独立于进程生命周期存在。所以压测后看到 TIME_WAIT 持续高位，未必是当前代码还在猛关连接，可能是前一轮流量遗留的“TCP 尸体”。
