做Java后端的基本没人能绕过数据库连接池这道槛。项目一跑起来连接池就是数据库访问的咽喉而Druid这个名字在很长一段时间里几乎是国内后端项目的默认选项。这篇就把Druid的核心设计、参数配置、监控玩法以及我实际踩过的坑一次讲透想让刚接触连接池的朋友少走弯路也给正在调优的人一些可抄的配置思路。1. 为什么是连接池又为什么是Druid1.1 没有连接池时数据库连接为什么扛不住先回到最基础的问题连接到底贵在哪。一个数据库连接的建立底层是一次TCP连接涉及三次握手、数据库鉴权、资源分配这一套走下来在局域网里可能只要几毫秒到几十毫秒但在高并发场景下每次请求都“现开现关”开销会被放大到让你怀疑人生。我见过一个真实项目最开始用了自研的“每次查询新建Connection”的写法压测到200并发时数据库连接数瞬间飙到上千数据库端连接线程直接被打满后端接口响应从20ms变成3秒。后来改成连接池同样200并发活跃连接稳定在30左右响应时间恢复到40ms以内。差异就在“复用”两个字上。连接池做的事本质上就是提前把一批连接创建好、放着备用请求来了从池子里借用完还回去而不是销毁。更重要的是连接池可以通过“保活检测”和“空闲回收”机制让池里的连接始终是健康的避免拿到一个已经被数据库端断开但TCP还没感知到的死连接。1.2 Druid 不只是连接池它与 HikariCP、C3P0 的差异Druid经常被拿来跟HikariCP、C3P0、dbcp对比。如果只看性能和连接管理能力HikariCP的吞吐确实非常猛字节码级别做了大量优化Spring Boot 2.x之后也默认把它作为数据源。但Druid能火靠的显然不是单纯的性能。对比项DruidHikariCPC3P0 / dbcp连接池基础能力完整完整完整监控面板内置StatViewServlet指标丰富有轻量指标需额外集成弱基本靠日志SQL级统计支持慢SQL、执行次数、并发数不直接支持不直接支持SQL防火墙WallFilter可拦截危险SQL无无数据库密码加密ConfigTools无需改代码需结合外部方案需结合外部方案性能略低于HikariCP但靠监控挽回极高一般Druid更像“连接池 监控运维工具”的结合体。它默认能输出SQL执行情况、连接分布、等待次数、慢SQL明细、Session列表。很多团队喜欢它其实是被它的可观测性吸引的线上出问题的时候打开Druid监控页一眼就能看出是慢SQL拖慢了接口还是连接没归还导致池子耗尽。1.3 选型和取舍什么时候该选 Druid我个人的标准很简单如果你的项目是内部系统、管理后台或者对数据库运行状态有强监控诉求那Druid是很好的选择。如果你做的是纯高并发互联网API追求极致性能HikariCP配合中间件监控也能用但你可能就要舍弃SQL维度的直接视图。结合国内开发者的习惯用Spring Boot MyBatis的团队Druid几乎做到了开箱即用依赖引入后配置几分钟就能看到监控面板。你完全可以在项目初期先用Druid把监控体系建立起来等上线稳定后再评估是否有必要为了那百分之几的性能换掉它。我的建议是不要人云亦云追求极致性能先把问题看清楚连接池这块三板斧Druid给得最全。2. Druid 核心配置逐项拆解2.1 连接数参数initialSize、minIdle、maxActive 到底怎么定Druid最常被讨论的就是这几个连接数参数。很多人在配置时直接抄模板从不关心数字背后的逻辑。先说结论没有“万金油参数”只有“适合你的参数”。initialSize启动时初始化的连接数。我一般设置成5或者10不用太大毕竟刚启动时并发通常不高连接是懒加载的用完再慢慢补。minIdle池中保底空闲连接数。这个值决定了低峰期池子至少留几条连接。设得太高低峰期也在白占数据库资源设得太低忽然来一波流量需要重新建连可能会扛不住瞬时压力。maxActive池中最大活跃连接数。这是最核心的约束建议根据“单条连接能支撑的并发请求数”和“预估QPS”来倒推。举例来说假设单连接每秒能处理50个SQL业务预计峰值2000 QPS那么预留40~50条连接是合理的。设太大会让数据库端连接线程过载太小又会在DB空闲时因为排队而拖垮接口。maxWait池中没有可用连接时获取连接的等待时间单位毫秒。超时后抛出异常而不是无限阻塞。这个值我习惯设60000既给了排队请求一定的容忍时间又能在池子彻底满时快速失败暴露问题。一个常见误区是以为maxActive越大越好。数据库连接数跟数据库自身的并发能力是强相关的一台MySQL的并发连接建议值是几百以内连接远多于CPU核心数反而会让线程调度开销变大甚至出现大量“sleep”连接占着资源不干活。把maxActive压到合理范围反而能倒逼你优化SQL和业务逻辑。2.2 连接保活与测试参数testWhileIdle 的平衡点这一组参数是Druid的灵魂也是最容易配置错的地方。validationQuery用来探测连接是否有效的SQL。MySQL用SELECT 1Oracle用SELECT 1 FROM DUAL。这条SQL会真实执行所以不能太重。testOnBorrow每次借出连接时是否做有效性检测。true的话最安全但每条连接借出都多一次探测性能开销明显。如果业务链路对性能敏感建议改成false。testWhileIdle连接空闲时是否做检测。这个可以设计成true配合timeBetweenEvictionRunsMillis和minEvictableIdleTimeMillis一起用代价很低收益很实在。timeBetweenEvictionRunsMillis空闲连接检测的执行周期默认60秒意思是每隔1分钟跑一次“体检”把连接池里空闲太久的连接关掉并重启到minIdle数量。minEvictableIdleTimeMillis连接最大空闲时间默认30分钟只有空闲超过这个时间的连接才会被回收。常用的配置套路就是testOnBorrowfalsetestWhileIdletruevalidationQuerySELECT 1让检测交给后台线程统一做避免每次借出连接都多一次额外往返。很多人踩过一个坑有的数据库因为网络中断连接已经失效但客户端不知道如果没有testWhileIdle和后台回收下次借出时拿到的是一条死连接执行任何SQL都直接报错排查半天还未必想到是连接池的问题。2.3 Spring Boot 下的最小可用配置模板给一份我项目里稳定跑了很久的配置基于druid-spring-boot-starter可以直接参考spring: datasource: type: com.alibaba.druid.pool.DruidDataSource driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/demo?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: xxxx druid: initial-size: 5 min-idle: 5 max-active: 20 max-wait: 60000 time-between-eviction-runs-millis: 60000 min-evictable-idle-time-millis: 300000 validation-query: SELECT 1 test-while-idle: true test-on-borrow: false test-on-return: false pool-prepared-statements: false filter: stat: enabled: true log-slow-sql: true slow-sql-millis: 2000 wall: enabled: true slf4j: enabled: true这里要说明几个容易被理解和配置错的地方pool-prepared-statements是用来缓存PreparedStatement的开启后确实能省一部分SQL预编译开销但会占用额外内存。在连接数多、SQL量大的场景下不建议盲目开。默认关闭是合理的。filter下面的配置控制的是Druid的各类扩展过滤器stat负责统计监控wall负责SQL防火墙slf4j负责把执行SQL打到日志里。注意这些filter跟纯Druid的原生配置文件的写法不同Spring Boot下用这种yml嵌套结构更方便。提示不要在生产环境照抄max-active20这个值请回到2.1那节按自己的并发模型重新算一遍。我给的模板是通用的起点不是最终答案。2.4 一组值得收藏的参数速查表参数默认值建议参考值参数作用initialSize35 ~ 10启动时初始连接数minIdle15 ~ 10最小空闲连接数maxActive820 ~ 100 视压测而定最大活跃连接数maxWait-130000 ~ 60000最大获取连接等待时间-1为无限等待timeBetweenEvictionRunsMillis6000060000空闲检测周期minEvictableIdleTimeMillis1800000300000 ~ 600000空闲连接最大存活时间validationQuery无视数据库类型而定探测SQLtestWhileIdlefalsetrue空闲时检测连接是否有效testOnBorrowtruefalse借出时检测连接是否有效testOnReturnfalsefalse归还时检测连接是否有效removeAbandonedfalse视场景开启自动回收被遗弃的连接logAbandonedfalse建议true记录被回收连接的堆栈信息removeAbandoned是双刃剑当连接被代码借用后没归还时Druid可以强制回收。线上关掉只在定位连接泄露问题时开了配合logAbandoned用否则很容易误杀还在执行长任务的连接。3. 监控、防火墙与扩展功能实战3.1 开启监控页StatViewServlet 与 WebStatFilter 的配置Druid的监控页是很多人喜欢它的直接原因。在Spring Boot里开启监控页只需要加上这么一段spring: datasource: druid: stat-view-servlet: enabled: true url-pattern: /druid/* login-username: admin login-password: admin123 reset-enable: false web-stat-filter: enabled: true url-pattern: /* exclusions: *.js,*.css,*.gif,*.jpg,*.png,*.ico,/druid/*开启后访问/druid/index.html就能看到控制台里面能看数据源状态、SQL监控、SQL防火墙、Session监控等信息。这里有三个经验要分享第一reset-enable一定要设成false否则页面上一个“重置”按钮就能把所有统计清零线上数据就白统计了。第二监控页必须能登录并且密码别用弱口令。这个页面暴露了你的完整SQL语句和库表结构是攻击者的高价值目标。第三如果项目使用了Spring Security或Shiro别忘记把/druid/**路径加进白名单或者额外做一层防护否则会出现“首页能开监控页但登录接口都调不通”的诡异现象。监控页的几个核心指标怎么看活跃连接数如果长期接近maxActive说明池子偏小或者存在连接泄漏。SQL执行次数、执行时间分布能快速找出慢SQL和高频SQL。连接等待次数如果等待次数持续增长说明连接竞争很激烈。3.2 慢SQL定位阈值怎么设才不误报慢SQL监控是排障效率最高的一环。配置里设置spring: datasource: druid: filter: stat: enabled: true log-slow-sql: true slow-sql-millis: 2000slow-sql-millis设成2000意思就是SQL执行超过2秒就记录到日志。这里要注意一个反直觉的点阈值别设太低比如100毫秒。很多公司的测试环境SQL执行几十毫秒很正常但一上生产环境受CPU、锁竞争、网络波动影响超过100毫秒的SQL一抓一大把日志会被刷爆反而淹没了真正的问题SQL。我见过一个项目把慢SQL阈值设成了500毫秒日志里全是“慢SQL”但没有一条是真正的性能隐患。后来改成了3000毫秒捞出来的都是确实需要优化的比如全表扫描、大分页、嵌套循环查询。建议慢SQL日志从2秒起步等上线稳定后再根据业务情况逐步收紧到1秒。日志里出现慢SQL之后下一步是把它从Druid监控页的SQL列表里找到原始SQL语句看执行计划用EXPLAIN分析索引命中情况。Druid自带功能只能暴露问题真正解决问题还是要回到数据库侧。3.3 WallFilterSQL防火墙防注入WallFilter是Druid很有特色的功能它本质上是一个SQL语法分析器在SQL真正执行前做一次“安检”阻止不确定的、有风险的语句进入数据库。启用方式就在filter配置里加一行spring: datasource: druid: filter: wall: enabled: true它拦截的典型行为包括select *这种不带条件的全表扫描没有WHERE条件的DELETE/UPDATE整表操作INSERT INTO一次性插入超大结果集禁止多条SQL用分号拼在一起执行阻止部分SQL注释变体绕过过滤器的行为关于WallFilter要泼一点冷水它不是万能的不能完全替代代码层的SQL参数化校验。对于MyBatis这种框架生成的SQLWallFilter基本够用但对于复杂业务里的动态SQL拼接、存储过程调用、特殊语法WallFilter可能会误伤。所以生产环境开启后要有“偶尔会误拦”的心理准备。我当时接入时有一类合法SQL被拦了某个老系统用了INSERT ... ON DUPLICATE KEY UPDATEWallFilter对某些版本的语法解析不完整直接报错。最后在配置文件里针对该连接增加了wall的insert配置放行才解决。遇到这种场景先看日志确定具体拦截规则不要一上来就全局关闭WallFilter。3.4 ConfigTools 密码加密让数据库口令不再裸奔Druid里最容易被低估的是ConfigTools它可以在不写代码的情况下给数据库密码做非对称加密。使用方式很简单命令行执行java -cp druid-1.2.20.jar com.alibaba.druid.filter.config.ConfigTools yourpassword执行后你会得到私钥、公钥和一个加密后的密文。然后配置改成这样spring: datasource: username: root password: 密文 druid: filter: config: enabled: true connection-properties: config.decrypt: true config.decrypt.key: 公钥这里有几个容易踩的点第一config.decrypt.key配的是公钥不是私钥。私钥只在生成密文时短暂出现生成完就该销毁别把它留在配置文件里。第二Spring Boot的druid-spring-boot-starter里connection-properties的写法是上面的yaml形式但如果你用的是纯Druid原生配置要写成connectionPropertiesconfig.decrypttrue;config.decrypt.key公钥注意是分号分隔。有一点要承认这种加密不是绝对安全因为解密用的公钥就在配置文件里真正攻入服务器的人仍然能拿到密钥。但它能解决一个实际问题配置文件被传到Git仓库、被截图发到群里、被运维脚本误打印时数据库口令不会直接泄露。这个成本很低建议所有项目都做。4. 真实环境中容易踩的坑与排查实录4.1 连接池耗尽activeCount 一直顶在 maxActive 时怎么办这是Druid最常见的生产事故。表现是接口开始大面积超时应用日志里出现wait millis 60000, active 20之类的异常。Druid监控页会显示activeCount长期等于maxActivewaitThreadCount持续增长。排查思路按照这个顺序来第一看Druid的SQL监控页是不是出现了某个SQL的执行时间暴涨。一个慢SQL如果执行10秒那在100并发下瞬间就会消耗掉几百条连接直接把池子打满。第二看连接获取后是否正常归还。写一段日志监控代码在DataSource.getConnection()后打印当前线程堆栈过一段时间再对比哪些线程还握着连接不放。或者在代码里临时加上removeAbandonedtrue和logAbandonedtrue让Druid在连接被遗弃时打印出当时的调用堆栈定位到具体代码行。确认问题后再关掉removeAbandoned。第三看数据库侧有没有一堆sleep连接。MySQL执行show processlist如果大量连接处在Sleep状态且持续很久基本是业务代码获取连接后没有关闭或事务超时时间设太长。有一次对方团队自查了三天没结果最后我在他们的连接获取入口打点发现是个事务方法里调了一个外部HTTP接口外部接口响应超时30秒而事务一直开着里面唯一一条数据库连接被占着不放。并发一高池子瞬间满了。4.2 连接泄露定位getConnection 之后没 close 的典型症状用Druid连接池的团队代码里经常出现“只在finally里closeResultSet忘了closeConnection”的情况。这在连接数不多时表现不明显但上线久了之后连接池必然出问题。定位泄露有两条路一是执行show full processlist看哪个应用IP的连接特别多且长时间Sleep二是用Druid的logAbandoned开关。logAbandonedtrue会在回收连接的时候打印出该连接最后一次被借用的业务堆栈这比盲目review代码高效得多。等日志捞出来再关掉。更重要的是从根上避免现在主流的做法是拥抱spring-boot-starter-jdbc里的DataSourceUtils或直接交给MyBatis / JPA的事务Template管理连接。宁可让框架管也别自己手写Connection因为手写意味着你要在每一个异常路径上都记得释放。曾经接手过一版代码用了try (Connection conn dataSource.getConnection())这种写法看起来没问题但里面又包了try ... catch返回jsoncatch里忘了关闭照样泄露。4.3 频繁 TIME_WAIT池子没复用连接的问题有段时间线上MySQL的ss -ant里能看到应用服务器到数据库端口有大量TIME_WAIT连接每秒几十个增加。这说明底层TCP连接根本没有被复用一直在创建新连接、关闭旧连接。连接池表现得像没起作用一样。核心原因通常是连接池的实际活跃连接数没到急着创建新连接的时候但连接却在被反复创建销毁。仔细排查后发现是socketTimeout或connectTimeout设置太短一条连接在空闲期间被数据库端通过wait_timeout切断了Druid后台还没轮询到它下次请求一来发现它不可用只能新建建完之后又不用继续被超时杀掉陷入循环。解决办法把timeBetweenEvictionRunsMillis调小一点比如30秒把minEvictableIdleTimeMillis调到小于数据库wait_timeout的值确保后台能在连接被数据库杀掉之前检测到并替换。同时可以适当调大testWhileIdle的频率让空闲连接一直在心跳保活。4.4 多数据源切换的坑事务一开DS 就失效做多数据源项目时很多人用DS注解做数据源路由。这里有个很隐蔽的坑一旦方法上加了Transactional事务管理器会在进入方法时就决定好使用哪个数据源后续DS的切换会全部失效。结果就是数据写到了错误的库里还半天查不出来。Druid在实际多数据源场景中的角色通常是提供多个独立的DruidDataSourceBean然后由一个路由数据源在运行时按key切换。事务一旦开启连接是在事务开始时从特定数据源拿的后续业务代码里的路由注解根本无法影响当前线程已绑定的连接。规避手段很简单把跨库操作拆成多个短事务方法事务边界的上层不写DS在真正访问数据的那一层再切换数据源与开启事务。做不到拆分的话就要自己管理连接和事务边界复杂度会上一个档次。很多时候报“事务失效”其实不是Druid的问题而是Spring事务传播机制和动态数据源路由的兼容性没有理清。4.5 常见问题速查表症状可能原因优先排查动作getConnection超时池子打满 / 连接泄露 / 慢SQL占用查activeCount、慢SQL列表、show processlist等待线程数持续增长高并发 池子过小或maxWait太长压测验证池子容量调整maxActive日志大量“a connection error occurred”连接被DB端断开但连接池还在复用调testWhileIdle / timeBetweenEvictionRunsMillisSQL监控页无数据stat filter没开启 / 切了HikariCP检查filter.stat.enabled接口偶发几十秒超时连接池执行了removeAbandoned回收查logAbandoned日志定位未归还的代码多数据源写入错误库事务边界内DS失效调整事务边界或手动管理连接5. 一些长期使用后的体会连接池这个组件不像缓存和消息队列那样引人注目但它是所有数据库访问的基座。基座一旦不稳上面再好的业务代码都会跟着遭殃。Druid给我最大的价值不是它帮你建了多少连接而是当线上出现问题的时候你能在几十秒内看到“问题SQL是哪个、连接在哪借的、等了多久”这种可观测性直接决定了排障效率。最后的建议是把Druid的参数当成有约束力的资源规划来做而不是随便填数字。上线前压测时特意把maxActive调小观察接口的排队和超时曲线再逐步放宽直到找到那个“既能扛住流量又不让数据库过载”的临界点。然后把这个临界点的参数固化下来配合监控报警一起用。这样数据库连接池才算真正在你的项目里“被配置过”而不是“跑起来而已”。 
长河君 · 2026/10/17 3:03:09 · 阅读 1.2k Druid数据库连接池全解析：核心参数、监控实战与避坑指南
做Java后端的基本没人能绕过数据库连接池这道槛。项目一跑起来连接池就是数据库访问的咽喉而Druid这个名字在很长一段时间里几乎是国内后端项目的默认选项。这篇就把Druid的核心设计、参数配置、监控玩法以及我实际踩过的坑一次讲透想让刚接触连接池的朋友少走弯路也给正在调优的人一些可抄的配置思路。1. 为什么是连接池又为什么是Druid1.1 没有连接池时数据库连接为什么扛不住先回到最基础的问题连接到底贵在哪。一个数据库连接的建立底层是一次TCP连接涉及三次握手、数据库鉴权、资源分配这一套走下来在局域网里可能只要几毫秒到几十毫秒但在高并发场景下每次请求都“现开现关”开销会被放大到让你怀疑人生。我见过一个真实项目最开始用了自研的“每次查询新建Connection”的写法压测到200并发时数据库连接数瞬间飙到上千数据库端连接线程直接被打满后端接口响应从20ms变成3秒。后来改成连接池同样200并发活跃连接稳定在30左右响应时间恢复到40ms以内。差异就在“复用”两个字上。连接池做的事本质上就是提前把一批连接创建好、放着备用请求来了从池子里借用完还回去而不是销毁。更重要的是连接池可以通过“保活检测”和“空闲回收”机制让池里的连接始终是健康的避免拿到一个已经被数据库端断开但TCP还没感知到的死连接。1.2 Druid 不只是连接池它与 HikariCP、C3P0 的差异Druid经常被拿来跟HikariCP、C3P0、dbcp对比。如果只看性能和连接管理能力HikariCP的吞吐确实非常猛字节码级别做了大量优化Spring Boot 2.x之后也默认把它作为数据源。但Druid能火靠的显然不是单纯的性能。对比项DruidHikariCPC3P0 / dbcp连接池基础能力完整完整完整监控面板内置StatViewServlet指标丰富有轻量指标需额外集成弱基本靠日志SQL级统计支持慢SQL、执行次数、并发数不直接支持不直接支持SQL防火墙WallFilter可拦截危险SQL无无数据库密码加密ConfigTools无需改代码需结合外部方案需结合外部方案性能略低于HikariCP但靠监控挽回极高一般Druid更像“连接池 监控运维工具”的结合体。它默认能输出SQL执行情况、连接分布、等待次数、慢SQL明细、Session列表。很多团队喜欢它其实是被它的可观测性吸引的线上出问题的时候打开Druid监控页一眼就能看出是慢SQL拖慢了接口还是连接没归还导致池子耗尽。1.3 选型和取舍什么时候该选 Druid我个人的标准很简单如果你的项目是内部系统、管理后台或者对数据库运行状态有强监控诉求那Druid是很好的选择。如果你做的是纯高并发互联网API追求极致性能HikariCP配合中间件监控也能用但你可能就要舍弃SQL维度的直接视图。结合国内开发者的习惯用Spring Boot MyBatis的团队Druid几乎做到了开箱即用依赖引入后配置几分钟就能看到监控面板。你完全可以在项目初期先用Druid把监控体系建立起来等上线稳定后再评估是否有必要为了那百分之几的性能换掉它。我的建议是不要人云亦云追求极致性能先把问题看清楚连接池这块三板斧Druid给得最全。2. Druid 核心配置逐项拆解2.1 连接数参数initialSize、minIdle、maxActive 到底怎么定Druid最常被讨论的就是这几个连接数参数。很多人在配置时直接抄模板从不关心数字背后的逻辑。先说结论没有“万金油参数”只有“适合你的参数”。initialSize启动时初始化的连接数。我一般设置成5或者10不用太大毕竟刚启动时并发通常不高连接是懒加载的用完再慢慢补。minIdle池中保底空闲连接数。这个值决定了低峰期池子至少留几条连接。设得太高低峰期也在白占数据库资源设得太低忽然来一波流量需要重新建连可能会扛不住瞬时压力。maxActive池中最大活跃连接数。这是最核心的约束建议根据“单条连接能支撑的并发请求数”和“预估QPS”来倒推。举例来说假设单连接每秒能处理50个SQL业务预计峰值2000 QPS那么预留40~50条连接是合理的。设太大会让数据库端连接线程过载太小又会在DB空闲时因为排队而拖垮接口。maxWait池中没有可用连接时获取连接的等待时间单位毫秒。超时后抛出异常而不是无限阻塞。这个值我习惯设60000既给了排队请求一定的容忍时间又能在池子彻底满时快速失败暴露问题。一个常见误区是以为maxActive越大越好。数据库连接数跟数据库自身的并发能力是强相关的一台MySQL的并发连接建议值是几百以内连接远多于CPU核心数反而会让线程调度开销变大甚至出现大量“sleep”连接占着资源不干活。把maxActive压到合理范围反而能倒逼你优化SQL和业务逻辑。2.2 连接保活与测试参数testWhileIdle 的平衡点这一组参数是Druid的灵魂也是最容易配置错的地方。validationQuery用来探测连接是否有效的SQL。MySQL用SELECT 1Oracle用SELECT 1 FROM DUAL。这条SQL会真实执行所以不能太重。testOnBorrow每次借出连接时是否做有效性检测。true的话最安全但每条连接借出都多一次探测性能开销明显。如果业务链路对性能敏感建议改成false。testWhileIdle连接空闲时是否做检测。这个可以设计成true配合timeBetweenEvictionRunsMillis和minEvictableIdleTimeMillis一起用代价很低收益很实在。timeBetweenEvictionRunsMillis空闲连接检测的执行周期默认60秒意思是每隔1分钟跑一次“体检”把连接池里空闲太久的连接关掉并重启到minIdle数量。minEvictableIdleTimeMillis连接最大空闲时间默认30分钟只有空闲超过这个时间的连接才会被回收。常用的配置套路就是testOnBorrowfalsetestWhileIdletruevalidationQuerySELECT 1让检测交给后台线程统一做避免每次借出连接都多一次额外往返。很多人踩过一个坑有的数据库因为网络中断连接已经失效但客户端不知道如果没有testWhileIdle和后台回收下次借出时拿到的是一条死连接执行任何SQL都直接报错排查半天还未必想到是连接池的问题。2.3 Spring Boot 下的最小可用配置模板给一份我项目里稳定跑了很久的配置基于druid-spring-boot-starter可以直接参考spring: datasource: type: com.alibaba.druid.pool.DruidDataSource driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/demo?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: xxxx druid: initial-size: 5 min-idle: 5 max-active: 20 max-wait: 60000 time-between-eviction-runs-millis: 60000 min-evictable-idle-time-millis: 300000 validation-query: SELECT 1 test-while-idle: true test-on-borrow: false test-on-return: false pool-prepared-statements: false filter: stat: enabled: true log-slow-sql: true slow-sql-millis: 2000 wall: enabled: true slf4j: enabled: true这里要说明几个容易被理解和配置错的地方pool-prepared-statements是用来缓存PreparedStatement的开启后确实能省一部分SQL预编译开销但会占用额外内存。在连接数多、SQL量大的场景下不建议盲目开。默认关闭是合理的。filter下面的配置控制的是Druid的各类扩展过滤器stat负责统计监控wall负责SQL防火墙slf4j负责把执行SQL打到日志里。注意这些filter跟纯Druid的原生配置文件的写法不同Spring Boot下用这种yml嵌套结构更方便。提示不要在生产环境照抄max-active20这个值请回到2.1那节按自己的并发模型重新算一遍。我给的模板是通用的起点不是最终答案。2.4 一组值得收藏的参数速查表参数默认值建议参考值参数作用initialSize35 ~ 10启动时初始连接数minIdle15 ~ 10最小空闲连接数maxActive820 ~ 100 视压测而定最大活跃连接数maxWait-130000 ~ 60000最大获取连接等待时间-1为无限等待timeBetweenEvictionRunsMillis6000060000空闲检测周期minEvictableIdleTimeMillis1800000300000 ~ 600000空闲连接最大存活时间validationQuery无视数据库类型而定探测SQLtestWhileIdlefalsetrue空闲时检测连接是否有效testOnBorrowtruefalse借出时检测连接是否有效testOnReturnfalsefalse归还时检测连接是否有效removeAbandonedfalse视场景开启自动回收被遗弃的连接logAbandonedfalse建议true记录被回收连接的堆栈信息removeAbandoned是双刃剑当连接被代码借用后没归还时Druid可以强制回收。线上关掉只在定位连接泄露问题时开了配合logAbandoned用否则很容易误杀还在执行长任务的连接。3. 监控、防火墙与扩展功能实战3.1 开启监控页StatViewServlet 与 WebStatFilter 的配置Druid的监控页是很多人喜欢它的直接原因。在Spring Boot里开启监控页只需要加上这么一段spring: datasource: druid: stat-view-servlet: enabled: true url-pattern: /druid/* login-username: admin login-password: admin123 reset-enable: false web-stat-filter: enabled: true url-pattern: /* exclusions: *.js,*.css,*.gif,*.jpg,*.png,*.ico,/druid/*开启后访问/druid/index.html就能看到控制台里面能看数据源状态、SQL监控、SQL防火墙、Session监控等信息。这里有三个经验要分享第一reset-enable一定要设成false否则页面上一个“重置”按钮就能把所有统计清零线上数据就白统计了。第二监控页必须能登录并且密码别用弱口令。这个页面暴露了你的完整SQL语句和库表结构是攻击者的高价值目标。第三如果项目使用了Spring Security或Shiro别忘记把/druid/**路径加进白名单或者额外做一层防护否则会出现“首页能开监控页但登录接口都调不通”的诡异现象。监控页的几个核心指标怎么看活跃连接数如果长期接近maxActive说明池子偏小或者存在连接泄漏。SQL执行次数、执行时间分布能快速找出慢SQL和高频SQL。连接等待次数如果等待次数持续增长说明连接竞争很激烈。3.2 慢SQL定位阈值怎么设才不误报慢SQL监控是排障效率最高的一环。配置里设置spring: datasource: druid: filter: stat: enabled: true log-slow-sql: true slow-sql-millis: 2000slow-sql-millis设成2000意思就是SQL执行超过2秒就记录到日志。这里要注意一个反直觉的点阈值别设太低比如100毫秒。很多公司的测试环境SQL执行几十毫秒很正常但一上生产环境受CPU、锁竞争、网络波动影响超过100毫秒的SQL一抓一大把日志会被刷爆反而淹没了真正的问题SQL。我见过一个项目把慢SQL阈值设成了500毫秒日志里全是“慢SQL”但没有一条是真正的性能隐患。后来改成了3000毫秒捞出来的都是确实需要优化的比如全表扫描、大分页、嵌套循环查询。建议慢SQL日志从2秒起步等上线稳定后再根据业务情况逐步收紧到1秒。日志里出现慢SQL之后下一步是把它从Druid监控页的SQL列表里找到原始SQL语句看执行计划用EXPLAIN分析索引命中情况。Druid自带功能只能暴露问题真正解决问题还是要回到数据库侧。3.3 WallFilterSQL防火墙防注入WallFilter是Druid很有特色的功能它本质上是一个SQL语法分析器在SQL真正执行前做一次“安检”阻止不确定的、有风险的语句进入数据库。启用方式就在filter配置里加一行spring: datasource: druid: filter: wall: enabled: true它拦截的典型行为包括select *这种不带条件的全表扫描没有WHERE条件的DELETE/UPDATE整表操作INSERT INTO一次性插入超大结果集禁止多条SQL用分号拼在一起执行阻止部分SQL注释变体绕过过滤器的行为关于WallFilter要泼一点冷水它不是万能的不能完全替代代码层的SQL参数化校验。对于MyBatis这种框架生成的SQLWallFilter基本够用但对于复杂业务里的动态SQL拼接、存储过程调用、特殊语法WallFilter可能会误伤。所以生产环境开启后要有“偶尔会误拦”的心理准备。我当时接入时有一类合法SQL被拦了某个老系统用了INSERT ... ON DUPLICATE KEY UPDATEWallFilter对某些版本的语法解析不完整直接报错。最后在配置文件里针对该连接增加了wall的insert配置放行才解决。遇到这种场景先看日志确定具体拦截规则不要一上来就全局关闭WallFilter。3.4 ConfigTools 密码加密让数据库口令不再裸奔Druid里最容易被低估的是ConfigTools它可以在不写代码的情况下给数据库密码做非对称加密。使用方式很简单命令行执行java -cp druid-1.2.20.jar com.alibaba.druid.filter.config.ConfigTools yourpassword执行后你会得到私钥、公钥和一个加密后的密文。然后配置改成这样spring: datasource: username: root password: 密文 druid: filter: config: enabled: true connection-properties: config.decrypt: true config.decrypt.key: 公钥这里有几个容易踩的点第一config.decrypt.key配的是公钥不是私钥。私钥只在生成密文时短暂出现生成完就该销毁别把它留在配置文件里。第二Spring Boot的druid-spring-boot-starter里connection-properties的写法是上面的yaml形式但如果你用的是纯Druid原生配置要写成connectionPropertiesconfig.decrypttrue;config.decrypt.key公钥注意是分号分隔。有一点要承认这种加密不是绝对安全因为解密用的公钥就在配置文件里真正攻入服务器的人仍然能拿到密钥。但它能解决一个实际问题配置文件被传到Git仓库、被截图发到群里、被运维脚本误打印时数据库口令不会直接泄露。这个成本很低建议所有项目都做。4. 真实环境中容易踩的坑与排查实录4.1 连接池耗尽activeCount 一直顶在 maxActive 时怎么办这是Druid最常见的生产事故。表现是接口开始大面积超时应用日志里出现wait millis 60000, active 20之类的异常。Druid监控页会显示activeCount长期等于maxActivewaitThreadCount持续增长。排查思路按照这个顺序来第一看Druid的SQL监控页是不是出现了某个SQL的执行时间暴涨。一个慢SQL如果执行10秒那在100并发下瞬间就会消耗掉几百条连接直接把池子打满。第二看连接获取后是否正常归还。写一段日志监控代码在DataSource.getConnection()后打印当前线程堆栈过一段时间再对比哪些线程还握着连接不放。或者在代码里临时加上removeAbandonedtrue和logAbandonedtrue让Druid在连接被遗弃时打印出当时的调用堆栈定位到具体代码行。确认问题后再关掉removeAbandoned。第三看数据库侧有没有一堆sleep连接。MySQL执行show processlist如果大量连接处在Sleep状态且持续很久基本是业务代码获取连接后没有关闭或事务超时时间设太长。有一次对方团队自查了三天没结果最后我在他们的连接获取入口打点发现是个事务方法里调了一个外部HTTP接口外部接口响应超时30秒而事务一直开着里面唯一一条数据库连接被占着不放。并发一高池子瞬间满了。4.2 连接泄露定位getConnection 之后没 close 的典型症状用Druid连接池的团队代码里经常出现“只在finally里closeResultSet忘了closeConnection”的情况。这在连接数不多时表现不明显但上线久了之后连接池必然出问题。定位泄露有两条路一是执行show full processlist看哪个应用IP的连接特别多且长时间Sleep二是用Druid的logAbandoned开关。logAbandonedtrue会在回收连接的时候打印出该连接最后一次被借用的业务堆栈这比盲目review代码高效得多。等日志捞出来再关掉。更重要的是从根上避免现在主流的做法是拥抱spring-boot-starter-jdbc里的DataSourceUtils或直接交给MyBatis / JPA的事务Template管理连接。宁可让框架管也别自己手写Connection因为手写意味着你要在每一个异常路径上都记得释放。曾经接手过一版代码用了try (Connection conn dataSource.getConnection())这种写法看起来没问题但里面又包了try ... catch返回jsoncatch里忘了关闭照样泄露。4.3 频繁 TIME_WAIT池子没复用连接的问题有段时间线上MySQL的ss -ant里能看到应用服务器到数据库端口有大量TIME_WAIT连接每秒几十个增加。这说明底层TCP连接根本没有被复用一直在创建新连接、关闭旧连接。连接池表现得像没起作用一样。核心原因通常是连接池的实际活跃连接数没到急着创建新连接的时候但连接却在被反复创建销毁。仔细排查后发现是socketTimeout或connectTimeout设置太短一条连接在空闲期间被数据库端通过wait_timeout切断了Druid后台还没轮询到它下次请求一来发现它不可用只能新建建完之后又不用继续被超时杀掉陷入循环。解决办法把timeBetweenEvictionRunsMillis调小一点比如30秒把minEvictableIdleTimeMillis调到小于数据库wait_timeout的值确保后台能在连接被数据库杀掉之前检测到并替换。同时可以适当调大testWhileIdle的频率让空闲连接一直在心跳保活。4.4 多数据源切换的坑事务一开DS 就失效做多数据源项目时很多人用DS注解做数据源路由。这里有个很隐蔽的坑一旦方法上加了Transactional事务管理器会在进入方法时就决定好使用哪个数据源后续DS的切换会全部失效。结果就是数据写到了错误的库里还半天查不出来。Druid在实际多数据源场景中的角色通常是提供多个独立的DruidDataSourceBean然后由一个路由数据源在运行时按key切换。事务一旦开启连接是在事务开始时从特定数据源拿的后续业务代码里的路由注解根本无法影响当前线程已绑定的连接。规避手段很简单把跨库操作拆成多个短事务方法事务边界的上层不写DS在真正访问数据的那一层再切换数据源与开启事务。做不到拆分的话就要自己管理连接和事务边界复杂度会上一个档次。很多时候报“事务失效”其实不是Druid的问题而是Spring事务传播机制和动态数据源路由的兼容性没有理清。4.5 常见问题速查表症状可能原因优先排查动作getConnection超时池子打满 / 连接泄露 / 慢SQL占用查activeCount、慢SQL列表、show processlist等待线程数持续增长高并发 池子过小或maxWait太长压测验证池子容量调整maxActive日志大量“a connection error occurred”连接被DB端断开但连接池还在复用调testWhileIdle / timeBetweenEvictionRunsMillisSQL监控页无数据stat filter没开启 / 切了HikariCP检查filter.stat.enabled接口偶发几十秒超时连接池执行了removeAbandoned回收查logAbandoned日志定位未归还的代码多数据源写入错误库事务边界内DS失效调整事务边界或手动管理连接5. 一些长期使用后的体会连接池这个组件不像缓存和消息队列那样引人注目但它是所有数据库访问的基座。基座一旦不稳上面再好的业务代码都会跟着遭殃。Druid给我最大的价值不是它帮你建了多少连接而是当线上出现问题的时候你能在几十秒内看到“问题SQL是哪个、连接在哪借的、等了多久”这种可观测性直接决定了排障效率。最后的建议是把Druid的参数当成有约束力的资源规划来做而不是随便填数字。上线前压测时特意把maxActive调小观察接口的排队和超时曲线再逐步放宽直到找到那个“既能扛住流量又不让数据库过载”的临界点。然后把这个临界点的参数固化下来配合监控报警一起用。这样数据库连接池才算真正在你的项目里“被配置过”而不是“跑起来而已”。