连接池满本质是连接被卡住未释放或慢操作长期占用，根因仅为连接泄漏或慢sql/锁竞争；需优先切断阻塞链、设全链路超时、隔离资源并精准监控，而非盲目调大max-active。
连接池满导致线程阻塞，本质不是连接数量不够，而是连接被卡住没释放、或慢操作长期占着不放。重点不在加连接数，而在切断阻塞链、控制超时、隔离资源、及时暴露问题。
查清真实原因：泄漏 or 慢SQL
先别急着调大 max-active。连接池满只是现象，背后通常只有两类根因：
-
连接泄漏：Connection/Statement/ResultSet 没关闭，尤其在异常分支或 try-with-resources 外手动管理时；开启 HikariCP 的
leakDetectionThreshold=60000（60 秒），日志会直接打出泄漏堆栈 - 慢 SQL 或锁竞争：单条查询执行超 5 秒、全表扫描、高并发更新同一行（如账户余额热点），让连接迟迟不能归还；用数据库慢日志 + EXPLAIN 分析执行计划，定位未走索引或事务过长的操作
强制超时熔断，不让一个慢请求拖垮全局
没有超时的数据库调用，等于给系统埋雷。每个环节都要设边界：
- HikariCP 配置
connection-timeout=3000：获取连接超过 3 秒直接失败，不排队等 - SQL 层加执行时限：MySQL 用
SET STATEMENT max_execution_time = 2000 FOR SELECT；MyBatis 的<select timeout="2"></select>显式声明秒级超时 - @Transactional 必须带
timeout = 3：防止事务空悬；autocommit=false 场景下，没 commit/rollback 就是泄漏温床
解耦 DB 操作，避免同步 JDBC 卡死线程
传统 JDBC 是同步阻塞调用，哪怕跑在虚拟线程里，也会让载体线程挂起不动——连接不释放、线程不出队。
- Spring Boot 3.4+ 项目中，停用 JdbcTemplate 和 MyBatis 同步模式，改用 R2DBC（如 r2dbc-postgresql）或封装好的异步客户端
- 若必须用 JDBC，把 DB 操作彻底移出主线程：
CompletableFuture.supplyAsync(() -> dao.find(id), dbExecutor)，并为dbExecutor单独配小而稳的线程池（core=4, max=8, 队列有界） - 绝对避免在 parallelStream 中直接调用 DAO，也不要把 Connection 或 PreparedStatement 跨 stage 传递
监控与容量治理：让问题看得见、控得住
靠经验调参不如靠指标驱动：
- 通过 HikariPoolMXBean 实时监控：
active = idle + waiting应始终 ≤max-total；一旦 waiting 线程持续上涨，说明获取连接已成瓶颈 - 设置
minimum-idle=5、maximum-pool-size根据业务峰值 QPS × 平均响应时间 × 安全系数（建议 1.5–2）反推，而非拍脑袋设 100 - 不同业务模块（如支付、查询、报表）使用独立数据源和连接池，防止单一模块故障扩散
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
