核心是快定位、准干预、稳收敛：查连接池active/pending/idle指标，临时压connectionTimeout至5–10秒并隔离慢查询，按数据库CPU核数×2～4反推maximumPoolSize，建立健康检查、慢查联动、索引评审三道防线。
数据库连接池参数配错，不是报错，而是悄悄拖垮系统——连接耗尽、接口超时、CPU飙升，但日志里找不到明显异常。处理这类故障，核心是“快定位、准干预、稳收敛”，不靠猜，靠指标和逻辑。
看连接池实时状态，别只盯应用日志
故障初期，应用日志往往只有“获取连接超时”或“SQLRecoverableException”，但根源在连接池内部。必须直接查连接池暴露的运行时指标：
- 活跃连接数（active connections）是否长期打满？接近 maximumPoolSize 就说明池子被占死
- 等待获取连接的线程数（pending threads）是否持续增长？说明请求在排队，且大概率会超时
- 空闲连接数（idle connections）是否为零？配合活跃数满，基本可判定慢查询正在“锁住”连接
- HikariCP 可通过
HikariDataSource.getHikariPoolMXBean()获取；Druid 提供内置监控页面或 JMX 接口
快速止血：临时调参 + 隔离慢查询
线上已抖动，先保服务，再查根因：
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 把 connectionTimeout 从默认 30 秒临时压到 5–10 秒，让失败更快返回，避免线程长时间阻塞
- 若确认是某类读操作引发（如报表），立即启用读写分离，将慢查询路由到只读库，隔离对主库连接池的影响
- 不建议盲目调大 maximumPoolSize——它可能加剧数据库争抢，反而恶化吞吐；优先做减法，不是加法
- 配合数据库侧执行
KILL慢会话，释放被占用的连接，给池子“松绑”
根因修复：按数据库承载力反推连接池上限
最大连接数不是拍脑袋定的。要结合数据库实例规格反向计算：
- MySQL/PostgreSQL 类 OLTP 数据库，活跃连接数建议控制在 CPU 核数 × 2～4 范围内。例如四核 MySQL 实例，maximumPoolSize 设为 12～16 更稳妥，而非默认的 20 或更高
- 检查数据库的
max_connections上限，连接池总大小（含所有应用实例）需预留至少 20% 余量，防其他组件抢连 - 配合 minIdle 和 idleTimeout（建议 10 分钟），避免空闲连接长期挂起，触发数据库端
wait_timeout主动断连 - 加上 maxLifetime（建议 30 分钟），强制连接定期刷新，防止长连接导致的连接泄漏或状态异常
建立防御机制，不让同类问题重演
一次故障暴露的是流程短板。后续必须补上三道防线：
- 上线前加连接池健康检查：启动时验证能否成功获取连接、执行简单 SQL，并记录耗时
- 接入慢查询日志联动——当某 SQL 执行超 500ms，自动告警并标记关联应用实例，便于快速定位“池子杀手”
- 所有新 SQL 上线前强制走索引评审；千万级表缺失关键查询字段索引，CI 流水线应卡点拦截
- 压测时必跑连接池饱和场景：模拟连接池打满 + 慢查询并发，验证超时策略与降级是否生效
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
