连接池满时应可控响应而非避免，需配置拒绝策略、主动拦截降级、增强可观测性并根因分析；HikariCP无排队直接超时抛异常，Druid和Tomcat支持排队等待；通过监控指标、泄漏检测、线程快照及压力测试等实现精准预警与治理。
当数据库连接池满时，Java 应用通常会阻塞等待或直接抛出异常（如 CannotGetJdbcConnectionException 或 PoolExhaustedException），这说明连接资源已耗尽。处理的核心不是“避免满”，而是“可控地响应满”——包括拒绝策略配置、线程行为控制、可观测性增强和快速定位根因。
明确连接池的拒绝策略类型
不同连接池实现对“获取连接超时”的处理逻辑不同，需按实际使用的连接池配置：
-
HikariCP：默认不排队，
connection-timeout（如 30000ms）到期后直接抛HikariPool.PoolInitializationException或SQLException；无内置排队队列，因此“拒绝”即“超时失败” -
Druid：支持
maxWait（排队等待最大毫秒数），超时后抛SQLException；还可通过notFullTimeoutRetryCount配置重试次数 -
Tomcat JDBC Pool：由
maxWait控制等待上限，超时抛SQLException；可通过validationQueryTimeout等辅助控制验证阶段行为
主动拦截与降级：在获取连接前做判断
不能只依赖连接池抛异常再兜底，应在调用 dataSource.getConnection() 前加一层轻量检查，提升响应速度和可观察性：
- 对 HikariCP，调用
getHikariPoolMXBean().getActiveConnections()获取当前活跃连接数，结合getMaximumPoolSize()计算使用率，超过阈值（如 90%）可提前记录告警或触发限流 - 封装统一的
SafeDataSource工具类，在getConnection()中捕获连接异常，并记录堆栈、线程名、请求上下文（如 traceId），便于关联业务链路 - 配合 Sentinel 或 Resilience4j，在 DAO 层方法上添加熔断器，当连续 N 次连接失败则自动熔断，返回兜底数据或友好错误
报警必须带上下文，不能只告“连接池满了”
单纯监控 activeConnections == maxPoolSize 意义有限。有效报警需回答三个问题：谁在用？为什么没释放？是不是慢 SQL 或事务未提交？
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
立即学习“Java免费学习笔记（深入）”；
- 开启连接泄漏检测：
leakDetectionThreshold=60000（HikariCP），超时未关闭连接时打印持有该连接的线程堆栈，这是定位连接不释放的黄金线索 - 集成 Micrometer + Prometheus，暴露指标如
hikaricp_connections_active、hikaricp_connections_idle、hikaricp_connections_pending，用 Grafana 设置「pending 连接持续 > 5 且 active == max」的复合告警 - 在连接获取失败时，自动采集 JVM 线程快照（
ThreadMXBean.dumpAllThreads()）并上报至日志系统，标记关键词[DB-POOL-REJECT]，方便 ELK 聚合分析阻塞线程共性
日常预防比应急更重要
连接池满本质是资源供需失衡，长期解法在于压测、治理和规范：
- 所有新 DAO 方法上线前，必须经过连接池压力测试：模拟高并发下连接获取成功率、平均等待时间、GC 行为，观察是否出现连接堆积
- 禁止在事务外手动
commit/rollback，禁用Connection.setAutoCommit(false)后不配事务管理器；Spring 中确保@Transactional正确传播，尤其注意REQUIRES_NEW嵌套导致连接翻倍 - 统一基类 DAO 强制校验：执行 SQL 前若发现当前线程已绑定 Connection（如 Spring 的
TransactionSynchronizationManager.getResource()返回非 null），则跳过新连接申请，复用已有连接
连接池满不是故障，而是信号。关键在让这个信号足够清晰、可追溯、可联动。配置合理、监控到位、代码守规，就能把“炸池”变成一次精准的容量预警。
