Wildfly连接池搭配Sybase数据库出现异常CLOSE_WAIT连接累积问题求助

一、如何判断哪一端发起的连接终止？ #

要定位发起连接终止的端，可从以下几个维度入手：

1. TCP抓包分析
   用tcpdump抓取数据库端口（50000）的流量：

   tcpdump port 50000 -w close_wait_capture.pcap
   

   用Wireshark打开抓包文件，过滤tcp.fin包，查看FIN包的源IP：

   • 如果源IP是数据库服务器，说明是数据库端主动发起终止
   • 如果源IP是应用服务器，说明是应用端先发起终止（这种情况CLOSE_WAIT通常不会大量累积，除非应用未完成后续TCP挥手步骤）

2. 查看连接状态详情
   执行ss -ti state CLOSE_WAIT '( dport = :50000 )'，输出会包含TCP连接的定时器和状态细节，结合本地/远端端口对应关系（本地是Wildfly的随机端口，远端是50000），再配合两端日志交叉验证。

3. 日志交叉核对

   • 开启Wildfly数据源的DEBUG日志（调整standalone.xml中数据源的日志级别），查看连接的创建、释放、异常记录，确认是否有连接被异常关闭的提示
   • 检查Sybase Anywhere的数据库日志，查找是否有主动断开连接的记录（比如超时告警、资源限制提示、会话终止日志）

二、两端发起连接终止的可能原因 #

数据库端（Sybase Anywhere）主动终止连接的常见原因 #

• 连接超时配置：数据库设置了connection_timeout或类似参数，超过指定时间无活动的连接被自动断开
• 资源限制触发：数据库达到最大连接数上限，或内存、CPU资源耗尽，主动清理闲置/占用资源的连接
• 会话被手动干预：DBA执行了DROP CONNECTION或KILL命令终止会话
• 数据库异常：出现死锁、事务超时、服务重启/故障切换等情况，数据库主动断开相关连接
• 中间设备干预：防火墙、负载均衡等网络设备设置了连接超时，长时间无数据传输的连接被中间设备切断，对应用侧表现为数据库端发起终止

应用端相关问题导致连接滞留在CLOSE_WAIT #

CLOSE_WAIT状态本质是应用侧未对数据库的FIN包发送ACK+FIN回应，所以即使是数据库先发起终止，应用侧的问题也会导致连接无法正常释放：

• 连接池配置缺陷：未配置连接有效性检查（如validation-query），无法及时检测到已被数据库断开的连接；或max-pool-size设置过松，连接池无法快速回收无效连接
• 代码层面未正确释放连接：JPA中EntityManager未关闭、事务未提交/回滚，导致连接被长期占用，无法响应数据库的终止信号
• Wildfly数据源bug：Wildfly 23的连接池实现可能存在连接管理逻辑缺陷，导致连接回收异常，滞留在CLOSE_WAIT状态
• 应用线程阻塞：处理数据库操作的线程被阻塞（如死锁、IO等待），无法执行连接关闭的逻辑，导致连接一直处于CLOSE_WAIT

内容的提问来源于stack exchange，提问作者gkatz