Druid连接池8个最常配错的参数、默认值与生产推荐值【免费下载链接】druid阿里云计算平台DataWorks(https://help.aliyun.com/document_detail/137663.html) 团队出品为监控而生的数据库连接池项目地址: https://gitcode.com/gh_mirrors/druid/druid凌晨 3 点应用集体抛出 GetConnectionTimeoutException重启才恢复——这类故障十有八九是 Druid 连接池参数没配到位连接被占满、死连接混进业务、泄漏无人发现。Druid 是阿里云 DataWorks 团队出品的数据库连接池它的参数默认值大多偏向安全而非高性能照默认值裸奔能跑但撑不过高峰。这篇文章按故障场景把最该动的参数一次讲清并给出可直接拷贝的配置。本文你能带走四样东西拿到一份带默认值、生产推荐值、改错后果的参数速查表按连接耗尽 / 死连接 / 泄漏三大故障理解参数出问题时知道动哪个拷走 3 份按场景写好的完整配置首次上线、核心交易、多副本学会用监控页和日志读数验证改对了没有上节监控页就是本文后面所有验证手段的入口配置改完先看这里。参数速查总表默认值与生产推荐值所有默认值取自 DruidAbstractDataSource.java推荐值按常见单库、20 线程级并发的场景给出具体数字后面每节都会解释。参数默认值生产推荐值改错的后果maxActive820~50并发一上来就排队数据库 max_connections 才是真上限maxWait-13000~5000ms-1 是无限等待连接池一耗尽全部业务线程卡死minIdle0maxActive 的 1/4~1/2低谷期没有热连接流量突增时现场建连接RT 毛刺testWhileIdletruetrue关掉后死连接要等下次检测才暴露timeBetweenEvictionRunsMillis6000060000调太小浪费调太大死连接窗口变长minEvictableIdleTimeMillis1800000≥ 数据库 wait_timeout小于它空闲连接刚建好就被清掉phyTimeoutMillis-136000001h-1 永不主动销毁死连接只能被动发现removeAbandonedfalse生产 false定位期短暂开 true强开会误杀长事务源码注释明确不建议生产使用连接为什么会被耗尽maxActive 与 maxWait应用报 GetConnectionTimeoutException本质是要连接的人多于池里的连接。三个参数决定这个平衡maxActive 定并发上限maxWait 定等不到时线程的行为minIdle 定冷启动表现。异常本身定义在 GetConnectionTimeoutException.java。参数默认值生产推荐值一句话原因initialSize05启动时预热几个连接避开第一波流量的建连开销maxActive820~50默认 8 太小超过 50 时先怀疑慢 SQL 或泄漏别无脑加minIdle0maxActive 的 1/4~1/2保持热连接低谷不浪费、高峰不建连maxWait-13000~5000ms设成保险丝池耗尽时快速失败而不是线程无限排队maxWaitThreadCount-130~100限制排队线程数防止数据库故障时线程堆积打满 JVM# 连接容量 spring.datasource.druid.initial-size5 # 启动预热连接数 spring.datasource.druid.max-active20 # 并发上限按业务线程数估算 spring.datasource.druid.min-idle8 # 低谷期保留的热连接 spring.datasource.druid.max-wait5000 # 拿不到连接 5 秒即抛异常快速失败 spring.datasource.druid.max-wait-thread-count50 # 排队线程封顶防线程堆积注意minIdle 不能大于 maxActive否则 setMinIdle 会直接抛 IllegalArgumentException。这节解决的是连接池在高峰时接不住或排队卡死。死连接怎么混进业务testWhileIdle 组合数据库重启、网络切换、超过 MySQL 的 wait_timeout池里的物理连接就死了。验证机制没配对时这些死连接会被借给业务线程抛出五花八门的通讯链路断裂异常。参数默认值生产推荐值一句话原因validationQuerynullSELECT 1各库通用的最小验证 SQLOracle 用 SELECT 1 FROM DUALtestOnBorrowfalsefalse每次借出都验证一次高并发下 RT 明显上升testOnReturnfalsefalse归还时验证同样浪费靠空闲检测兜底即可testWhileIdletruetrue默认就是 true别关空闲检测是唯一常态化剔除死连接的手段timeBetweenEvictionRunsMillis600006000060 秒一轮兼顾开销与死连接暴露窗口# 连接有效性 spring.datasource.druid.validation-querySELECT 1 # 验证 SQL spring.datasource.druid.test-while-idletrue # 空闲时检测剔除死连接 spring.datasource.druid.time-between-eviction-runs-millis60000 # 检测间隔 60s spring.datasource.druid.min-evictable-idle-time-millis3600000 # 空闲 1h 才允许清注意minEvictableIdleTimeMillis 必须大于数据库侧的 wait_timeoutMySQL 默认 8 小时否则连接被数据库断掉前池子自己就清了清得越多重建越频繁。这节解决的是偶发连接已关闭/通讯链路失效类异常。连接泄漏怎么被定位removeAbandoned 的正确用法泄漏的典型读数是 activeCount 只增不减minIdle 兜不住、maxWait 被反复触发。Druid 的 removeAbandoned 会在连接借出超时后强制回收并打堆栈但它在源码里的警告很直接# 泄漏定位 spring.datasource.druid.log-abandonedtrue # 回收时打印借出堆栈定位泄漏代码 spring.datasource.druid.remove-abandonedfalse # 生产保持 false参数默认值生产推荐值一句话原因logAbandonedfalsetrue只记堆栈不误杀是定位泄漏的关键开关removeAbandonedfalse生产 false排障期短暂 true强回收会杀掉运行超过阈值的正常长事务removeAbandonedTimeoutMillis300000按业务最长事务上浮 50%阈值低于最长事务时长就是误杀注意DruidDataSource 中 setRemoveAbandoned(true) 会打 warn 日志removeAbandoned is true, not use in production——把它当排障开关用不当常态防护用。定位手法短暂开 removeAbandoned logAbandoned看日志里的借出堆栈找到漏关连接的代码或者在监控页Web应用页对照 URI 的 JDBC 执行次数与活跃连接。修完代码后记得关回去。这节解决的是连接池被慢慢吃光却查不到源头。物理连接该活多久phyTimeoutMillisphyTimeoutMillis 默认 -1物理连接永不主动销毁phyMaxUseCount 默认 -1一个连接执行 SQL 没有次数上限。两者都意味着死连接和脏状态只能被动发现。# 物理连接生命周期 spring.datasource.druid.phy-timeout-millis3600000 # 1 小时主动换血 spring.datasource.druid.phy-max-use-count100000 # 执行 10 万次后强制重建参数默认值生产推荐值一句话原因phyTimeoutMillis-136000001h主动换血比等死连接被检测出来成本低phyMaxUseCount-1100000给连接服役时长上限防状态积累这节解决的是运行数天后才出现的偶发连接失效。PreparedStatement 缓存到底开不开池化让固定模板 SQL 复用服务端编译结果。CRUD 模板 SQL 多、重复执行的高并发场景收益明显动态拼接 SQL 多的场景收益低还占内存。实现见 PreparedStatementPool.java。参数默认值生产推荐值一句话原因poolPreparedStatementsfalse模板 SQL 多则 true开启前先看 SQL 监控页确认 SQL 集中度maxPoolPreparedStatementPerConnectionSize1050每连接缓存条数按业务 SQL 模板数定sharePreparedStatementsfalse保持 false跨连接共享引入额外复杂度收益有限# PS 缓存确认 SQL 模板集中后再开 spring.datasource.druid.pool-prepared-statementstrue spring.datasource.druid.max-pool-prepared-statement-per-connection-size50注意先开 stat 过滤看 SQL 模板集中度再决定开不开别凭感觉开——模板 SQL 不集中时纯占内存。这节解决的是固定 SQL 高并发下 prepare 开销占比高的问题。场景配方三份可直接拷贝的配置配方一首次上线最小可用版spring.datasource.druid.initial-size5 spring.datasource.druid.max-active20 spring.datasource.druid.min-idle5 spring.datasource.druid.max-wait3000 # 快速失败上线初期宁可报错也别卡线程 spring.datasource.druid.validation-querySELECT 1 spring.datasource.druid.test-while-idletrue spring.datasource.druid.time-between-eviction-runs-millis60000 spring.datasource.druid.log-abandonedtrue # 上线初期多留一双眼睛为什么这么配容量保守、失败快速、只开无副作用的防护。maxWait 设 3000ms 是为了让泄漏和慢 SQL 在第一周就暴露成异常而不是被无限等待掩盖。配方二核心交易接口加固版在配方一基础上追加spring.datasource.druid.max-wait5000 spring.datasource.druid.max-wait-thread-count50 spring.datasource.druid.phy-timeout-millis3600000 spring.datasource.druid.min-evictable-idle-time-millis3600000 spring.datasource.druid.connection-propertiesdruid.stat.slowSqlMillis500 # 记录 500ms 的 SQL为什么这么配交易接口对毛刺敏感物理连接 1 小时换血避免服役过久的连接slowSqlMillis 设 500ms 让占用连接过长的 SQL 可追溯。配方三多副本生产版8 副本 × 20 连接spring.datasource.druid.max-active20 # 8 副本 × 20 160需 数据库 max_connections spring.datasource.druid.async-inittrue # 异步建连缩短发布窗口 spring.datasource.druid.break-after-acquire-failuretrue # 建连失败不再反复重试 spring.datasource.druid.connection-error-retry-attempts1 # 重试 1 次即快速失败 spring.datasource.druid.min-idle8为什么这么配多副本下真正的上限是数据库侧连接数先算总量再定单副本容量asyncInit 让滚动发布少等几十秒breakAfterAcquireFailure 防止数据库故障时每个副本都在后台反复建连把故障放大成雪崩。自诊断表现象 → 原因 → 该动什么现象可能原因该动的参数 / 动作GetConnectionTimeoutException 频发连接耗尽或 maxWait 太短先查 activeCount 是否贴 maxActive是则优化慢 SQL再考虑加 maxActive高峰 RT 毛刺、偶发建连延迟minIdle 为 0现场建连接minIdle 提到 maxActive 的 1/4偶发连接已关闭/通讯链路断裂死连接借出确认 testWhileIdletrue调 minEvictableIdleTimeMillis wait_timeoutactiveCount 缓慢增长不回落连接泄漏开 logAbandoned 短暂开 removeAbandoned 抓堆栈数据库故障后恢复慢、日志刷建连错误默认不断重试建连breakAfterAcquireFailuretrue调小 connectionErrorRetryAttempts内存随运行时间上涨PS 缓存过开调小 maxPoolPreparedStatementPerConnectionSize 或关闭池化应用启动慢initialSize 大 同步初始化开 asyncInittrue验证怎么判断改对了改完配置用三个手段读数对应监控页入口见文首截图监控页数据源页看 ActiveCount 和 WaitThreadCount。正常读数ActiveCount 明显低于 maxActive 且平稳WaitThreadCount 长期为 0、只在流量尖刺时短暂出现个位数。日志观察create connection、discard connection、remove abandoned connection关键词。正常读数稳态下几乎没有 discard频繁 discard 说明验证配置和 wait_timeout 打架排障期能看到 remove abandoned 后跟借出堆栈。JSON API监控页右上角查看 JSON API拉取activeCount、recycleCount、errorCount与改配前对比。正常读数errorCount 不随时间上涨recycleCount 缓慢增长。Druid 连接池的调优核心就三件事把连接供给容量与等待算清楚把死连接清理检测与换血配成闭环把泄漏定位堆栈日志留在手边。每个参数都有默认值可查、推荐值可抄、监控读数可验证。下一步值得深入的是 SQL 监控与慢查询分析——找到真正占住连接过长的 SQL比调任何参数都有效。你有哪类故障场景还没覆盖到留言说说下一期挑一个最常见的接着拆。【免费下载链接】druid阿里云计算平台DataWorks(https://help.aliyun.com/document_detail/137663.html) 团队出品为监控而生的数据库连接池项目地址: https://gitcode.com/gh_mirrors/druid/druid创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考