Druid连接池参数配置与调优实战从首次接入到超时与泄漏排查【免费下载链接】druid阿里云计算平台DataWorks(https://help.aliyun.com/document_detail/137663.html) 团队出品为监控而生的数据库连接池项目地址: https://gitcode.com/gh_mirrors/druid/druidDruid连接池是阿里巴巴开源的JDBC连接池核心价值在于复用数据库连接、隔离连接失效、并把连接池状态暴露成可观测的监控页面。它面向需要管理数据库连接的后端开发与运维人员。本文不罗列全部配置项而是沿首次接入 → 高并发生产 → 出现连接超时或连接泄漏排查三个阶段给出可直接落地的Druid配置参数并说明每个取值背后的依据与验证方法。先搞清一个连接在池里的完整生命周期不看机制就调参等于盲调。一个连接在池里会经历五个阶段创建initialSize决定启动时预建多少条minIdle是空闲时保底保活的连接数二者都低于maxActive上限时才可能真正建连。借出业务线程调getConnection()。池有空闲就直接拿没有且未达maxActive上限就新建已达上限则等待最多等maxWait毫秒超时抛GetConnectionTimeoutException。有效性检查归还时按testOnReturn、借出时按testOnBorrow、空闲时按testWhileIdle默认true决定是否执行validationQuery验证。空闲驱逐后台任务每timeBetweenEvictionRunsMillis默认60000ms跑一轮把空闲超过minEvictableIdleTimeMillis默认30分钟的连接剔除且保证剔除后仍不低于minIdle。物理超时phyTimeoutMillis默认-1永不主动重建物理连接一旦开启连接存活超过该值就会被强制销毁重建。调参的本质就是在这五个阶段上决定何时建、等多久、何时验、何时杀。下面按场景给参数。场景一新项目首次接入配置清单首次接入的目标是可用且行为可预期不需要堆高级项。这份配置最关键的两个值是maxActive10和maxWait6000其余保持默认即可。DruidDataSource ds new DruidDataSource(); ds.setUrl(jdbc:mysql://localhost:3306/demo); ds.setUsername(app); ds.setPassword(secret); ds.setMaxActive(10); ds.setMaxWait(6000); ds.setValidationQuery(SELECT 1);参数本场景取值依据不设置/配错会怎样maxActive10小服务按峰值并发SQL数留一倍余量给10~20默认值8对多数小应用偏紧默认8配得比数据库允许的单应用配额大会在数据库端撞连接上限maxWait6000借不到连接最多阻塞6秒宁可快速失败让上层感知而不是无限挂住默认-1表示不超时慢请求会把业务线程越拖越死initialSize0默认启动快冷启动首次请求略慢可接受配成接近maxActive启动变慢且必须≤maxActive否则启动直接抛 IllegalArgumentExceptionminIdle5与initialSize一致即可避免低谷把连接全驱逐光设0也行但流量波动大时连接数来回抖动validationQuerySELECT 1MySQL配合testWhileIdle保证空闲连接可用留空则空闲检查走Driver的isValid()部分老驱动不可靠minEvictableIdleTimeMillis默认1800000空闲30分钟才驱逐覆盖一般午休/夜间低谷设太小如5分钟业务低谷后连接频繁重建phyTimeoutMillis保持-1不做主动物理重建交给驱逐机制处理设成比minEvictableIdleTimeMillis还短会先于驱逐把连接杀掉注意一条硬约束maxActive必须大于minIdle否则 Druid 在 DruidDataSource.java 里直接抛IllegalArgumentException。场景二高并发生产环境的参数组合高并发场景与首发清单的差别在于要防冷启动冲击、要控制建连成本。这份配置最关键的两个值是minIdle20预热和sharePreparedStatementstrue降低server-side prepare数量。ds.setMaxActive(30); ds.setMinIdle(20); ds.setAsyncInit(true); ds.setPoolPreparedStatements(true); ds.setMaxPoolPreparedStatementPerConnectionSize(5); ds.setSharePreparedStatements(true);参数本场景取值依据不设置/配错会怎样maxActive30示例按峰值并发×平均单SQL占用时间÷可接受排队压测算同时不超过数据库max_connections分配给本实例的配额拍脑袋翻倍数据库端连接数先打满所有应用一起超时minIdle20压测前预热避免流量突增时集中建连建连成本远高于复用默认0突发QPS下连接数从零爬升首波请求RT明显抬高asyncInittrue异步建连应用启动不被initialSize拖住启动阻塞影响发布窗口poolPreparedStatementstrue模板SQL固定如DAO层固定几百条时收益明确默认false每次执行都走prepare动态拼接SQL极多时开启反而浪费内存maxPoolPreparedStatementPerConnectionSize5每连接只缓存5条热SQL控制内存占用默认10SQL模板多时会缓存上千条server-side preparesharePreparedStatementstrue把server-side prepare数从连接数×模板数压到模板数MySQL下收益最大默认false连接多时prepare数量线性膨胀开启removeAbandoned时源码会打印not use in production的告警日志它属于兜底手段高并发场景更推荐用监控指标见下一节定位问题而不是长期开着自动回收。场景三连接泄漏与连接超时排查参数出现连接不归还时先定位、再兜底。这份配置最关键的是logAbandonedtrue留下泄漏栈和removeAbandonedTimeoutMillis兜底阈值必须大于业务最长SQL耗时。ds.setLogAbandoned(true); ds.setRemoveAbandoned(true); ds.setRemoveAbandonedTimeoutMillis(180000);参数本场景取值依据不设置/配错会怎样logAbandonedtrue借出连接被判定泄漏时打印借出时的调用栈直接定位到代码行默认false泄漏只能靠猜removeAbandonedtrue临时源码 DruidDataSource.java 中有明确告警不宜长期生产开启定位完问题应关闭长期开着会把执行时间超过阈值的正常长SQL连接一起杀掉removeAbandonedTimeoutMillis180000必须显著大于业务最长SQL耗时如最长60s取3倍否则误杀正常长事务默认300000设得比慢SQL还短等于自己制造故障正确动作是开logAbandoned抓栈 → 修代码归还连接 → 关闭removeAbandoned而不是把自动回收当常驻功能。配置生效后如何验证与观测改完参数不要只看没报错要进监控页面需开启 stat 过滤器核对数值。重点关注五个指标指标正常范围异常时说明什么ActiveCount远低于maxActive长期贴着maxActive池容量不够或连接被长期占用PoolingCount≥ minIdle贴着0说明空闲驱逐太激进或minIdle没生效WaitThreadCount0或瞬时个位数持续0说明有线程在排队等连接maxActive偏小或SQL太慢ActivePeak不超过maxActive峰值平缓峰值长期贴顶按峰值反推容量余量不足RecycleCount增速稳定突增且ActiveCount同步下跌检查是否有连接被误判泄漏回收判断生效的硬标准压测一轮后ActiveCount峰值落在预期并发附近WaitThreadCount全程为0且无GetConnectionTimeoutException日志。三个典型问题的排障思路连接超时GetConnectionTimeoutException症状报错带wait millis集中在业务高峰或冷启动后。排查看 WaitThreadCount 与 ActiveCount 是否同时贴顶查数据库端max_connections余量按SQL耗时排序找长占用SQL。处置慢SQL优化或加超时queryTimeout容量确认足够后再上调 maxActive冷启动型超时把 minIdle 预热做足。内存持续上涨症状老年代缓慢爬升Full GC 后不回落。排查先区分两类来源——连接数是否只增不减ActiveCount/PoolingCount 单调上涨还是稳定但内存仍涨查 PreparedStatement 缓存量级 连接数 × maxPoolPreparedStatementPerConnectionSize × 模板数。处置前者按泄漏流程抓logAbandoned栈修代码后者收敛缓存上限或关闭 sharePreparedStatements。响应时间波动症状RT 曲线锯齿状尖刺间隔与流量高峰对应。排查监控页面 SQL 耗时分布是否集中在某几条数据库端 CPU/IO 是否与尖刺同步尖刺时刻是否伴随连接数跳变批量建连。处置批量建连型用 minIdle 预热 phyTimeoutMillis 控制物理重建节奏慢SQL型先优化SQL再考虑开启 wall 过滤器拦截危险SQL。调参收尾调优顺序固定为先看监控指标再动参数一轮只改一个变量跑一个完整业务周期再看下一轮任何配置上线前用压测覆盖最坏流量而不是等生产来验证。延伸方向有两个用 druid-spring-boot-starter 把参数收进 Spring Boot 配置体系统一管理以及用 druid-admin 做跨实例的集中监控。【免费下载链接】druid阿里云计算平台DataWorks(https://help.aliyun.com/document_detail/137663.html) 团队出品为监控而生的数据库连接池项目地址: https://gitcode.com/gh_mirrors/druid/druid创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考