配置连接池故障排查的核心在于通过监控接口获取连接状态，并结合日志定位耗尽或泄漏原因。通常做法是启用连接池的统计功能（如 druid 的 stat 视图或 hikaricp 的 mbean），观察活跃连接数、等待队列长度及慢 sql 记录。若发现连接数持续高位且无释放，需检查代码中是否存在未关闭的资源；若出现连接拒绝，则需调整最大连接数或排查网络与数据库端限制。
如何监控连接池的健康状态
通过集成 JMX 或专用监控面板可以实时查看连接池的运行指标。以 Druid 为例，开启 stat 监控后，可关注 ActiveCount（活跃连接数）、PoolingCount（池中空闲连接数）和 WaitThreadCount（等待线程数）。HikariCP 则通过 MBean 暴露类似数据，重点观察 Connections 和 Threads-Active。这些指标能直接反映池是否处于压力状态或即将耗尽。
import com.zaxxer.hikari.HikariConfig;
import com.zaxxer.hikari.HikariDataSource;
public class PoolMonitor {
public static void main(String[] args) throws Exception {
HikariConfig config = new HikariConfig();
config.setJdbcUrl("jdbc:mysql://localhost:3306/test");
config.setUsername("user");
config.setPassword("pass");
config.setMaximumPoolSize(10);
config.addDataSourceProperty("cachePrepStmts", "true");
config.addDataSourceProperty("prepStmtCacheSize", "250");
config.addDataSourceProperty("prepStmtCacheSqlLimit", "2048");
HikariDataSource ds = new HikariDataSource(config);
// 模拟获取连接并立即关闭，正常情况
try (var conn = ds.getConnection()) {
System.out.println("Connection acquired: " + conn.isValid(1));
}
// 检查当前状态
System.out.println("Active: " + ds.getHikariPoolMXBean().getActiveConnections());
System.out.println("Idle: " + ds.getHikariPoolMXBean().getIdleConnections());
ds.close();
}
}
运行上述代码，预期输出显示 Active 为 1 时正在使用，关闭后变为 0。这验证了连接在 try-with-resources 块结束后正确归还到池中。若在实际应用中 Active 持续增长且不降，说明存在连接泄漏或未正确关闭的情况。
立即学习“Java免费学习笔记（深入）”；
如何处理连接池耗尽导致的阻塞
当应用并发请求超过连接池容量时，获取连接的线程会被阻塞直到有可用连接或超时。解决此问题需调整 maximumPoolSize 或优化 SQL 执行时间。HikariCP 默认超时时间为 30 秒，可通过 connectionTimeout 参数调整。若频繁超时，应优先检查是否有长事务或慢查询占用连接过久，而非盲目增大池大小。
import com.zaxxer.hikari.HikariConfig;
import com.zaxxer.hikari.HikariDataSource;
import java.sql.Connection;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.TimeUnit;
public class PoolStressTest {
public static void main(String[] args) throws Exception {
HikariConfig config = new HikariConfig();
config.setJdbcUrl("jdbc:mysql://localhost:3306/test");
config.setUsername("user");
config.setPassword("pass");
config.setMaximumPoolSize(5); // 设置较小的池大小以模拟耗尽
config.setConnectionTimeout(TimeUnit.SECONDS.toMillis(5)); // 5秒超时
HikariDataSource ds = new HikariDataSource(config);
ExecutorService executor = Executors.newFixedThreadPool(10);
for (int i = 0; i < 10; i++) {
executor.submit(() -> {
try {
long start = System.currentTimeMillis();
try (Connection conn = ds.getConnection()) {
Thread.sleep(2000); // 模拟耗时操作
System.out.println(Thread.currentThread().getName() + " finished in " + (System.currentTimeMillis() - start) + "ms");
}
} catch (Exception e) {
System.err.println("Failed: " + e.getMessage());
}
});
}
executor.shutdown();
executor.awaitTermination(30, TimeUnit.SECONDS);
ds.close();
}
}
该测试程序创建 10 个线程竞争 5 个连接。预期结果是前 5 个线程迅速获得连接并执行，后 5 个线程等待。若等待时间超过 5 秒，将抛出 SQLException 提示超时。通过观察日志中的等待时间和异常，可以确认连接池是否因资源不足而阻塞，进而决定是否需要增加 maximumPoolSize 或优化业务逻辑以减少连接持有时间。
为什么连接池中出现大量 Waiting 线程
大量 Waiting 线程表明所有可用连接均被占用，且新请求无法立即获得连接。这通常由两个原因引起：一是并发量确实超过了池的最大容量；二是部分连接被长时间占用未释放，导致有效容量降低。在 Druid 中，可通过 stat 页面查看 SQL 执行时间，定位慢查询。在 HikariCP 中，检查 maxLifetime 是否设置合理，避免连接因过期而被强制关闭时引发额外开销。此外，确保所有 Connection、Statement 和 ResultSet 都在 finally 块或 try-with-resources 中关闭，防止连接泄漏。
