1. 项目概述为什么SpringBoot项目需要Druid如果你正在用SpringBoot开发一个需要连接数据库的应用比如一个用户管理系统或者电商后台那么你大概率已经用上了Spring Boot Starter Data JPA或者MyBatis-Plus。Spring Boot的自动配置确实省心它默认会使用HikariCP作为数据源连接池。HikariCP很快号称“光速”但在生产环境中光有速度可能还不够。你可能会遇到一些更实际的问题某个SQL突然执行得很慢拖垮了整个应用但你不知道是哪条语句数据库连接莫名其妙被占满应用开始报错你却无从排查你想知道在业务高峰期数据库连接的使用情况到底怎么样。这时候Druid的价值就凸显出来了。它不仅仅是一个高性能的数据库连接池更是一个强大的监控和诊断工具。在国内的Java开发圈尤其是阿里巴巴的技术生态里Druid几乎是标配。我经历过不止一次线上事故最后都是靠Druid的监控页面快速定位到慢SQL或者泄露的连接从而解决问题。所以把SpringBoot默认的HikariCP换成Druid对于追求稳定性和可观测性的项目来说是一个很自然的选择。这个过程不复杂但里面的细节和配置项如果理解不透彻可能会埋下隐患。接下来我就结合自己踩过的坑带你从零开始在SpringBoot项目中完整地配置并用好Druid。2. 核心依赖引入与基础配置2.1 依赖选择与引入首先我们需要在项目的pom.xml文件中引入Druid的Spring Boot Starter。这里有个关键点不要只引入druid的普通依赖要引入druid-spring-boot-starter。这个Starter封装了与SpringBoot的自动配置集成会省去你大量手动配置Bean的麻烦。dependency groupIdcom.alibaba/groupId artifactIddruid-spring-boot-starter/artifactId version1.2.20/version !-- 请使用最新稳定版本 -- /dependency同时确保你已经有了数据库驱动和Spring Boot的JDBC或数据访问层依赖比如MySQL和spring-boot-starter-data-jpa或mybatis-spring-boot-starter。dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scoperuntime/scope /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-jpa/artifactId !-- 或用 mybatis-spring-boot-starter -- /dependency注意版本号务必去Maven中央仓库核对最新稳定版。我曾因为用了过旧的版本导致一些新的监控功能无法使用还遇到了兼容性问题。2.2 基础连接池参数配置引入依赖后下一步就是在application.yml或application.properties中配置数据源。SpringBoot会自动识别spring.datasource.druid前缀下的配置。以下是一份兼顾性能和基础监控的配置示例spring: datasource: # 基本连接信息 url: jdbc:mysql://localhost:3306/your_database?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai username: root password: your_password driver-class-name: com.mysql.cj.jdbc.Driver # 指定使用Druid数据源这是关键一步 type: com.alibaba.druid.pool.DruidDataSource # Druid专属配置 druid: # 连接池大小配置核心参数根据业务调整 initial-size: 5 min-idle: 5 max-active: 20 # 获取连接等待超时时间毫秒 max-wait: 60000 # 连接有效性检查 validation-query: SELECT 1 test-on-borrow: false # 借出时检查影响性能不建议开启 test-on-return: false # 归还时检查影响性能不建议开启 test-while-idle: true # 空闲时检查推荐开启 time-between-eviction-runs-millis: 60000 # 空闲连接检查间隔(ms) min-evictable-idle-time-millis: 300000 # 连接最小空闲时间(ms)参数解读与踩坑经验initial-size, min-idle, max-active这是连接池的“水位线”。initial-size是启动时就建立的连接数避免第一次请求的延迟。min-idle是池中始终保持的最小空闲连接数。max-active是最大活跃连接数相当于池子的容量上限。设置太小高并发时请求会排队等待设置太大会耗尽数据库资源。一般建议max-active是数据库max_connections的70%-80%。我通常从20开始根据监控数据调整。test-while-idle这是最重要的健康检查设置。设置为true后Druid会定期用validation-query检查空闲连接是否有效自动销毁失效连接并补充新连接。务必开启这是避免应用使用已断开的数据库连接比如数据库重启后导致报错的关键。max-wait当连接池耗尽新的请求获取连接的最大等待时间。超时则抛异常。生产环境可以设长一点如10秒但也要在代码中做好超时处理。3. 监控功能配置与安全加固Druid最强大的功能在于其内置的监控统计。不开启监控Druid就失去了大半价值。3.1 启用Web监控统计ServletDruid提供了一个类似/druid/index.html的监控页面。我们需要在配置中启用它并设置访问账号密码这是安全底线绝不能裸奔开放。spring: datasource: druid: # 监控统计相关配置 web-stat-filter: enabled: true # 启用Web关联监控 url-pattern: /* # 过滤所有URL exclusions: *.js,*.gif,*.jpg,*.png,*.css,*.ico,/druid/* # 排除静态资源和监控本身 session-stat-enable: true # 启用Session统计谨慎开启涉及隐私 principal-session-name: session_user # Session中用户信息的字段名 principal-cookie-name: cookie_user # Cookie中用户信息的字段名 stat-view-servlet: enabled: true # 启用StatViewServlet提供监控页面 url-pattern: /druid/* # 监控页面的访问路径 login-username: admin # 监控页面登录用户名必须修改 login-password: druid123 # 监控页面登录密码必须修改 reset-enable: false # 禁用HTML页面上的“重置所有数据”按钮生产环境务必关闭 allow: 127.0.0.1 # 白名单多个用逗号分隔。生产环境建议配置内网IP或空允许所有但必须配密码 deny: 192.168.1.100 # 黑名单优先级高于allow安全配置要点login-username和login-password这是第一道防线。绝对不要使用默认值或弱密码。我见过有团队直接部署监控页面被爬虫扫到导致数据库信息泄露。reset-enable: false这个按钮一旦被误点所有监控数据清零对于排查历史问题会是灾难。生产环境必须关掉。allow和deny通过IP进行访问控制是最佳实践。在开发环境可以设为127.0.0.1本地访问。生产环境可以设置为运维网段IP或者结合公司网关做二次认证。如果暂时无法确定IP至少保证强密码。url-pattern默认/druid/*挺好不建议修改。如果你修改了记得上面的web-stat-filter.exclusions也要同步更新。3.2 配置SQL监控与防火墙除了资源监控我们更关心SQL执行情况。Druid可以记录所有SQL的执行时间、返回行数等。spring: datasource: druid: # SQL监控与防火墙 filter: stat: enabled: true # 开启SQL监控 log-slow-sql: true # 记录慢SQL slow-sql-millis: 2000 # 慢SQL阈值单位毫秒。建议根据业务调整初期可设为1秒。 merge-sql: true # 合并相似的SQL便于统计 wall: enabled: true # 启用SQL防火墙防御SQL注入 config: drop-table-allow: false # 禁止删除表 truncate-allow: false # 禁止清空表 # 合并 filters 的配置新版本推荐方式 filters: stat,wall,slf4j # 启用统计、防火墙、日志过滤器监控数据分析经验慢SQL日志slow-sql-millis设置后执行时间超过该值的SQL会被记录到日志如果配置了slf4j过滤器并在监控页面“慢SQL”栏展示。这是性能调优的黄金入口。定期查看慢SQL针对性加索引或优化业务逻辑。SQL防火墙WallFilter能有效拦截一些明显的SQL注入攻击比如11、union select等。对于内网管理后台等系统可以适当放宽限制对于直接面向公网的接口建议严格开启。合并SQLmerge-sql对于使用PreparedStatement的SQLselect * from user where id ?无论参数是1还是2在统计时会被合并为一条这样能更准确地反映SQL模板的执行性能而不是被海量参数值淹没。4. 高级特性与生产环境调优基础配置能让Druid跑起来但要发挥其最大效能适应生产环境的高并发、高可用场景还需要进行一些深度调优。4.1 连接泄漏检测与回收这是Druid解决线上顽疾的利器。应用代码如果没有正确关闭Connection、Statement或ResultSet就会导致连接泄漏最终连接池被占满。spring: datasource: druid: # 连接泄漏检测 remove-abandoned: true # 是否移除泄露的连接 remove-abandoned-timeout: 300 # 连接被占用的超时时间秒超过此时间视为泄露 log-abandoned: true # 输出泄露连接的堆栈信息到日志工作原理与注意事项 Druid会跟踪每一个从连接池借出的连接。如果一个连接被借用时间超过了remove-abandoned-timeout例如300秒并且没有被归还Druid就会认为它泄露了。此时如果remove-abandoned为trueDruid会强制回收这个连接如果log-abandoned为true会打印出借用此连接的线程的堆栈信息帮助你定位是哪段代码没有关闭连接。警告remove-abandoned是一个“事后补救”机制它会强制关闭连接可能导致正在进行的事务被中断。它不能替代良好的编程习惯。正确的做法是在代码中使用try-with-resourcesJava 7或finally块确保资源关闭。开启此功能主要用于在过渡期或排查历史遗留问题时发现那些隐藏的泄露点。生产环境长期开启时超时时间可以设得长一些如10分钟避免误杀长时间运行的批处理任务。4.2 异步初始化与性能优化对于大型应用启动时初始化所有连接initial-size可能会拖慢启动速度。Druid支持异步初始化。spring: datasource: druid: # 异步初始化加快应用启动速度 async-init: true # 连接池的公平锁模式在高并发下更稳定但略有性能损耗 use-unfair-lock: false # 默认为true非公平锁高并发竞争激烈时可设为false尝试公平锁 # 连接持有时间监控用于分析连接使用是否合理 time-between-log-stats-millis: 300000 # 每5分钟输出一次统计日志到控制台调优建议async-init: true对于initial-size设置较大的场景如50开启此选项可以让你应用秒启连接在后台线程中慢慢建立。非常实用的一个特性。锁模式选择Druid内部使用重入锁管理连接池。use-unfair-lock: true默认性能更好但在极端高并发下可能造成线程饥饿。如果你监控到获取连接的等待时间异常波动可以尝试切换到公平锁false看是否更平滑。不过99%的场景默认值就够了。定期日志time-between-log-stats-millis会让Druid定期将关键统计信息活跃数、等待数等打印到日志便于你通过ELK等日志系统进行长期趋势分析而不仅仅依赖监控页面。4.3 集成Spring监控与多数据源配置集成Spring监控如果你想在Druid监控页面上看到Spring相关的监控信息如Controller方法调用次数、耗时需要额外引入druid-spring-boot-starter的依赖我们已经引入了并且确保spring-boot-starter-aop在类路径下。Druid会自动通过AOP切面进行统计。多数据源配置当你的项目需要连接多个数据库时Spring Boot的自动配置就不够用了。你需要手动定义多个DruidDataSource的Bean。Configuration public class DruidConfig { Bean ConfigurationProperties(spring.datasource.druid.master) public DataSource masterDataSource() { return DruidDataSourceBuilder.create().build(); } Bean ConfigurationProperties(spring.datasource.druid.slave) public DataSource slaveDataSource() { return DruidDataSourceBuilder.create().build(); } Primary // 指定主数据源 Bean public DataSource dynamicDataSource(Qualifier(masterDataSource) DataSource master, Qualifier(slaveDataSource) DataSource slave) { MapObject, Object targetDataSources new HashMap(); targetDataSources.put(master, master); targetDataSources.put(slave, slave); // 使用AbstractRoutingDataSource实现动态数据源路由 AbstractRoutingDataSource dynamicDataSource new AbstractRoutingDataSource() { Override protected Object determineCurrentLookupKey() { // 可以从ThreadLocal中获取当前要使用的数据源key例如 master 或 slave return DynamicDataSourceContextHolder.getDataSourceKey(); } }; dynamicDataSource.setDefaultTargetDataSource(master); dynamicDataSource.setTargetDataSources(targetDataSources); return dynamicDataSource; } // 配置Druid监控Servlet和Filter注意这里要注入的是最终的dynamicDataSource Bean public ServletRegistrationBeanStatViewServlet statViewServlet() { ServletRegistrationBeanStatViewServlet bean new ServletRegistrationBean(new StatViewServlet(), /druid/*); MapString, String initParams new HashMap(); initParams.put(loginUsername, admin); initParams.put(loginPassword, druid123); initParams.put(allow, 127.0.0.1); bean.setInitParameters(initParams); return bean; } Bean public FilterRegistrationBeanWebStatFilter webStatFilter() { FilterRegistrationBeanWebStatFilter bean new FilterRegistrationBean(new WebStatFilter()); bean.setUrlPatterns(Arrays.asList(/*)); MapString, String initParams new HashMap(); initParams.put(exclusions, *.js,*.gif,*.jpg,*.png,*.css,*.ico,/druid/*); bean.setInitParameters(initParams); return bean; } }然后在application.yml中分别配置两个数据源spring: datasource: druid: master: url: jdbc:mysql://master-host:3306/db username: ... password: ... initial-size: 5 # ... 其他master专属配置 slave: url: jdbc:mysql://slave-host:3306/db username: ... password: ... initial-size: 3 # ... 其他slave专属配置多数据源配置核心点Primary注解必须指定一个默认数据源否则Spring不知道注入哪个。动态数据源路由上面的例子使用了AbstractRoutingDataSource你需要自己实现DynamicDataSourceContextHolder一个基于ThreadLocal的工具类在Service层或AOP切面中根据业务逻辑如读操作用slave写操作用master设置当前线程要使用的数据源Key。监控配置在多数据源下自动配置的监控Servlet可能不工作。你需要像上面代码一样手动注册StatViewServlet和WebStatFilter并且确保Filter和Servlet能正确关联到你的数据源。更复杂的做法是为每个DruidDataSource单独配置一个StatFilter并绑定。5. 监控页面解读与常见问题排查配置完成后启动应用访问http://你的应用地址/druid/index.html输入配置的用户名密码就能看到功能强大的监控后台了。5.1 核心监控面板解读数据源这里显示连接池的基本状态。重点关注活跃连接数 (Active)当前正在被使用的连接数。如果长期接近max-active说明连接池大小可能不足。等待线程数 (WaitThreadCount)获取连接时发生等待的线程数。如果长期大于0说明连接不够用请求在排队。逻辑连接打开次数 (ConnectCount)和关闭次数(CloseCount)理论上这两个数应该接近。如果ConnectCount远大于CloseCount可能存在连接泄漏。SQL监控这里记录了所有执行过的SQL。重点关注执行时间找出最耗时的SQL慢SQL。执行次数找出执行最频繁的SQL考虑是否引入缓存。读取行数 (ResultSet)和更新行数 (Update)分析SQL效率。可以点击“SQL”列进行聚合分析查看同一模板SQL在不同参数下的执行情况。SQL防火墙展示被拦截的SQL攻击尝试。如果这里频繁出现记录说明你的应用可能正在被扫描或攻击。Web应用展示URL请求的监控数据类似于简易版的APM。可以查看每个URI的请求次数、耗时、Jdbc执行次数等帮助定位接口性能瓶颈。5.2 常见问题与排查实录问题一监控页面无法访问报404或空白页。检查1确认stat-view-servlet.enabled是否为true。检查2确认访问路径是否正确默认是/druid/*。检查3检查是否有其他过滤器或安全框架如Spring Security拦截了/druid/**路径。需要在安全配置中放行。检查4如果是多数据源手动配置确认是否手动注册了StatViewServlet。问题二应用运行一段时间后出现“获取连接超时”异常。排查步骤立刻打开Druid监控面板查看“数据源”页。如果“活跃连接数”等于max-active且“等待线程数”很多说明连接池已满。点击“连接堆栈”查看当前所有活跃连接正在执行的SQL。很可能是有慢SQL或事务未提交长时间占用连接。同时检查“SQL监控”页按“执行时间”倒序排列找出可疑的慢SQL。如果“活跃连接数”不高但“逻辑连接打开次数”异常高且“物理连接打开次数”也很高可能是连接泄漏。开启remove-abandoned和log-abandoned功能观察日志输出定位未关闭连接的代码位置。问题三监控页面显示的数据如SQL执行次数不准确或为零。检查1确认filters: stat已经配置。没有这个过滤器SQL监控功能不会生效。检查2检查是否使用了其他数据源代理如P6Spy可能会干扰Druid的统计。检查3某些特定类型的SQL如存储过程调用或通过某些特定框架早期版本的JPA Native Query执行的SQLDruid可能无法统计到。问题四应用启动特别慢。排查检查initial-size是否设置过大。如果数据库在远端建立多个连接本身就很耗时。可以尝试设置async-init: true让连接池在后台异步初始化。一个真实的踩坑案例我们有一个定时任务会在凌晨批量处理数据。最初没有配置test-while-idle某天数据库半夜例行维护重启后连接池里持有的连接全部失效。早上定时任务启动从池中拿到这些失效连接去执行SQL全部报“Communications link failure”错误导致任务失败。后来开启了test-while-idle并设置了合理的time-between-eviction-runs-millisDruid会定期检查并刷新连接这个问题再没出现过。配置Druid不是一劳永逸的事情。它更像是一个给你装上了仪表盘的汽车。你需要定期查看这些“仪表盘”监控页面了解你应用数据库连接的健康状况连接数压力、发动机效率SQL性能、以及是否有异常报警慢SQL、泄露连接。结合监控数据反复调整连接池参数、优化SQL语句才能真正让Druid成为你系统稳定运行的守护者而不是一个简单的连接池组件。