1. 事故现场连接池干涸业务线程排队等连接那天下午两点多服务群突然开始刷屏订单接口超时率直接跳到百分之四十多调用方一个接一个地来问情况。我第一反应是数据库出了问题赶紧打开数据库监控结果CPU、内存、慢SQL、锁等待全都正常。再回头看我们自己应用的监控一个平时不怎么起眼的指标炸了——Druid连接池的activeCount稳稳顶在maxActive上后面还排着几百个线程在等getConnection()。这个场景如果你也遇到过应该能体会那种感觉数据库本身活得好好的但你的应用就是拿不到连接所有请求像堵在收费站外的车流一样一动不能动。这篇文章不是讲Druid怎么配置入门而是把一次真实的线上事故从头到尾复盘一遍——现象是什么、怎么一步步定位到根因、中间踩了哪些参数的坑、最后怎么调整配置和治理才让系统稳住。如果你负责的Java服务也在用Druid做连接池尤其是线上出现过超时飙升、连接池爆满但不知道从哪下手的情况这篇内容应该能帮你省掉不少弯路。1.1 一开始以为是数据库扛不住其实是池子先被抽干了事故刚发生时团队的第一反应和我一样先查数据库。因为接口超时的表象太像数据库问题了——请求普遍耗时从几十毫秒涨到几秒错误日志里大量CommunicationsException、Connection is not available, request timed out这类报错。但数据库侧的各项核心指标都在安全水位内QPS没有明显上涨慢SQL数量和平时差不多InnoDB的行锁等待、buffer pool命中率、磁盘IO都没有异常。这时候我开始把怀疑对象转向应用自身的资源瓶颈打开应用监控一看Druid的监控数据把问题暴露得很明显指标平时水位故障时activeCount10-2050满poolingCount池中空闲数20-300waitCount0持续增长获取连接等待时间毫秒级数秒到超时也就是说池子里已经没有任何空闲连接可以借出所有新请求都在排队等待而数据库自己其实远没到瓶颈。这就是Druid连接池干涸的标准特征池子本身成了系统的瓶颈点而不是数据库。1.2 快速止血只能撑半小时重启给了我们重要的排查窗口当时线上第一反应是重启应用。重启后确实立竿见影接口恢复但大约半小时后同一症状再次出现错误率又开始往上爬。这基本可以确定问题不在代码加载阶段而是运行时某种行为在持续消耗连接。我也试过临时调大maxActive从50调到100、再调到200效果都只是把爆炸时间点往后推了一些。因为如果每个连接被占用的时间足够长池子再大也迟早被填满只是时间问题。这次短暂的重启窗口成了我们定位问题的关键机会。趁着系统刚恢复、连接池还没被完全挤爆我抓了几份线程Dump和Druid的实时监控页终于还原出了整个链路的问题。2. 线程Dump还原现场一半线程卡在getConnection上Druid自带一个监控页面StatViewServlet能直接看到每个连接当前由哪个线程持有、SQL执行状态、连接创建时间等信息。配合jstack抓线程栈事故的轮廓很快就清晰了。2.1 线程Dump里的典型PatternWAITING线程围堵getConnection拿到线程Dump后我快速统计了线程状态分布结果非常典型约40%的业务线程处于WAITING状态栈顶都停在com.alibaba.druid.pool.DruidDataSource.getConnection()的takeLast/pollLast等待上。约30%的线程是RUNNABLE正在执行SQL但其中有相当一部分执行的不是简单的CRUD而是某个业务方法里的第一行语句。剩下的线程在TIMED_WAITING或处理其他非数据库逻辑。这个分布基本说明了问题大量线程进不来少数线程拿着连接不撒手。我挑了几个RUNNABLE线程看完整堆栈发现它们都卡在同一个业务方法里——一个订单处理流程入口方法上标注了Transactional而方法内部有一段调用外部HTTP接口的逻辑。getConnection()排队等待这件事本身不是病根它只是结果。真正的病根是连接被持有太久导致池子无法周转。2.2 慢事务加外部调用连接被合法地占着不还我们复盘了那段业务代码结构大概是这样一个逻辑接收订单消息后开启事务先更新订单状态然后调用外部风控/积分服务HTTP拿到结果后继续更新库存、生成流水最后提交事务。外部HTTP调用的平均耗时在800毫秒左右极端情况甚至到3秒。而一个数据库连接从getConnection()到事务提交整个过程持有了多长时间启动事务前拿连接、外部调用期间连接一直挂在事务里、最后提交才释放——也就是一次请求平均占用连接超过800毫秒。再算笔账业务峰值QPS大约2000。其中约20%的请求会走这条包含外部调用的慢事务链路也就是400 QPS。400 QPS × 0.8秒平均持有时间 320个连接被这条链路长期占用。其余80%的请求虽然快平均100毫秒也需要 1600 × 0.1 160个连接。合计峰值大概需要480到500个连接才能正常周转。而我们当时的maxActive只有50供需缺口接近十倍。连接池在这种情况下只能像一个过于狭窄的漏斗所有请求堵在入口处排队排队超过maxWait就直接抛GetConnectionTimeoutException接口大面积超时。这个案例里最值得警惕的一点是没有慢SQL没有死锁代码也没写错一切都在按业务逻辑正常执行但池子就是被这种合法占用给拖垮了。2.3 remove-abandoned为什么没能兜住这个坑看到这你可能会问配置里不是开了remove-abandoned: true吗不是应该自动回收泄漏的连接吗这就是我们当时踩的一个认知误区。remove-abandoned的机制是Druid后台会周期性地扫描池里的连接如果某个连接被持有未归还的时间超过removeAbandonedTimeoutMillis的阈值就认为这个连接被遗弃了然后强制回收。但关键在于Druid无法判断一个连接是被业务正常使用但执行慢还是被业务代码忘了关闭导致泄漏。在慢事务场景下连接虽然持有时间长但每隔几十毫秒都有SQL在执行或等待外部响应后再执行下一步SQL连接一直处于活跃使用状态Druid不会对它动手。反过来说如果一个连接真的超过阈值没有任何SQL活动被强制回收后还有可能把正在执行的SQL直接打断导致事务回滚或数据不一致。所以remove-abandoned本质上是兜底用的最后手段它防不住慢事务也无法作为常规治理手段来依赖。3. 被合理参数埋掉的坑remove-abandoned、maxActive和日志Filter的连锁反应定位到根因后我们开始审视全套Druid配置。不看不知道很多问题其实是多个看起来合理的参数组合在一起慢慢把池子逼到崩溃边缘的。3.1 remove-abandoned的副作用远比你想象的严重这次事故之后我把remove-abandoned相关参数翻来覆去研究了一遍也查了不少社区案例这里总结几个容易踩的坑。第一慢任务误杀。removeAbandonedTimeout如果设置得太小比如60秒而业务里恰好有合法的大事务——批量导入、报表导出、定时任务——执行时间超过60秒Druid后台检测到连接很久没归还会直接强制回收连接正在执行的业务SQL被中断事务回滚。如果恰好是半夜的批处理任务第二天早上你才会发现数据缺了一大块。第二被回收的连接状态不可控。Druid回收遗弃连接时并不会等待该连接上的SQL执行完毕而是直接标记连接为废弃并归还池子。这条连接底层的socket可能还处于半通信状态如果后续某个线程借到这条连接继续使用就会遇到奇怪的SocketTimeoutException、Packet corrupt等异常极难排查。第三检测机制自身的开销。开启remove-abandoned后Druid会启动一个异步扫描任务每次扫描需要遍历池中所有连接并检查活跃时间。在高并发大连接数场景下比如500个连接以上这个扫描本身会消耗可观的时间片还可能因为争抢锁导致连接获取路径出现不必要的竞争。我们曾经在高并发压测时对比过开关remove-abandoned对P99的影响开了之后P99大约多了15到20毫秒。所以我的建议是生产环境尽量不开remove-abandoned的自动回收只开log-abandoned让连接泄漏问题在日志里暴露出来由人工介入处理而不是让框架替你做可能有副作用的强制动作。3.2 maxActive拍脑袋设置的缺口以及maxWait的放大器效应我们当时的maxActive50是怎么来的说实话是早期联调测试时按并发50个够了吧的直觉填的。这就是问题所在——连接池容量必须按峰值QPS × 平均事务持有时间来估算而不是按并发用户数或线程数来拍。我在第2.2节里已经算过我们当时的业务模型需要接近500个连接才能正常周转。50和500之间差了10倍这种数量级的缺口不是调优能解决的必须从业务侧和配置侧同时改。而maxWait这个参数在事故中起到了放大器的作用。当时maxWait10000即最多等10秒。在池子干涸时每个请求都排队等到接近10秒才超时这期间线程池的工作线程全部被阻塞。Tomcat默认的maxThreads200很快200个线程全部卡在等待连接上新的请求连线程都分配不到服务等于整体不可用。正确做法是maxWait不要设置得太长一般3000到5000毫秒足够。宁可快速失败让上游感知到后端服务压力过大走重试或降级也不要让所有线程长时间阻塞形成雪崩。3.3 很多Druid崩了的表象其实是日志和监控Filter先撑不住了排查过程中我还发现另一个被忽视的问题Druid启动加载了一堆filters包括stat、wall、slf4j日志Filter。每个filter都在连接和SQL执行路径上增加额外开销。stat监控Filter本身问题不大但要注意logSlowSql和日志输出频率。我们当时开启了Slf4jLogFilter在高并发下每个SQL都会打印日志日志文件以每分钟几百兆的速度增长直接把磁盘写满。磁盘满了之后业务线程阻塞在日志写入上数据库连接自然也被占住不放——又是一个连接池爆了的假象。wall防火墙如果配置不当也有风险。它会对每条SQL进行语法解析和白名单校验高并发下CPU开销明显。而且如果规则写得太死合法SQL可能被误拦截导致一批请求在事务里长时间处理反而制造慢事务。所以这里有个原则Druid的filter不是越多越好按需加载。常规生产环境stat用于监控就够了确实有SQL注入防护需求再上wall日志Filter一定要限制输出频率或干脆关掉。4. 生产级Druid配置复盘参数逐个说明白先说结论这次事故之后我把Druid连接池的参数体系完整梳理了一遍结合压测结果和业务特点重新设计了一套配置。这套配置不一定适合所有场景但每个参数背后的逻辑你可以直接参考。4.1 一套可以直接抄作业的配置模板下面是我们目前生产环境使用的Spring Boot Druid配置YAML格式spring: datasource: druid: initial-size: 10 min-idle: 10 max-active: 200 max-wait: 3000 validation-query: SELECT 1 validation-query-timeout: 3 test-while-idle: true test-on-borrow: false test-on-return: false time-between-eviction-runs-millis: 30000 min-evictable-idle-time-millis: 60000 max-evictable-idle-time-millis: 300000 keep-alive: true phy-timeout-millis: 60000 remove-abandoned: false log-abandoned: true filters: stat,wall connection-properties: druid.stat.mergeSqltrue;druid.stat.slowSqlMillis500关键参数的选取逻辑和技术依据如下参数设置理由initial-size / min-idle10应用启动后预建少量连接避免冷启动时瞬时请求全去建连max-active200由压测得出的合理峰值水位约为算出的500需求量的40%通过业务侧优化降低持有时间后够用max-wait3000快速失败优先防止线程池被长时间占满导致雪崩test-while-idletrue空闲连接在后台任务中定时校验兼顾性能和连接有效性test-on-borrowfalse每次借出都校验会放大到数据库压力不必要time-between-eviction-runs-millis30000每30秒跑一次空闲连接检测在数据库wait_timeout限制下足够及时min-evictable-idle-time-millis60000空闲超过60秒且min-idle有富余时才回收防止频繁建连keep-alivetrue保证池内连接长时间不被数据库服务端主动断开remove-abandonedfalse放弃自动回收机制用log-abandoned记录泄漏情况人工介入phy-timeout-millis60000物理连接最大空闲时间配合keep-alive维持稳定链路这里重点解释两个容易被忽略的细节。max-active我特意没有直接设成500。因为单纯把池子放大到够用只会暂时掩盖问题池子里长期驻留几百条连接本身对数据库也是一种负担。我们同步做了业务侧优化——把事务内的外部HTTP调用移到事务外通过消息队列或异步任务解耦硬生生把平均持有时间从800ms压到不到50ms。业务优化之后再压测200的连接水位已经绰绰有余。keep-alive值得单独说一句。数据库服务器一般有wait_timeout设置比如默认8小时超过这个时间空闲的物理连接会被服务端断开。如果连接池没感知到这个变化客户端拿到的连接其实已经是一个死连接第一次使用就会报错。开启keep-alive后Druid会定期发送探测语句保证连接存活避免这种情况。4.2 数据库密码加密与连接泄漏检测的稳妥方案除了连接池核心参数顺带把两个经常被忽视的点一起说了。第一数据库密码不要明文写在配置文件里。如果你用的RuoYi框架集成Druid或者是自建的Spring Boot项目都可以用Druid自带的ConfigFilter实现密码加密。原理是先通过Druid提供的工具类生成公钥和密文密码然后在配置里指定spring: datasource: druid: filters: config,stat,wall connection-properties: config.decrypttrue;config.decrypt.key${DRUID_PUBLIC_KEY}${DRUID_PUBLIC_KEY} 从环境变量或配置中心读取不要把公钥直接硬编码进配置文件。密码明文一旦泄露意味着数据库等于裸奔尤其是线上环境容易被批量扫描攻击。我用过一段时间也踩过坑ConfigFilter的connection-properties里如果同时存在druid.stat.*和config.decrypt.*会比较容易因为分号分隔符或空格问题导致配置没生效。建议先单独只配filters: config验证解功能正常再叠加其他filter。第二连接泄漏检测采用只记录不回收策略spring: datasource: druid: remove-abandoned: false log-abandoned: true remove-abandoned-timeout: 180这样配置后如果业务代码存在连接泄漏Druid会在日志中打印abandoned connection告警我们通过日志监控发现并及时修复而不是让Druid自动强制回收。自动回收机制在上一节已经分析过副作用这里就不再重复了。4.3 上线前必须做的验证压测和灰度配置改完之后不能直接在线上生效必须有一套验证流程。我们当时做了三件事第一步全链路压测。用JMeter或Gatling把峰值流量打进去观察Druid监控页面的指标activeCount是否接近max-active上限、waitCount是否长期大于0、获取连接等待时间的P99是否在合理范围内。压测时要特别关注热点场景——那些长事务、慢事务触发的请求因为它们才是池子枯竭的主力。第二步灰度发布。先让一个边缘节点加载新配置观察4小时以上确认业务无感、连接池水位健康再逐步把所有节点刷完。这里要提醒一句连接池参数变更属于运行期配置变更灰度时最好在新老节点并存的情况下观察对比不要同时全量发布。第三步连接池体检检查。上线后第15分钟、30分钟、1小时各检查一次Druid监控页确认连接创建数、销毁数、池中空闲数、活跃数的分布合理。如果发现连接频繁创建销毁说明min-idle或空闲回收时间设置得不够合适需要微调。5. 长期治理没有监控的池子就是在裸奔配置调整解决了这次事故的直接原因但复盘会上我们达成了一个共识一次事故根因是慢事务但如果监控和规范到位这个问题早在压测阶段就该暴露。连接池的稳定性本质上是监控体系、代码规范、应急机制三件事共同作用的结果。5.1 把连接池指标纳入监控体系Druid内置的监控页面StatViewServlet是排查利器但它只是事后取证用的不能替代持续监控。必须把连接池的健康指标接入你的监控告警平台。需要盯的核心指标包括activeCount当前活跃连接数超过max-active的70%就要关注poolingCount池中空闲连接持续为0说明池子开始吃紧waitCount和notEmptyWaitMillis获取连接等待的次数和累计等待时间连续出现等待说明供给不足connectCount/closeCount连接创建和销毁频率异常波动说明配置或SQL有问题errorCount连接获取或使用时发生的错误次数Spring Boot项目可以通过引入spring-boot-starter-actuator并把Druid的指标暴露到Prometheus或者直接用Druid监控页的JSON API定时拉取。我们当时用Prometheus Grafana做了一套连接池仪表盘每条业务线都能看到自己的连接池水位告警规则按活跃连接数连续5分钟超过上限70%来设置。5.2 代码层的防泄漏规范监控只能发现问题规范才能减少问题。复盘之后我们定了几条硬性要求事务方法内禁止调用RPC或HTTP接口。如果业务流程必须依赖外部服务结果通过异步处理、消息对账或最终一致性方案解耦而不是在事务里同步等待。这是本次事故最核心的代码层整改项。数据库操作统一使用try-with-resources或依托框架的资源管理手动获取Connection时必须确保finally中释放。Druid的log-abandoned此时发挥价值——它会告诉我们哪条连接可能泄漏了帮助快速定位代码位置。事务注解要标注rollbackFor避免只处理RuntimeException而漏掉受检异常导致事务不回滚、连接迟迟不释放的情况。5.3 应急预案连接池水位分级告警与处置动作有监控有规范还不够真出事的时候团队需要在最短时间内执行预定的处置方案而不是现场开会讨论。我们定了三级预案级别触发条件处置动作P3activeCount 超上限70%持续5分钟通知值班检查慢事务、外部调用排查近期发布P2waitCount持续增长 或 等待P99 1s拉群沟通必要时应急调整maxActive触发慢查询分析P1连接获取超时、接口错误率上升立即启动快速降级摘除故障节点按预案恢复连接池水位P1时最有效的应急手段是直接对问题节点执行连接池清空重建可以通过Spring Boot Actuator自定义一个端点来触发DruidDataSource.restart()而不是整个应用重启。这个操作耗时短、对业务影响小能在几十秒内释放当前所有被占用的连接。我个人在实际操作中的体会是连接池这个组件平时太老实不出事的时候你几乎感觉不到它的存在但它其实是数据库和应用之间最重要的一道闸门。经历过这次事故我给自己定了一条规矩Druid参数变更一律走压测评审生产环境只开log-abandoned不自动回收连接池水位必须进监控大屏。这三件事做好大部分连接池引发的线上事故都能在早期被发现而不是等到炸锅后才手忙脚乱。最后分享一个排查小技巧如果哪天线上连接池突然爆满先不要急着重启第一时间抓一份线程Dump和Druid监控页截图。线程Dump能告诉你线程卡在哪Druid监控页能告诉你哪些连接被谁持有、持有了多久。这两个数据组合起来基本可以定位90%的连接池问题。记住重启一时爽但问题还在找到根因才是真正的解法。