Java连接池配置核心在于匹配业务与DB能力，常见错误包括：maxLifetime超MySQL wait_timeout致连接失效；maximumPoolSize超DB max_connections引发雪崩；idleTimeout与connectionTimeout混淆致资源泄漏；忽略手动close导致GC无法释放连接；缺乏监控告警使问题滞后暴露。
Java 中连接池参数配置常见错误，核心问题不在“配不配”，而在于“配得是否贴合业务节奏和数据库实际能力”。很多故障——比如高并发下响应飙升、凌晨连接数突增、内存缓慢上涨直至 OOM——往往都源于几个关键参数的误设。纠正不靠堆参数，而靠理解每个值背后的资源边界与协作逻辑。
maxLifetime 设置偏离数据库 wait_timeout
这是最隐蔽也最常踩的坑。HikariCP 的 maxLifetime 若大于 MySQL 的 wait_timeout（默认 8 小时），连接池会把已被数据库端静默关闭的连接继续分发给应用，导致“Connection is closed”异常或查询无声失败。
- 查数据库真实超时：执行
SHOW VARIABLES LIKE 'wait_timeout';，记下数值（单位秒） - 正确设置：maxLifetime = (wait_timeout × 0.8) × 1000，再减去至少 300000 毫秒（5 分钟缓冲）
- 例如 wait_timeout=28800 秒 → maxLifetime 建议设为 22800000ms（6 小时 20 分），而非默认 30 分钟或盲目设 8 小时
maximumPoolSize 脱离数据库承载力硬调
设成 100 或 200 看似“保险”，实则可能压垮数据库。连接不是越多越好，而是要匹配 DB 的 max_connections 和单连接平均处理能力。
- 先查数据库上限：MySQL 执行
SHOW VARIABLES LIKE 'max_connections'; - 预留安全余量：应用侧 maximumPoolSize ≤ DB max_connections × 0.7（多实例部署时还要除以实例数）
- 结合业务峰值估算：QPS × 平均响应时间（秒）× 1.5，结果不能超过上一步的上限
- 典型参考：单实例 MySQL max_connections=300 → Java 应用 maximumPoolSize 建议 150～200 区间内按需取值
idleTimeout 与 connectionTimeout 混淆或缺失
这两个超时管的是完全不同的阶段：connectionTimeout 是“借连接等多久”，idleTimeout 是“连闲置多久该回收”。缺一不可，且值要合理错开。
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
立即学习“Java免费学习笔记（深入）”；
- connectionTimeout 建议 10～30 秒（如 20000ms）：防止线程无限阻塞在 getConnection()
- idleTimeout 建议 600～1200 秒（如 600000ms）：比 maxLifetime 小，确保空闲连接早于“老化”前被清理
- 切忌设为 0 或 Integer.MAX_VALUE：等于放弃主动回收，空闲连接永久驻留，最终耗尽文件句柄
忽略连接归还机制，依赖 GC 清理
Connection、Statement、ResultSet 不是普通对象，它们背后绑着 socket、本地缓冲区和数据库会话。GC 不会释放这些资源，只回收 JVM 堆里的引用。
- 所有数据库操作必须用 try-with-resources，强制 close() 在作用域结束时执行
- 禁止在 Service 层、工具类或静态变量中缓存 Connection 对象
- 异步场景（如 WebFlux + R2DBC）需确认在
doFinally或onComplete中显式释放，不能只靠订阅结束
不监控、不告警，直到报警才介入
连接池健康状态无法靠日志肉眼判断。必须暴露指标并设阈值，把“隐患”变成“可观测信号”。
- 通过 JMX 或 Micrometer 暴露：ActiveConnections、IdleConnections、TotalConnectionsAcquired、ThreadsAwaitingConnection
- 关键告警规则：ActiveConnections 持续 > maximumPoolSize × 0.85 达 90 秒，说明大量连接未归还
- 定期抓取连接堆栈：HikariCP 提供
getConnectionStackTraces()，可定位长期占用连接的具体代码行
