【沉淀之华】SpringBoot配置原生HikariCP数据源两次初始化过程剖析 & 服务器与本地完全一致却不同数据源结果定位
文章目录
背景介绍场景复现溯源彩蛋
背景介绍
JDK版本：1.8 SpringBoot： 2.2.3.RELEASE 整合原生Hikari数据源连接池 IDEA：2023.1
再保证服务器和本地的启动参数、apollo配置、代码分支完全一致的前提下，经过验证得到如下结论
在确定原生Hikari数据源配置是否生效时，发现引入Prometheus监控在本地和服务器环境在初始化数据源连接池是不一致的，具体表现： 只要是IDEA本地运行，在没有任何数据库操作的前提下监控数据：本地运行结果要么是正确的配置结果，要么配错了都是默认值10【以最大最小活跃连接数为例】 只要是云服务器运行，在没有任何数据库操作的前提下监控数据： 服务器运行结果要么是正确的配置，要么配错了最大最小活跃连接数而导致默认值是-1 SpringBoot配置Hikari初始化是懒加载的，只有在数据库操作时才初始化数据源【注意验证不要添加test-connect-query 会干扰实验结果】
怎么配置监控可以参考网上这位大佬：https://blog..net/qq_36120342/article/details/119740189【网上都有咱就不重复了】
于是本着知其然亦要知其所以然的原则开启本篇漫长排查分析之路…
场景复现
下面给出两个配置让大家感受下 这个差异过程
正确的配置
spring.datasource.hikari.allow-pool-suspension = true
spring.datasource.hikari.connection-timeout = 10000
spring.datasource.hikari.pool-name = My-Hikari
spring.datasource.hikari.idle-timeout = 60000
spring.datasource.hikari.maximum-pool-size = 300
spring.datasource.hikari.max-lifetime = 120000
spring.datasource.hikari.minimum-idle = 30
spring.datasource.type = com.zaxxer.hikari.HikariDataSource
spring.datasource.driver-class-name = com.mysql.cj.jdbc.Driver
spring.datasource.url = jdbc:mysql://a.com:4000/payment?characterEncoding=utf8&zeroDateTimeBehavior=convertToNull&serverTimezone=Asia/Shanghai
spring.datasource.username = xx
spring.datasource.password = sx
错误的配置 这个故意写错最大活跃连接数，为了凸显错误，所以只改一处
spring.datasource.hikari.max-pool-size = 300
本地和云服务器在正确的配置下 监控的数据如下: 这无可厚非，下面看看异常配置下本地和云服务器的差异
本地运行结果：
且本地有初始化日志
服务器运行结果 云服务器没有初始化日志
溯源
通过断点调试跟踪发现，本地能有初始化数据库连接池的日志，从堆栈看出是Springboot开启了对数据源jmx监控，也就是说开启了jmx，就会触发SpringBoot Actuator对数据源的健康检查，而健康检查其中会调用validate方法校验HikariConfig的配置合法性，对于非法的配置会设置默认值即10
这里是引用
那么问题来了，既然是SpringBoot行为，怎么会出现差异，原因如下： SpringBoot 2.2.x版本之前是默认开启jmx的，但是 2.2.x 以后是禁用JMX的，本文也是用的2.2.3，也就是说更不应该出现健康检查啊，在考虑所有代码配置和云服务器一样的背景下，我开始怀疑IDEA环境问题，最终在启动配置上发现问题所在 IDEA 2023.1 【看你的机器配置】的配置是默认帮你开启了JMX如下图【截图时我已经勾选】，所以无论SpringBoot行为如何，一定能触发健康检查，这才是导致差异的根本所在。 当勾选后，云服务器环境运行结果和本地完全一致。 ok，剩下懒加载问题就很好验证了，执行一个Sql看看是不是在sql执行后出现初始化日志，而此时再去刷新监控：http://localhost:8088/actuator/prometheus，可以看到最初的默认值-1 变为默认值10
本质是因为先执行sql去建立连接时成功触发validate方法完成最终初始化，至此问题剖析完毕。
彩蛋
如果的你结论和我不一样，那么极有可能是IDEA版本低或者使用了自动开启JMX的SpringBoot版本
那么我们推论到SpringBoot整合Dynamic-Source是不是也是懒加载的？结论不是 只要引入了dynamic-source依赖，无论你是否配置正确，都会尝试去加载，而且有个巨坑的点你即便配错了，只提示警告，但是只要一执行数据库操作，就会报错，找不到主数据源错误
印证如下： 可以看出这是main线程下，也就是立即加载
