只要是跑Java Web应用、Spring Boot微服务或者任何连MySQL的业务系统连接池爆满这个问题基本都躲不过。你大概率见过这样的报错HikariCP的connection is not available, request timed out after 30000ms或者是Druid的wait millis 30000, active 20, maxActive 20。第一次碰到的时候很多人第一反应是“连接数不够调大maxPoolSize”结果调完发现治标不治本高峰期照样爆甚至把数据库直接拖垮。这篇文章就把整个排查过程和解决思路完整复盘一遍。文章会讲清楚连接池爆满时先看什么、每个报错参数到底在说什么、如何一步步定位到真正的根因以及从应用端和数据库端分别怎么下手解决。无论你是刚接触连接池的新手还是被线上告警折腾过的老手这波经验应该都能直接抄作业。1. 连接池爆满的表现与参数误读先搞清楚报错在说什么1.1 两种主流连接池的报错长什么样国内Java生态里连接池无非就是HikariCP、Druid、c3p0、dbcp这几家现在主流基本是HikariCP和Druid。两者的报错风格不太一样但表达的意思是一致的池子里没有空闲连接可用了请求在排队等连接等到超时就直接抛异常。HikariCP的典型报错java.sql.SQLTransientConnectionException: HikariPool-1 - Connection is not available, request timed out after 30000ms (total20, active20, idle0, waiting15)注意看最后括号里的几个数字total20是池子当前总共管理的连接数active20表示20个连接全部被业务线程借走idle0说明空闲连接为0waiting15表示还有15个线程在排队等连接。Druid的报错风格就直白些com.alibaba.druid.pool.GetConnectionTimeoutException: wait millis 30000, active 20, maxActive 20, creating 0这里的active 20、maxActive 20和HikariCP的active20, total20是一个意思——池子满了。这里有一个非常重要的点报错说的是“连接池满了”但连接池满了只是结果不是原因。就像银行柜台排队排到了门口你盯着“柜台数不够”去加柜台却没想过是不是前面有个客户在窗口办了一个小时不动。连接池的active连接被占满意味着有20个数据库连接正被业务代码占用着这20个连接在干什么才是关键。1.2 连接池几个关键参数的真正含义先说几个绕不开的参数很多人配置连接池只填了一个maximum-pool-size其他全靠默认值这其实埋了不少雷。HikariCP的核心参数参数名默认值含义maximumPoolSize10池中允许的最大连接数minimumIdle10池中维护的最小空闲连接数connectionTimeout30000ms客户端从池中获取连接的等待超时时间idleTimeout600000ms空闲连接超过该时长会被回收maxLifetime1800000ms连接最大存活时间超过后会被强制退役validationTimeout5000ms获取连接时校验可用性的超时时间Druid的核心参数对应关系参数名默认值含义maxActive8池中最大连接数minIdle0最小空闲连接数maxWait-1无限等待获取连接的最大等待毫秒数removeAbandonedfalse是否开启泄漏连接自动回收removeAbandonedTimeoutMillis300000连接被占用超过该毫秒数视为泄漏testWhileIdletrue空闲时是否校验连接有效性在排查爆满问题时我一般先看两个参数连接获取超时时间和最大连接数。报错里出现的30000ms就是客户端等待获取连接最多等了30秒等不到就放弃。这30秒内请求线程全被堵在getConnection()这一步后续的SQL根本发不出去。1.3 一个容易踩的认知误区最大连接数不是越大越好很多运维同学遇到连接池爆满第一反应是“maxActive20太小了改成100、200”。这个思路只对了一小半。连接池的理论并发上限并不是你写了100就真的有100。一个MySQL实例能处理的并发连接数有限连接数越多每个连接分到的CPU、内存、锁资源就越少。尤其当业务SQL本身偏慢时你把池子从20调到100反而会让数据库同时处理100个慢查询整体吞吐量断崖式下跌。我曾处理过一个线上事故Druid连接池maxActive50高峰期报GetConnectionTimeoutException。DBA直接把maxActive调到200结果数据库的Threads_running从几十飙到两百多CPU直接打到100%最终数据库hang死业务全部超时。后来我们把maxActive降回60同时优化了一批慢SQL问题彻底解决。连接池爆满时的第一要务不是加连接而是搞清楚已有的连接为什么不够用。提示如果你在报错里看到waiting或者排队线程数持续增长先别急着改参数登录数据库看一眼当前有哪些连接、在跑什么SQL、跑了多久这一步通常能把问题缩小到具体模块。2. 排查取证从复现到定位根因的完整链路2.1 第一步把池子调小稳定复现问题我排查这类问题不是直接上生产环境的大池子去分析而是先找一个测试环境把连接池参数调到很小比如maximumPoolSize5、minimumIdle2然后压一波流量确保问题能稳定复现。能复现才能观测到完整的证据链。这里有一个小技巧调小连接池不是为了让问题更严重而是为了缩短每个排查循环的周期。生产环境池子大、流量高你可能等很久才能抓到一次activetotal的瞬间池子调小后几乎每次压测都会触发爆满配合线程堆栈和监控很快就能看清连接被谁占着。复现时我会同步做三件事打开连接池统计日志HikariCP的poolStats、Druid的StatFilter记录active、idle、waiting的变化曲线开启show processlist定时采集每5秒抓一次数据库当前的连接快照准备一份业务线程的jstack输出在爆满发生的时刻抓取应用线程状态。2.2 第二步show processlist看清线程在干什么show processlist是排查连接池问题时最直接的工具不用装任何插件MySQL自带。它会把当前所有连接到实例的线程列出来每行包含Id、User、Host、db、Command、Time、State、Info这几列。重点关注三个地方Command列正常情况下绝大多数连接应该是Sleep空闲如果Query、Execute很多说明连接都在跑SQL。Time列Query状态的线程如果Time值很大比如几百秒那基本就是慢SQL实锤。State列如果大量线程卡在Waiting for table metadata lock、Waiting for lock、Updating这类状态说明问题不是SQL慢而是锁等待。举个例子有一次排查中发现连接池被打满执行show processlist后20个连接里有14个是Query状态全部指向同一张用户表Info列里能看到同一个慢查询模板执行时间从几秒到几十秒不等。这就解释通了一个慢查询把连接池的active打满后续所有请求都在等连接。show processlist有个局限它只显示当前正在执行的语句如果连接是Sleep状态你看到的就是空白。这时候还得配合information_schema.innodb_trx和performance_schema来看事务。2.3 第三步区分“慢SQL堆积”与“锁等待”连接被占满本质上只有两种可能SQL执行太慢连接一直不释放事务迟迟不提交连接被事务粘住了。判断方法很简单。查看information_schema.innodb_trxSELECT trx_id, trx_state, trx_started, trx_mysql_thread_id, trx_query, trx_rows_modified FROM information_schema.innodb_trx;如果查出来的事务trx_state是RUNNING并且trx_started时间已经过去很久比如10分钟、半小时那业务代码里多半有“开启事务后没及时提交”的问题。再看performance_schema.events_statements_currentSELECT THREAD_ID, SQL_TEXT, TIMER_WAIT/1000000000 AS cost_second FROM performance_schema.events_statements_current WHERE SQL_TEXT IS NOT NULL ORDER BY TIMER_WAIT DESC LIMIT 20;TIMER_WAIT的单位是皮秒除以10^9就是秒。通过这张表可以看到每个连接当前正在执行的SQL和耗时。这两张表结合起来基本就能把连接池爆满的锅落到具体SQL或具体事务上了。慢SQL堆积和锁等待的解决思路完全不同前者要靠加索引、改写SQL后者要把事务拆小、控制锁范围所以在排查阶段一定要分清楚。3. 根因分类四种最常见的爆满场景3.1 慢SQL打满连接查询先慢连接池后爆慢SQL是最常见的爆满原因逻辑很简单某个查询特别慢单个连接被占住好几秒池子里的连接数量有限当慢查询的速度超过了连接释放的速度池子就会被慢慢填满。有一次我们线上出现周期性连接池告警排查后发现是后台定时任务在每天凌晨跑一个多表JOIN统计其中一张大表的关联字段没有索引单次查询耗时3到5分钟。这个任务一跑20个连接被它自己吃掉十来个其他业务请求全部拿不到连接。慢SQL堆积的特征比较明显show processlist里能看到多个相同模板的Query语句Time列的数值普遍较大压测时active连接数稳步上升直到打满。解决思路是SQL优化不是加连接。加索引、改写关联条件、拆分大查询单次查询耗时降下来连接释放速度跟上池子自然就空了。经验排查慢SQL时可以顺手看下slow_query_log。MySQL的慢查询日志会记录执行时间超过long_query_time默认10秒的语句定位耗时SQL比盯processlist更持久、更全面因为processlist只能看到“当下恰好正在执行”的SQL。3.2 连接泄漏借了没还池子在慢慢饿死连接泄漏比慢SQL更隐蔽。慢SQL至少能通过processlist看见泄漏则完全看不见任何异常SQL——所有连接都处于Sleep状态但active就是下不来。最经典的场景是业务代码里写了这样的逻辑public void doBusiness() { Connection conn getConnection(); PreparedStatement ps null; try { // 执行SQL } catch (Exception e) { // 只处理了异常没有释放连接 } finally { // finally里又只关了ps没有关闭conn } }或者更隐蔽的从连接池拿连接时用了try-with-resources但内部又包了一层事务切面事务方法抛了异常后切面没有正确回滚并归还连接。连接泄漏的排查难点在于连接池里的active连接占比很高但这些连接看起来全都“空闲”。Druid有removeAbandoned机制HikariCP可以开leakDetectionThreshold实在不行就抓jstack看线程栈——泄漏的连接必然被某个线程对象持有顺着栈能看到是哪个方法打开了连接没关闭。3.3 大事务长时间持有连接大事务和慢SQL不一样慢SQL的耗时主要在SQL执行本身大事务的耗时可能SQL很快但因为在一个事务里执行了大量操作或者事务和外部RPC调用交织在一起导致事务迟迟不提交。举个典型例子Transactional public void createOrder(Order order, ListOrderItem items) { orderMapper.insert(order); // 调用库存服务扣减库存走HTTP耗时长 inventoryClient.deduct(order.getSkuId(), order.getCount()); items.forEach(item - itemMapper.insert(item)); }这个事务里嵌了一个HTTP调用假设库存服务平均响应200ms高峰期可能1秒以上。事务没提交之前数据库连接一直被占用。如果这种接口的QPS稍微上来连接池很快被打满。大事务的排查特征是show processlist看到连接处于Sleep状态但information_schema.innodb_trx里能查到对应的事务trx_started时间很旧事务里可能已经修改了若干行trx_rows_modified非零。大事务的解决方案不是数据库层面能解决的必须改代码把外部调用移出事务或者用PROPAGATION_NOT_SUPPORTED让外部调用不参与当前事务再或者把大事务拆成多个小事务。这个在本文第4部分会展开。3.4 数据库端连接数上限与池参数不匹配还有一种情况问题不在应用端而是MySQL的max_connections配置太小。比如一个Spring Boot服务配置maximumPoolSize30同时部署了4个实例那么这4个实例对同一个MySQL实例的合计连接数是30×4120。如果数据库的max_connections默认是151理论上还够但别忘了数据库自己还有系统连接、监控连接第三方工具如Navicat也会占用连接。当服务数再增多几套应用一起连同一个库很容易把max_connections顶破。连接池这一侧参数传的是“我要多少”MySQL这一侧参数决定的是“能给多少”。两边一旦不匹配应用侧的连接池会报HikariPool - Connection is not available数据库侧则会在错误日志里留下Too many connections的报错。提示确定数据库实际允许的最大连接数可以直接查SHOW VARIABLES LIKE max_connections; SHOW STATUS LIKE Threads_connected; SELECT max_connections;Threads_connected和max_connections的差值就是你的连接余量建议余量保持在20%以上。4. 解决方案技术手段与代码规范双管齐下4.1 池参数调优不要只调maxPoolSize先说结论连接池参数调整要遵循“够用、留余量、防止雪崩”的原则而不是无脑调大。我个人在Spring Boot HikariCP场景下的推荐配置如下spring: datasource: hikari: # 核心配置根据压测结果确定一般10~50之间 maximum-pool-size: 20 minimum-idle: 5 # 获取连接超时建议10秒以内过长的等待会拖死整个服务 connection-timeout: 10000 # 连接最大存活时间建议小于数据库wait_timeout max-lifetime: 540000 # 空闲超时 idle-timeout: 600000 # 连接泄漏检测超过10秒没归还就输出日志 leak-detection-threshold: 10000这组配置有几个关键逻辑需要解释maximum-pool-size这个数字不是拍脑袋定的建议压测得出来。简单估算公式是最大池大小 (单连接QPS × 峰值并发请求量) / 单连接可处理的最大请求数但实际中更靠谱的做法是拿生产环境高峰期流量做压测从10开始往上调找到“连接数增加但吞吐不再增长”的那个拐点。connection-timeout: 10000这个值要保守一点。如果业务SQL平均耗时是100ms正常情况拿连接肯定在毫秒级完成。一旦等了10秒还没拿到要么是池子真的满了要么是数据库hang了这时候快速失败比继续等待更安全——至少可以把错误信息抛出来让监控能盯到。max-lifetime: 540000MySQL的wait_timeout默认是8小时但连接池里的连接如果存活太久中间网络断一下、数据库重启一下连接就成了“坏连接”。max-lifetime让连接定期退役再新建立连接降低这种风险。leak-detection-threshold: 10000这个参数非常重要是探测连接泄漏的眼睛。一旦业务代码里某个线程借了连接超过10秒没归还HikariCP会在日志里打印警告包含栈信息直接告诉你“哪段代码泄漏了连接”。建议所有新项目都提前配上。Druid场景下的等价配置spring: datasource: druid: max-active: 20 min-idle: 5 max-wait: 10000 # 泄漏检测与回收开关 remove-abandoned: true remove-abandoned-timeout-millis: 10000 log-abandoned: trueDruid的removeAbandoned比HikariCP更激进它不仅打印日志还会强制将泄漏超时的连接从业务线程中回收掉。这个特性在生产环境要谨慎开——如果业务代码里存在真正耗时超过removeAbandonedTimeoutMillis的合法事务开了它会把正在执行的事务连接强制回收导致事务中断。建议先在测试环境开一段时间确认没有误杀再上生产。4.2 连接泄漏检测HikariCP的leakDetectionThreshold与Druid的removeAbandoned这里单独把连接泄漏检测拎出来说因为我踩过的坑里连接泄漏是最难揪又最容易在代码审查中被漏掉的问题。HikariCP的leakDetectionThreshold工作方式很有意思它并不是一个独立的检测线程而是在每次借出连接时记录时间戳当连接被归还时检查“借出时长是否超过阈值”。如果超过就输出一条包含调用栈的警告日志。所以实际效果是——泄漏发生后下一次归还连接时日志才会打印。它的意义不是“阻止泄漏”而是“把泄漏暴露在阳光下”。我建议线上环境统一开启这个参数因为哪怕只是日志级别泄漏时的调用栈信息也能帮开发省下几天的排查时间。Druid的removeAbandoned则更进一步。开启后Druid会启动一个守护线程周期扫描发现占用超过removeAbandonedTimeoutMillis的连接直接强制Connection.abort()从池子里移除并记录日志。被强杀的业务线程会收到Connection is closed异常SQL执行会失败——这是刻意为之目的就是快速暴露问题。我个人的建议是在测试环境把leakDetectionThreshold或removeAbandoned全部开启并设为较小值5~10秒来跑全链路测试上线初期可以保持开启等确认代码中没有泄漏后再把HikariCP的阈值调大或关闭Druid则把removeAbandoned关掉、保留logAbandoned。4.3 客户端调优与服务端配合应用端的调优做完了服务端的配合也不能少。这里说的服务端不是指MySQL的max_connections而是一整套配套措施。第一为应用单独建数据库账号限制最大连接数。比如给核心业务服务创建一个专用账号GRANT ALL ON app_db.* TO app_user%并设置MAX_USER_CONNECTIONS 50。这样即使某台服务器上的连接池配置失控也不会拖垮同一个MySQL上的其他业务。CREATE USER app_user% IDENTIFIED BY your_password; GRANT ALL PRIVILEGES ON app_db.* TO app_user%; ALTER USER app_user% WITH MAX_USER_CONNECTIONS 50;第二合理配置MySQL的wait_timeout和interactive_timeout。如果数据库默认8小时的wait_timeout没动连接池里的空闲连接会长期占用数据库资源。有些团队会把wait_timeout调成60秒甚至30秒强制空闲连接被MySQL主动断开——但要注意单纯的断开并不是归还应用端连接池需要自己处理“失效连接”所以HikariCP的maxLifetime应该比数据库的wait_timeout小比如数据库设60秒池里设max-lifetime: 54000毫秒。第三监控先行。连接池的监控指标一定要前置部署。HikariCP可以通过com.zaxxer.hikari.HikariDataSource的getHikariPoolMXBean()拿到activeConnections、idleConnections、waitingThreadsSpring Boot Actuator的/actuator/metrics/hikaricp_connections_active接口可以直接暴露这些指标。Druid有更友好的监控页面/druid/index.html和一套完整的StatFilter统计。这套监控的意义在于连接池爆满不是一瞬间发生的而是有一个逐渐累积的过程。如果只靠事后排查每次都要半夜爬起来登录服务器抓现场指标监控部署好之后你可以在active连接数超过maxActive的80%时提前收到告警在爆满之前介入。5. 事后复盘监控指标与上线验收5.1 我建议要盯的指标连接池相关告警如果只设置一个那就是active连接数的比例水位。HikariCP的监控指标形如hikaricp_connections_active // 当前活跃连接数 hikaricp_connections_idle // 当前空闲连接数 hikaricp_connections_pending // 正在等待连接的数量 hikaricp_connections_max // 池最大连接数告警规则我会这样设计当前活跃连接数 / 最大连接数 80%持续5分钟发Warning级别告警当前活跃连接数 / 最大连接数 95%持续1分钟发Critical级别告警等待线程数 0持续3分钟直接PG灵。pending这个指标很关键——活跃连接数高可能只是并发大但如果同时出现排队等待那一定是池子不够用了。注意区分“池活跃”和“池排队”两个概念。另外数据库侧的指标也要联动看Threads_connected已建立的连接数对比max_connectionsThreads_running正在执行的线程数一般远小于Threads_connected如果两者接近说明空闲连接很少、负载很高Slow_queries慢查询计数持续增长说明有慢SQL在拖后腿Innodb_row_lock_current_waits当前等待行锁的数量不是0就要警觉。这些指标可以统一接到PrometheusSecAlert/Grafana可视化即可。技术选型不强制关键是监控链路要通告警要能定位到具体服务实例。5.2 递归式复盘这次爆满的真正源头连接池爆满处理完我一般还会追问几个“为什么”避免下次换个姿势再来一遍。分享一套排查后的复盘清单为什么连接池会满——是慢SQL、是泄漏、是大事务、还是参数不匹配为什么慢SQL/泄漏会流到生产——代码Review没发现测试环境没有全链路压测为什么监控没有提前发现——告警阈值太高指标没接入还是没有人盯告警为什么紧急扩容没有生效——当时直接加减实例还是加连接池大小数据库有没有扛住比如有一次我处理完连接池爆满后复盘发现根因是一个新上线的列表接口在for循环里逐条查询数据库单请求产生几十次查询高峰期直接打爆连接池。代码Review没拦下来压测又只跑了功能测试没跑峰值流量。后续整改就两件事把N1查询改成IN批量查询压测流程补上峰值流量场景。改完之后连接池active水位从95%降到20%以下。复盘的价值不在于写一篇事故报告而在于把问题一层层把到根上把流程漏洞补齐让同类问题失去复现空间。最后再聊一个细节。很多人在解决连接池问题时会优先去数据库侧调max_connections、调wait_timeout这没有错但我更建议先从应用侧排查。原因很简单数据库是共享资源一个服务的连接池爆满遭殃的可能不止一个服务。提前在应用侧做连接池参数验证、做泄漏检测、做全链路压测远比在数据库层面做兜底省心得多。连接池问题看着猛其实只要把“排查链路”走一遍大多数都能在半小时内定位到根因。真正难的不是解决问题而是建立一套机制让问题在发生前就被指标和规范拦住。