1. 项目概述为什么一个连接池值得你花三天时间重读源码Spring Boot 项目上线后数据库响应突然变慢QPS 从 1200 掉到 300监控显示线程池满、连接等待超时但 MySQL 的Threads_connected却只有 47——这根本不是数据库扛不住是应用层的连接没放回去。我去年在金融支付中台踩过这个坑凌晨三点收到告警查日志发现全是HikariPool-1 - Connection is not available, request timed out after 30000ms.而 DBA 坚称“数据库负载不到 30%慢查询零条”。最后定位到一行被注释掉的Transactional导致事务未正常提交连接被长期占用。这不是个例而是 HikariCP 在 Spring Boot 中被当作“开箱即用”的黑盒后最典型的认知断层。你手里的spring-boot-starter-jdbc默认就带了 HikariCP但它绝不是配个spring.datasource.hikari.maximum-pool-size20就能高枕无忧的组件。它是一套精密的连接生命周期控制器背后有状态机管理POOL_NORMAL/POOL_SUSPENDED/POOL_SHUTDOWN、空闲连接回收定时器HouseKeeper、连接健康度探测connection-test-query或validation-timeout、甚至还有针对不同 JDBC 驱动的兼容性补丁比如 Oracle 的oracle.jdbc.ReadTimeout。这些能力在开发环境跑得飞快一上生产就集体失灵——因为开发库是单机 MySQL生产是分库分表读写分离中间件代理网络延迟从 0.2ms 涨到 8ms而你的connection-timeout还卡在默认的 30 秒。这篇文章不讲“HikariCP 是什么”也不罗列所有配置项。我要带你做三件事第一用真实压测数据告诉你调哪个参数能让吞吐量提升 3.7 倍而不是拍脑袋设成 100第二还原一次线上连接泄漏的完整排查链路——从 JVM 线程栈 dump 到 HikariCP 内部ConcurrentBag状态分析第三把“故障防御”落到代码里不是加个熔断器就叫防御而是让连接池在 DNS 故障、DB 主从切换、驱动 Bug 等 7 类典型异常下自动降级、隔离、报警、自愈。全文所有结论都来自我们团队在 2023 年支撑日均 4.2 亿次数据库调用的支付中台实战配置已沉淀为公司《Java 生产规范 V3.2》第 4.7 条。2. 连接池调优的本质不是设数字而是建模型2.1 为什么“最大连接数CPU核数×2”是毒药很多教程教你在application.yml里写spring: datasource: hikari: maximum-pool-size: 20 minimum-idle: 5然后告诉你“这是经验值够用了”。错。这等于让司机闭着眼开车只靠“别人说油门踩一半就行”。HikariCP 的吞吐能力取决于三个刚性约束并发请求数QPS× 平均连接持有时间ms÷ 1000 理论最小连接数。举个真实例子我们有个订单查询接口压测 QPS 为 800平均 DB 耗时含网络120ms那么理论最小连接数 800 × 0.12 96。你设maximum-pool-size20等于让 800 个线程抢 20 个连接排队等待时间必然暴涨。我们实测过当connection-timeout设为 30 秒时平均等待时间从 2ms 涨到 18.4 秒TP99 直接从 150ms 崩到 18.6 秒。更致命的是这个公式还漏了一个关键变量连接创建成本。MySQL 默认wait_timeout288008 小时但 HikariCP 创建新连接要走 TCP 握手 SSL 加密 认证 初始化 session 变量实测在阿里云 RDS 上平均耗时 120~200ms。如果你的minimum-idle5但流量突增时需要瞬间创建 50 个新连接这 50×150ms 7.5 秒的阻塞足够让整个服务雪崩。所以minimum-idle不是保底值而是预热缓冲区——它必须覆盖日常流量波峰的基线连接需求避免冷启动抖动。我们最终采用的建模法是“双阈值动态计算”基线连接数 日均峰值 QPS × P95 持有时间 ÷ 1000 × 1.2安全系数弹性上限 基线连接数 × 2.5应对突发流量但不超过 DB 最大连接数的 70%以我们订单服务为例日均峰值 QPS1200P95 持有时间95ms → 基线1200×0.095×1.2136.8 → 取整 140DB 最大连接数2000 → 弹性上限140×2.5350且 3502000×0.71400合规。最终配置为maximum-pool-size350minimum-idle140。上线后连接等待时间为 0GC 次数下降 41%因减少了连接对象频繁创建销毁。2.2connection-timeout和validation-timeout的生死时速这两个参数常被混为一谈但它们守的是完全不同的门。connection-timeout是客户端等待连接的倒计时单位毫秒默认 3000030 秒。它解决的问题是“如果池子里没空闲连接我最多等多久” 而validation-timeout是连接校验的倒计时单位毫秒默认 50005 秒它只在连接被借出前触发用来执行SELECT 1或驱动原生校验确保连接没断。问题来了如果你的数据库主从切换花了 8 秒validation-timeout5000就会导致所有借连接的线程在第 5 秒时失败报Validation timeout occurred。但此时连接其实已经恢复只是校验超时了。我们曾因此误判为 DB 故障紧急回滚结果发现 DB 一切正常——是校验超时在背锅。正确的做法是validation-timeout必须小于connection-timeout且大于网络 P99 RTT。我们通过ping -c 10 rds-mysql-prod测得生产环境到 RDS 的 P99 RTT18ms所以validation-timeout设为 20002 秒足够。而connection-timeout不能拍脑袋要按业务容忍度设支付类接口要求 TP99500ms那连接等待必须控制在 100ms 内所以设connection-timeout100。这意味着如果池子空了线程会立刻失败而不是傻等 30 秒。配合spring.cloud.loadbalancer.retry.enabledfalse禁用重试避免失败请求被重发二次打爆连接池。提示connection-timeout100后必须配套leak-detection-threshold60000连接泄漏检测阈值设为 60 秒。因为连接只借 100ms但业务代码可能因 bug 占用连接 60 秒这时 HikariCP 会主动打印Connection leak detection triggered日志并关闭该连接防止池子被僵尸连接占满。2.3idle-timeout与max-lifetime的协同陷阱idle-timeout空闲连接最大存活时间和max-lifetime连接最大生命周期看起来都是“过期清理”但逻辑完全不同。idle-timeout针对的是池中未被借用的空闲连接比如你设minimum-idle10但当前只有 5 个连接在用剩下 5 个空闲它们会在idle-timeout后被物理关闭。而max-lifetime针对的是所有被创建出来的连接无论是否空闲只要活过这个时间就强制关闭重建。陷阱在于如果max-lifetime idle-timeout会出现“连接还没空闲就被杀”的诡异现象。我们曾设max-lifetime180000030 分钟idle-timeout60000010 分钟结果监控发现连接每 10 分钟批量断开一次日志里全是HikariPool-1 - Pool stats (total10, active0, idle10, waiting0)突然变成(total0, active0, idle0, waiting0)。查源码发现HouseKeeper定时任务会优先检查max-lifetime只要连接创建时间超过此值立即标记为evict根本不管它是不是空闲。正确姿势是max-lifetime必须大于idle-timeout且留出至少 30 秒缓冲。我们生产环境设max-lifetime360000060 分钟idle-timeout3000005 分钟缓冲 55 分钟。这样空闲连接先在 5 分钟后被清理活跃连接则在 60 分钟后强制重建既避免了 MySQL 的wait_timeout断连RDS 默认 8 小时但网络设备可能 30 分钟断空闲连接又不会因频繁重建增加 DB 压力。2.4allow-pool-suspension那个被 99% 项目忽略的“暂停键”这个布尔参数默认false文档里只有一行“This property controls whether the pool can be suspended.” 很多人直接跳过。但它在灰度发布、数据库维护时是救命稻草。设为true后你可以通过 JMX 或 Actuator 端点动态执行suspendPool()让 HikariCP 立刻停止向应用提供新连接但已借出的连接继续使用直到归还。这相当于给连接池装了个“软刹车”。我们做 RDS 版本升级时DBA 要求停写 10 分钟。传统做法是停应用但订单服务有 12 个实例滚动重启要 8 分钟且正在处理的订单会失败。我们改用suspendPool()先调用/actuator/hikaricp/suspend需暴露端点所有实例连接池立即进入POOL_SUSPENDED状态新请求全部快速失败Pool is suspended老请求平稳完成。10 分钟后调用/actuator/hikaricp/resume连接池自动恢复。全程无订单丢失用户无感知。注意启用此功能必须同时配置spring.datasource.hikari.register-mbeanstrue否则 JMX 不可用Actuator 端点需在application.yml中显式暴露management: endpoints: web: exposure: include: health,info,metrics,hikaricp3. 生产级故障防御7 类场景的代码级防御方案3.1 场景一DNS 故障导致连接池雪崩——用socketTimeout精准截断当 DNS 服务器宕机InetAddress.getByName(rds-mysql-prod)会阻塞长达 30 秒JVM 默认networkaddress.cache.ttl30而 HikariCP 创建连接时会先解析域名。此时maximum-pool-size350350 个线程全卡在 DNS 解析上CPU 100%服务不可用。这不是连接池的锅是 JVM 网络层的锅。防御方案在 JDBC URL 中强制指定socketTimeout并禁用 DNS 缓存。我们用的是 MySQL Connector/J 8.0.33URL 配置如下spring: datasource: url: jdbc:mysql://rds-mysql-prod:3306/order_db?useSSLfalseserverTimezoneAsia/ShanghaiconnectTimeout3000socketTimeout5000cachePrepStmtstrueprepStmtCacheSize250prepStmtCacheSqlLimit2048useServerPrepStmtstruerewriteBatchedStatementstrueallowPublicKeyRetrievaltrue关键参数connectTimeout3000TCP 连接建立超时3 秒内连不上就失败socketTimeout5000网络读写超时5 秒内没收到响应就断开cachePrepStmtstrue等是性能优化非防御项但光这样还不够。我们写了DnsFailoverFilter在应用启动时预热 DNSComponent public class DnsFailoverFilter implements ApplicationRunner { Override public void run(ApplicationArguments args) throws Exception { try { InetAddress.getByName(rds-mysql-prod); log.info(DNS pre-warm success for rds-mysql-prod); } catch (UnknownHostException e) { log.error(DNS pre-warm failed, fallback to IP, e); // 读取配置中心的备用 IP 列表注入到 HikariConfig String backupIp ConfigCenter.get(mysql.backup.ip); HikariConfig config new HikariConfig(); config.setJdbcUrl(jdbc:mysql:// backupIp :3306/order_db?...); } } }这样DNS 故障时应用启动直接切到备用 IP连接池初始化成功服务照常运行。3.2 场景二MySQL 主从切换期间的连接失效——用failOverReadOnly自动降级RDS 主从切换时旧主库会变为只读但 HikariCP 不知道还在往它上面发写请求报The MySQL server is running with the --read-only option so it cannot execute this statement。传统方案是等 30 秒wait_timeout后连接自动断但业务已大量失败。MySQL Connector/J 提供了failOverReadOnlytrue参数默认true配合secondsBeforeRetryMaster60可实现自动故障转移。但要注意它只对SQLException中包含ER_MASTER_IS_READ_ONLY错误码的异常生效。我们封装了FailoverDataSourcepublic class FailoverDataSource extends HikariDataSource { private final String masterUrl; private final String slaveUrl; public FailoverDataSource(String masterUrl, String slaveUrl) { this.masterUrl masterUrl; this.slaveUrl slaveUrl; // 初始化主库连接池 HikariConfig config new HikariConfig(); config.setJdbcUrl(masterUrl failOverReadOnlytruesecondsBeforeRetryMaster60); this.setConfiguration(config); } Override public Connection getConnection() throws SQLException { try { return super.getConnection(); } catch (SQLException e) { if (e.getSQLState().equals(HY000) e.getMessage().contains(read-only)) { log.warn(Master is read-only, switching to slave for read-only operation); // 切换到从库连接池需预先初始化 return slaveDataSource.getConnection(); } throw e; } } }这样当主库只读时写操作失败后自动降级到从库执行读操作保证查询不中断。3.3 场景三连接泄漏的实时捕获与自愈——leak-detection-threshold的深度定制HikariCP 的leak-detection-threshold默认 0关闭设为 6000060 秒后会在连接被借出 60 秒未归还时打印堆栈并关闭连接。但这只是“事后灭火”我们要“事前预警”。我们扩展了HikariPool重写getConnection方法加入连接借用追踪public class TrackedHikariPool extends HikariPool { private final MapLong, Long borrowTimes new ConcurrentHashMap(); private final MapLong, Exception borrowStacks new ConcurrentHashMap(); Override public ProxyConnection getConnection(final long hardTimeout) throws SQLException { final ProxyConnection connection super.getConnection(hardTimeout); final long threadId Thread.currentThread().getId(); borrowTimes.put(threadId, System.currentTimeMillis()); borrowStacks.put(threadId, new Exception(Connection borrowed at new Date())); return connection; } Override public void recycle(final ProxyConnection connection) { final long threadId Thread.currentThread().getId(); borrowTimes.remove(threadId); borrowStacks.remove(threadId); super.recycle(connection); } // 暴露检查方法供定时任务调用 public ListLeakInfo checkLeaks() { final long now System.currentTimeMillis(); return borrowTimes.entrySet().stream() .filter(entry - now - entry.getValue() 30000) // 30秒以上视为潜在泄漏 .map(entry - new LeakInfo(entry.getKey(), entry.getValue(), borrowStacks.get(entry.getKey()))) .collect(Collectors.toList()); } }再配一个Scheduled(fixedRate 30000)定时任务每 30 秒扫描一次发现泄漏立即发企业微信告警并记录到 ELK{ level: WARN, message: Connection leak detected, threadId: 12345, borrowTime: 2023-10-15T14:22:10.123Z, stackTrace: at com.xxx.service.OrderService.createOrder(OrderService.java:45) }上线后我们 3 天内捕获 7 次泄漏定位到 3 个try-with-resources忘写、2 个Transactional传播行为错误、2 个异步线程未手动关闭连接。3.4 场景四驱动 Bug 导致的连接假死——connection-test-query的精准打击MySQL Connector/J 8.0.28 有一个 Bug当连接空闲超过wait_timeout后isValid()方法返回true但实际执行 SQL 会报Communications link failure。HikariCP 的connection-test-query默认用isValid()这就导致“假健康”连接被借出业务失败。解决方案禁用isValid()改用SELECT 1显式测试。在application.yml中spring: datasource: hikari: connection-test-query: SELECT 1 validation-timeout: 2000但SELECT 1有性能损耗。我们做了优化只在连接空闲超过wait_timeout * 0.8时才测试。HikariCP 源码中PoolBase类的isConnectionAlive方法可被重写public class OptimizedPoolBase extends PoolBase { Override boolean isConnectionAlive(final Connection connection) throws SQLException { final long idleMs System.currentTimeMillis() - lastAccessTime; if (idleMs waitTimeoutMs * 0.8) { // 空闲超 80%执行 SELECT 1 try (Statement stmt connection.createStatement()) { stmt.execute(SELECT 1); return true; } catch (SQLException e) { log.warn(Connection test failed, closing, e); return false; } } // 否则用 isValid()轻量 return connection.isValid(1); } }实测将连接校验耗时从平均 15ms 降到 2msQPS 提升 12%。3.5 场景五海量小连接冲击——concurrentBag的锁竞争优化HikariCP 的ConcurrentBag是连接池的核心数据结构用CopyOnWriteArrayList存储待分配连接用SynchronousQueue存储待回收连接。当 QPS 超过 5000borrow操作的 CAS 竞争会飙升Thread.getState()显示大量线程卡在BLOCKED状态。我们对比了三种方案方案 A升级到 HikariCP 5.0.0引入StripedLock优化方案 B将ConcurrentBag替换为Disruptor无锁队列改造成本高方案 C调整minimum-idle让连接池始终有足够空闲连接避免borrow时创建新连接实测方案 C 最有效将minimum-idle从 140 提到 200borrow操作 99% 走空闲连接路径CAS 竞争下降 92%BLOCKED线程归零。代价是内存多占 20MB200 个连接对象但远低于 GC 频繁带来的 STW 损耗。3.6 场景六连接池状态突变——HouseKeeper的心跳守护HouseKeeper是 HikariCP 的后台线程负责空闲连接回收、连接生命周期检查、泄露检测。默认每 30 秒执行一次。但在高负载下它可能被 JVM GC 暂停导致idle-timeout失效空闲连接堆积。我们给HouseKeeper加了心跳监控Component public class HouseKeeperHealthChecker { private final ScheduledExecutorService scheduler Executors.newSingleThreadScheduledExecutor(); PostConstruct public void start() { scheduler.scheduleAtFixedRate(this::checkHouseKeeper, 0, 30, TimeUnit.SECONDS); } private void checkHouseKeeper() { try { // 通过 JMX 获取 HouseKeeper 最后执行时间 ObjectName name new ObjectName(com.zaxxer.hikari:typePool (HikariPool-1)); Long lastExec (Long) mBeanServer.getAttribute(name, LastHouseKeeperExecution); if (System.currentTimeMillis() - lastExec 60000) { // 超过 60 秒未执行 log.error(HouseKeeper stalled! Triggering manual execution); mBeanServer.invoke(name, runHouseKeeper, null, null); } } catch (Exception e) { log.error(HouseKeeper health check failed, e); } } }这样一旦HouseKeeper卡住立即手动触发保证连接池状态及时更新。3.7 场景七全链路可观测性——从连接池到业务的 Trace 透传连接池问题最难 debug是因为它横跨应用层和 DB 层。我们用 SkyWalking 做了深度集成在HikariDataSource的getConnection方法前后埋点记录连接获取耗时、连接 ID、线程 ID将连接 ID 注入到 SkyWalking 的Span标签中span.tag(db.connection.id, connectionId)在 MyBatis 的Interceptor中将同一个连接 ID 关联到所有 SQL 执行 Span。这样在 SkyWalking UI 中点击一个慢 SQL 的 Span就能看到它是从哪个连接池借的HikariPool-1借用耗时多少2ms连接 ID 是多少conn-7a8b9c同一个连接 ID 下之前执行过哪些 SQL形成连接级调用链我们曾用此功能发现一个SELECT * FROM order WHERE user_id?查询平均耗时 800ms但关联的连接 ID 下前一条UPDATE order SET statuspaid耗时 790ms说明不是查询慢是连接被前一个长事务占着。根因是Transactional传播行为设成了REQUIRES_NEW导致事务嵌套过深。4. 全链路实战从本地验证到生产灰度的 5 步落地法4.1 第一步本地压测——用 wrk 模拟真实流量别信 JMeter 的线程组。wrk是真正的高并发 HTTP 压测工具单机轻松压出 2 万 QPS。我们用它测连接池# 模拟 1000 并发持续 60 秒GET /order/{id} wrk -t12 -c1000 -d60s --latency http://localhost:8080/order/123关键看三个指标连接等待时间wrk 输出的Latency Distribution中50%和99%值应稳定在 10ms 内错误率Non-2xx or 3xx responses应为 0HikariCP 指标访问http://localhost:8080/actuator/metrics/hikaricp.connections.acquire看count是否平滑增长无尖刺。我们发现当maximum-pool-size20时99%延迟飙到 12.4 秒调到 140 后降到 8ms。这就是数据说话。4.2 第二步预发环境混沌测试——用 ChaosBlade 注入故障预发环境不是缩小版生产而是故障演练场。我们用 ChaosBlade 模拟 7 类故障故障类型ChaosBlade 命令验证目标网络延迟blade create network delay --time 100 --interface eth0socketTimeout是否生效DNS 故障blade create dns error --domain rds-mysql-prod备用 IP 是否自动启用MySQL 只读mysql -e set global read_onlyon;failOverReadOnly是否降级连接数耗尽mysql -e set global max_connections10;connection-timeout是否快速失败主从断连iptables -A OUTPUT -d rds-slave-ip -j DROP从库连接是否自动剔除每次故障注入后观察http://localhost:8080/actuator/prometheus中的hikaricp_connections_active、hikaricp_connections_idle、hikaricp_connections_pending指标变化确保连接池状态符合预期。4.3 第三步生产灰度——用 Apollo 配置中心动态调控生产环境绝不允许重启。我们把所有 HikariCP 参数接入 Apollo# application.properties spring.datasource.hikari.maximum-pool-size${hikari.maximum-pool-size:140} spring.datasource.hikari.minimum-idle${hikari.minimum-idle:140} spring.datasource.hikari.connection-timeout${hikari.connection-timeout:100}在 Apollo 中新建hikari命名空间为每个集群prod-a, prod-b设置不同值。灰度时先调prod-a的maximum-pool-size200观察 1 小时无异常再推prod-b。所有变更实时生效无需重启。4.4 第四步监控告警——Grafana Prometheus 的黄金指标我们在 Prometheus 中抓取 HikariCP 的 4 个黄金指标# 连接池使用率越接近 100% 越危险 100 * hikaricp_connections_active{applicationorder-service} / hikaricp_connections_max{applicationorder-service} # 连接等待队列长度0 表示有排队 hikaricp_connections_pending{applicationorder-service} # 连接泄漏率每分钟泄漏连接数 rate(hikaricp_connections_leaked_total{applicationorder-service}[1m]) # 连接创建失败率反映 DB 或网络问题 rate(hikaricp_connections_creation_failures_total{applicationorder-service}[1m])在 Grafana 中建 Dashboard设置告警规则connections_pending 5持续 2 分钟 → 企业微信告警级别 P2connections_leaked_total 0→ 立即告警级别 P1connections_creation_failures_total 10/分钟 → 触发 DB 健康检查脚本。4.5 第五步复盘文档——生成每个服务的《连接池健康报告》每次大促或故障后我们用脚本自动生成 PDF 报告# generate_health_report.py import pandas as pd from fpdf import FPDF def generate_report(service_name): # 从 Prometheus API 拉取过去 7 天指标 metrics get_prometheus_metrics(service_name) pdf FPDF() pdf.add_page() pdf.set_font(Arial, size12) pdf.cell(200, 10, txtf{service_name} 连接池健康报告, lnTrue, alignC) # 插入关键图表用 matplotlib 生成 PNG plot_usage_rate(metrics) pdf.image(usage_rate.png, x10, y30, w180) # 插入配置快照 pdf.set_y(120) pdf.cell(0, 10, txt当前配置:, lnTrue) for k, v in current_config.items(): pdf.cell(0, 6, txtf{k}: {v}, lnTrue) pdf.output(f{service_name}_hikari_report.pdf)报告包含使用率趋势图、配置快照、Top3 异常连接堆栈、优化建议。这份报告是 SRE 团队每月复盘的必读材料。5. 实操心得与避坑指南那些文档里不会写的真相5.1 关于auto-commit永远不要相信框架的默认值Spring Boot 的DataSourceTransactionManager默认开启auto-committrue但 HikariCP 的auto-commit默认是true。表面看一致但问题出在Transactional。当你在一个Transactional(propagation Propagation.REQUIRED)方法里执行 SQLSpring 会先调用connection.setAutoCommit(false)事务结束后再设回true。但如果方法抛异常setAutoCommit(true)可能不被执行连接就永久处于auto-commitfalse状态。我们遇到过一个批处理服务循环插入 1000 条记录每条都INSERT INTO log VALUES (?)没加事务。结果连接池里所有连接的auto-commit都是false导致后续的SELECT也变成事务内执行锁表风险激增。解决方案在application.yml中强制指定spring.datasource.hikari.auto-committrue并在PostConstruct中校验Component public class AutoCommitValidator { Autowired private HikariDataSource dataSource; PostConstruct public void validateAutoCommit() throws SQLException { try (Connection conn dataSource.getConnection()) { if (!conn.getAutoCommit()) { throw new RuntimeException(HikariCP auto-commit is false! Check configuration.); } } } }5.2 关于leak-detection-threshold设太小会误伤设太大会漏检设leak-detection-threshold1000010 秒看似严格但会误报。比如一个报表导出接口要查 10 张表JOIN 5 次耗时 12 秒HikariCP 就会把它当泄漏关掉用户看到 500 错误。我们的经验是设为业务最长合理耗时的 1.5 倍。我们所有接口的 P99 耗时都在 3 秒内所以设leak-detection-threshold45004.5 秒。既覆盖了绝大多数泄漏又放过真正的大查询。5.3 关于initialization-fail-timeout别让它成为启动瓶颈这个参数默认 -1无限等待意思是“连不上 DB 就一直卡着不启动”。在 K8s 环境下Pod 启动超时默认 30 秒会被 kill导致反复重启。我们设为initialization-fail-timeout50005 秒并在启动类中捕获HikariPool.PoolInitializationExceptionSpringBootApplication public class OrderApplication { public static void main(String[] args) { try { SpringApplication.run(OrderApplication.class, args); } catch (Exception e) { if (e.getCause() instanceof HikariPool.PoolInitializationException) { log.error(HikariCP init failed, exiting to avoid crashloop, e); System.exit(1); // 让 K8s 重启而不是卡住 } throw e; } } }5.4 关于metricRegistryMicrometer 不是银弹很多教程教你配 spring.datasource.hikari.metric-