一、问题背景：线上故障的惊魂时刻 某日下午，线上系统突然出现大量接口超时，错误日志显示： Could not get JDBC Connection; nested exception is java.sql.SQLTransientConnectionException: HikariPool-1 - Connection is not available, request timed out after 30000ms. 更诡异的是：数据库服务器正常，网络连接正常，应用日志中却没有任何 SQL 执行超时。 这正是数据库连接池"假死"现象的典型特征。 二、核心概念：HikariCP 连接池机制 2.1 连接池工作原理 ┌────────────────────────────────────────────────────────────────┐ │ HikariCP 连接池架构 │ ├────────────────────────────────────────────────────────────────┤ │ │ │ 应用线程 │ │ │ │ │ ▼ │ │ ┌───....

去年我们搞了一次周年庆秒杀。活动页面提前一周预热，到点那一刻，后台监控直接变成一片红。 不是 QPS 被打爆——网关和应用层都扛住了。是数据库连接池，三秒之内从 0 飙到 200（最大连接数），然后所有请求开始报 Cannot get JDBC Connection。 最离谱的是，库存表一行没动。 因为所有请求刚到数据库门口，就被连接池耗尽的异常挡回去了。秒杀还没开始，数据库先倒下了。 一、连接池为什么瞬间被榨干 常规架构下，每次请求处理到数据库这一步才会获取连接。秒杀场景的流量是瞬时脉冲——0 秒之前无人问津，0 秒之后几十万并发同时冲到数据库门口。 连接池有个坑：它不会拒绝你，它只会让你排队等。 HikariCP 默认最大连接数 10（或者你手动设的 200），当并发的数据库请求数超过这个值时，获取连接的线程进入等待队列。每个请求最多等 connectionTimeout（默认 30 秒）。秒杀场景下 30 秒太长了—— 所有线程都在等连接 连接被前面进来的请求占用着（那些请求可能正在执行慢查询） 后面的请求继续涌进来抢连接 线程池里的线程全卡在获取连接上，CPU 空转 tom....

前言 数据库连接池是应用与数据库之间的桥梁，它的健康状况直接影响着整个系统的性能。当连接池中的连接被耗尽时，新的请求只能排队等待，响应时间从毫秒级飙升到秒级甚至超时，这就是 dreaded 的"连接池耗尽"问题。 传统的连接池配置是静态的：在应用启动时设置好最大连接数，之后就一成不变。但在实际生产环境中，流量是动态变化的： 早高峰：用户登录、查看数据，连接需求激增 大促期间：订单量暴增，数据库压力陡增 夜间批处理：定时任务集中执行，连接竞争激烈 本文将介绍一套完整的数据库连接池监控与动态扩容方案，实现： 实时监控：全面掌握连接池运行状态 智能扩容：连接不足时自动增加连接数 缩容回收：空闲时自动释放多余连接 告警通知：异常情况及时通知运维 一、连接池问题分析 1. 连接池耗尽的场景 ┌─────────────────────────────────────────────────────────────┐ │ 连接池耗尽场景示意 │ ├─────────────────────────────────────────────────────────────┤ │ │ │ 正常情....