连接池指标监控是定位数据库瓶颈的必经路径，需重点关注activeConnections、idleConnections、threadsAwaitingConnection、connectionAcquireMillis、totalConnections五项核心指标，并通过HikariCP+JMX快速采集，结合指标反推慢SQL、连接泄漏、频繁扩缩容等问题并优化。
重点关注这5个核心运行指标
连接池自身暴露的运行时指标，比压测结果更真实反映线上水位：
- activeConnections：当前被应用占用的连接数。持续接近 maximumPoolSize，说明连接不够用或存在泄漏
- idleConnections：空闲可用连接数。长期为 0 或极低，配合 high active 值，大概率是慢查询或连接未 close
- threadsAwaitingConnection：等待获取连接的线程数。非零值直接表明连接已成瓶颈，请求开始排队
- connectionAcquireMillis：平均获取连接耗时（毫秒）。超过 10ms 就需警惕，20ms+ 通常意味着池子过小或连接验证开销大
- totalConnections：池中总连接数。对比 active + idle，可判断是否频繁扩缩容（如 idleTimeout / maxLifetime 设置不合理）
用 HikariCP + JMX 快速启用监控
HikariCP 默认开启 JMX 支持，无需额外依赖即可采集指标：
- 启动时加 JVM 参数：
-Dcom.zaxxer.hikari.jmxEnabled=true - 用 JConsole 连接进程，在
com.zaxxer.hikariMBean 下查看HikariPool-1（或自定义 poolName）的属性和操作 - 关键属性包括：
ActiveConnections、IdleConnections、ThreadsAwaitingConnection、ConnectionAcquireTime等 - 定期调用
getTotalConnections()和getActiveConnections()接口，写入 Prometheus 或日志做趋势分析
从指标反推三类典型问题及优化动作
指标不是数字游戏，要能指导具体动作：
- 高 threadsAwaitingConnection + 高 acquireMillis → 缩短 connectionTimeout（避免长等）、增大 minimumIdle（预热池子）、检查数据库端连接数限制（max_connections）
- active ≈ total，idle 长期为 0，但 threadsAwaitingConnection 为 0 → 不是池子小，而是连接用得太久。查慢 SQL、事务未提交、流式查询未关闭 ResultSet
- totalConnections 波动剧烈（忽高忽低） → idleTimeout 太短（如设成 10s），或 maxLifetime 过短（如 5 分钟），导致连接反复创建销毁。建议 idleTimeout ≥ 30s，maxLifetime = 30min
结合 Druid 做 SQL 级深度下钻（可选增强）
如果需要定位哪条 SQL 拖垮了连接池，Druid 提供更细粒度支持：
- 开启
statFilter，自动统计每条 SQL 的执行次数、平均耗时、失败数 - 配置
wallFilter 启用 SQL 防火墙，拦截全表扫描、无 where 更新等高危语句 - 通过 Druid 内置监控页面（/druid/index.html）查看「SQL 列表」和「数据源」Tab，直观看到连接占用最久的 SQL
- 注意：Druid 资源开销略高于 HikariCP，高 QPS 场景建议以 HikariCP 为主监控，Druid 仅用于诊断期临时接入
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
