文章目录
- 背景介绍
- 场景复现
- 溯源
- 彩蛋
背景介绍
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.csdn.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线程下，也就是立即加载
