在现代化的应用架构中,数据库连接池是保障应用性能与稳定性的核心组件，它通过复用已建立的数据库连接，显著减少了频繁创建和销毁连接所带来的开销，连接池若配置不当或出现异常（如连接泄漏），反而会成为系统的瓶颈，掌握如何有效查看和监控数据库连接池的状态，是每一位开发者和运维人员的必备技能，本文将从多个维度，系统性地介绍查看数据库连接池的常用方法。
通过应用内部接口直接查看
大多数主流的数据库连接池（如HikariCP、Druid、C3P0等）都内置了丰富的监控和管理接口，这是最直接、最精准的查看方式。
JMX（Java Management Extensions）监控
对于Java应用而言,JMX是查看连接池状态的标准方式，连接池库通常会注册一个或多个MBean（Managed Bean），暴露其核心运行指标。
- 如何操作：使用JDK自带的
jconsole或jvisualvm工具，连接到目标Java进程，在“MBean”标签页下，可以找到连接池对应的MBean，HikariCP的MBean通常在com.zaxxer.hikari域下，而Druid则在com.alibaba.druid.pool域下。 - 关键指标：通过MBean，你可以实时查看以下核心数据：
ActiveConnections：正在被应用程序使用的活跃连接数。IdleConnections：当前空闲、可供应用程序获取的连接数。TotalConnections：连接池中总的连接数。ThreadsAwaitingConnection：当前有多少线程正在等待获取连接，这个指标是判断连接池是否紧张的关键。MaxPoolSize/MinPoolSize：连接池的最大和最小连接数配置。
连接池内置的Web监控页面
部分连接池提供了更为友好的Web监控控制台,其中最著名的当属Druid。
- 如何操作：在Druid的配置中，开启
StatFilter和StatViewServlet，配置完成后，通过访问特定URL（如http://<ip>:<port>/context/druid/index.html）即可进入其监控页面。 - 功能亮点：Druid的监控页面非常强大，不仅展示了连接池的基本状态，还提供了SQL性能分析、URI监控、Spring监控等功能，能帮助开发者快速定位到慢查询和潜在的性能问题点。
借助外部监控系统集成查看
在微服务或分布式系统中,逐一登录到每个应用实例去查看连接池状态效率低下，需要借助统一的监控系统。
APM（Application Performance Management）系统
现代APM工具（如SkyWalking、Pinpoint、New Relic、Dynatrace）通过Java Agent技术，能够无侵入地采集应用内部的各项指标，其中就包括了数据库连接池的状态。
- 优势：你可以在APM的Web界面上，直观地看到不同服务、不同实例的连接池使用趋势图、告警信息，并进行跨服务的关联分析，非常适合生产环境的长期监控和故障排查。
Prometheus + Grafana技术栈
这是开源社区非常流行的监控解决方案。
- 工作流程：需要在应用中部署一个JMX Exporter（如
jmx_prometheus_javaagent），它会将JMX MBean中的指标转换为Prometheus格式的指标，Prometheus服务器定期从应用拉取这些指标数据，通过Grafana连接Prometheus数据源，创建美观的可视化仪表盘。 - 优点：该方案高度可定制，社区有大量现成的Grafana模板可供导入，能够快速搭建起一套强大的连接池监控系统。
从数据库服务器端反向查询
有时,我们也可以从数据库的角度来验证连接情况，这可以作为一种辅助手段，帮助确认应用与数据库之间的连接数是否符合预期。
不同的数据库提供了不同的查询方式,以下以常见的MySQL和PostgreSQL为例：
| 数据库 | 查询语句 | 说明 |
|---|---|---|
| MySQL | SHOW PROCESSLIST; 或 SELECT * FROM INFORMATION_SCHEMA.PROCESSLIST; | 列出当前数据库的所有连接线程，可以关注Host（来源IP）、db（数据库）、Command（当前状态，如Sleep、Query）、Time（处于当前状态的秒数）等字段。 |
| PostgreSQL | SELECT * FROM pg_stat_activity; | 查看所有当前会话的活动状态，关键字段包括datname（数据库名）、usename（用户名）、client_addr（客户端地址）、state（状态，如active、idle）等。 |
注意事项：数据库端看到的连接数是当前已建立的TCP连接数，它可能与连接池中的ActiveConnections + IdleConnections数量相近，但无法直接反映有多少线程在Waiting，此方法主要用于确认连接总数是否异常，或排查是否存在长时间未释放的“僵尸”连接。
相关问答FAQs
问题1：当应用日志提示“无法获取连接，连接池已耗尽”时，应该优先从哪里排查？
解答：遇到此类问题，建议按以下步骤进行排查：
- 检查应用日志：首先查看应用日志中是否有“连接泄漏”的警告信息，许多连接池（如Druid）在检测到连接被长时间占用未释放时会打印警告，这是最直接的线索。
- 查看连接池实时状态：通过JMX或内置监控页面，立即查看
ActiveConnections、IdleConnections和ThreadsAwaitingConnection三个核心指标，如果ActiveConnections长时间等于MaxPoolSize，且ThreadsAwaitingConnection值很大，说明连接确实被占满。 - 分析数据库慢查询：登录数据库，执行
SHOW PROCESSLIST或类似查询，查看是否有执行时间过长的SQL语句，这些慢查询会长时间占用连接，导致其他请求无法获取。 - 审查业务代码：结合日志和监控，定位到可能导致连接长时间占用的代码逻辑，检查是否存在事务未正确提交/回滚、资源未在
finally块中关闭等编码问题。 - 评估配置合理性：如果以上均无异常，则需要审视连接池的
maxPoolSize配置是否过小，无法满足高峰期的业务需求。
问题2：为什么通过JMX看到的活跃连接数，和通过数据库查询看到的处于Query状态的连接数不一致？
解答：这是一个常见且正常的现象，原因在于两者观察的视角和状态定义不同：
- JMX视角：
ActiveConnections指的是连接池中已经被应用程序“借出”，但尚未“归还”的连接，只要应用代码中调用了dataSource.getConnection()并还未调用connection.close()，这个连接就被视为活跃，应用可能正在执行SQL，也可能只是在执行业务逻辑计算，并未与数据库交互。 - 数据库视角：数据库的
Query（或active）状态仅表示该连接当前时刻正在执行一条SQL命令，当一个连接从数据库获取数据后，应用可能在内存中进行复杂的计算或处理，这段时间内，该连接在JMX中仍是Active，但在数据库端可能已经回到了Sleep（或idle）状态。
JMX的ActiveConnections数量通常会大于或等于数据库端显示的Query状态连接数，两者不一致是正常的，关键在于观察它们的趋势和峰值是否在合理范围内。
【版权声明】：本站所有内容均来自网络，若无意侵犯到您的权利，请及时与我们联系将尽快删除相关内容!
发表回复