文章目录

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

背景介绍

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开启了对数据源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线程下，也就是立即加载