升级MySQL至5.6.39企业版后Spring DBCP连接池应用挂起求助

嘿，针对你遇到的这个麻烦——升级MySQL到5.6.39企业版后，应用时不时挂起、所有线程陷入等待，必须重启Wildfly才能恢复，甚至四天不重启就彻底无法运行——我整理了几个大概率的问题根源和对应的解决步骤，你可以一步步排查：

可能的问题根源 #

• MySQL 5.6.39企业版的默认连接参数和社区版5.6.11存在不少差异，尤其是连接超时、空闲回收这类和连接池强相关的配置，DBCP的默认设置没跟上节奏，导致连接池里的连接要么被耗尽，要么失效后未被及时回收，所有业务线程都卡在等待获取数据库连接的环节。
• DBCP未配置有效的连接验证规则，无法检测出已失效的连接，线程拿到"死连接"后就一直阻塞在操作数据库的步骤上。
• 部分MySQL企业版默认强制开启SSL连接，而你的DBCP未配置SSL相关参数，导致连接建立或复用过程中卡住。

具体排查修复步骤 #

1. 调整DBCP连接池核心配置 #

给你的BasicDataSource补上这些关键参数，适配MySQL企业版的特性：

// 若使用Spring XML配置，对应设置<property>标签即可
basicDataSource.setValidationQuery("SELECT 1");
basicDataSource.setTestOnBorrow(true);
basicDataSource.setTestWhileIdle(true);
basicDataSource.setTimeBetweenEvictionRunsMillis(30000); // 每30秒检查一次空闲连接
basicDataSource.setMinEvictableIdleTimeMillis(1800000); // 空闲30分钟的连接直接回收
basicDataSource.setMaxWaitMillis(10000); // 获取连接超时10秒，避免线程无限等待

这些配置的作用：

• validationQuery：用最简SQL验证连接有效性，MySQL用SELECT 1足够。
• TestOnBorrow：获取连接前先验证，避免拿到已失效的连接。
• TestWhileIdle：空闲时自动检查连接，提前回收死连接。
• MaxWaitMillis：设置超时时间，防止线程一直卡着等连接，至少能抛出超时异常，不会让整个应用挂死。

2. 检查MySQL企业版的SSL强制配置 #

登录MySQL服务器，执行这条命令确认是否强制要求SSL连接：

SHOW VARIABLES LIKE 'require_secure_transport';

如果结果为ON，需要在DBCP的JDBC URL中添加SSL相关参数：

jdbc:mysql://你的数据库地址:3306/你的库名?useSSL=true&requireSSL=true&trustCertificateKeyStoreUrl=file:/你的信任证书路径/truststore.jks&trustCertificateKeyStorePassword=证书密码

若不需要SSL连接，可修改MySQL配置关闭require_secure_transport，或在URL中添加useSSL=false（注意企业版可能有安全策略限制，建议先确认合规性）。

3. 深挖线程转储确认阻塞点 #

你提供的线程转储片段仅提到Attach Listener线程（这是调试用的守护线程，无业务影响），重点要查看等待获取数据库连接的业务线程的栈信息，比如是否卡在org.apache.commons.dbcp.PoolingDataSource.getConnection()或com.mysql.jdbc.ConnectionImpl.createNewIO()这类方法上：

典型阻塞栈示例：

"http-nio-8080-exec-10" #123 prio=5 os_prio=0 tid=0x00007ff884012340 nid=0x1234 waiting on condition [0x00007ff88a123450]
   java.lang.Thread.State: WAITING (parking)
    at sun.misc.Unsafe.park(Native Method)
    - parking to wait for  <0x000000076abcdef0> (a org.apache.commons.dbcp.PoolingDataSource$PoolGuardConnectionWrapper)
    at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
    at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
    at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
    at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
    at org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:118)

如果是这种情况，基本可以确认是连接池耗尽，按照第一步的配置调整就能解决。

4. 升级DBCP版本（可选但推荐） #

若你使用的是较旧的DBCP 1.x版本，可能与MySQL 5.6.39企业版存在兼容性问题，建议升级到commons-dbcp2（2.x系列），它的连接管理更稳定，支持更多现代数据库特性：

<!-- Maven依赖示例，版本选最新稳定版即可 -->
<dependency>
    <groupId>org.apache.commons</groupId>
    <artifactId>commons-dbcp2</artifactId>
    <version>2.10.0</version>
</dependency>

对应的配置类换成org.apache.commons.dbcp2.BasicDataSource，配置参数与旧版本基本兼容，无需大幅修改。

总结 #

优先从调整DBCP的连接验证和超时配置入手，再检查MySQL的SSL强制设置，结合线程转储确认阻塞点，大部分情况下都能解决应用挂起问题。若调整后仍有异常，可开启DBCP的DEBUG日志，查看连接池的创建、回收、获取过程，进一步定位具体原因。

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