【沉淀之华】SpringBoot配置原生HikariCP数据源两次初始化过程剖析 & 服务器与本地完全一致却不同数据源结果定位

文章目录

    • 背景介绍
    • 场景复现
    • 溯源
    • 彩蛋

背景介绍

JDK版本:1.8
SpringBoot: 2.2.3.RELEASE 整合原生Hikari数据源连接池
IDEA:2023.1

再保证服务器和本地的启动参数、apollo配置、代码分支完全一致的前提下,经过验证得到如下结论

  1. 在确定原生Hikari数据源配置是否生效时,发现引入Prometheus监控在本地和服务器环境在初始化数据源连接池是不一致的,具体表现:
    只要是IDEA本地运行,在没有任何数据库操作的前提下监控数据:本地运行结果要么是正确的配置结果,要么配错了都是默认值10【以最大最小活跃连接数为例】

    只要是云服务器运行,在没有任何数据库操作的前提下监控数据: 服务器运行结果要么是正确的配置,要么配错了最大最小活跃连接数而导致默认值是-1

  2. 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配置原生HikariCP数据源两次初始化过程剖析 & 服务器与本地完全一致却不同数据源结果定位_第1张图片
且本地有初始化日志
【沉淀之华】SpringBoot配置原生HikariCP数据源两次初始化过程剖析 & 服务器与本地完全一致却不同数据源结果定位_第2张图片

服务器运行结果
在这里插入图片描述
云服务器没有初始化日志


溯源

【沉淀之华】SpringBoot配置原生HikariCP数据源两次初始化过程剖析 & 服务器与本地完全一致却不同数据源结果定位_第3张图片

通过断点调试跟踪发现,本地能有初始化数据库连接池的日志,从堆栈看出是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行为如何,一定能触发健康检查,这才是导致差异的根本所在。
【沉淀之华】SpringBoot配置原生HikariCP数据源两次初始化过程剖析 & 服务器与本地完全一致却不同数据源结果定位_第4张图片
当勾选后,云服务器环境运行结果和本地完全一致。
ok,剩下懒加载问题就很好验证了,执行一个Sql看看是不是在sql执行后出现初始化日志,而此时再去刷新监控:http://localhost:8088/actuator/prometheus,可以看到最初的默认值-1 变为默认值10

在这里插入图片描述
本质是因为先执行sql去建立连接时成功触发validate方法完成最终初始化,至此问题剖析完毕。


彩蛋

如果的你结论和我不一样,那么极有可能是IDEA版本低或者使用了自动开启JMX的SpringBoot版本

那么我们推论到SpringBoot整合Dynamic-Source是不是也是懒加载的?结论不是
只要引入了dynamic-source依赖,无论你是否配置正确,都会尝试去加载,而且有个巨坑的点你即便配错了,只提示警告,但是只要一执行数据库操作,就会报错,找不到主数据源错误

印证如下:
在这里插入图片描述
可以看出这是main线程下,也就是立即加载

你可能感兴趣的:(沉淀之华,spring,boot,Hikari,数据源,JMX)