上周五凌晨我们的支付对账服务突然开始疯狂打印DataSource is closed的报错。监控大盘显示数据库连接池活跃连接数归零而流量明明没有任何波动——这场景是不是让你想起某个不眠夜现象自动配置的智能成了定时炸弹问题出现在一个日均处理 200w 账务记录的 SpringBoot 2.7 服务。在接收到 Kafka 消息后服务会通过 JPA 写入 MySQL核心逻辑简单到只有三行Transactional public void handlePayment(PaymentMessage msg) { paymentRepository.save(new Payment(msg.getTxId(), msg.getAmount())); }但诡异的是当 Kafka 消费者重启时偶尔会触发整个连接池不可用。日志里明晃晃的HikariPool-1 - Database connection pool is closed和Cannot get a connection, pool error交替出现而这时离服务启动已经过去了 15 分钟。根因多数据源下的自动配置博弈经过反复复现和调试发现问题出在 SpringBoot 的自动配置竞速条件上。我们的项目由于历史原因混用了两个数据源主数据源通过ConfigurationProperties(prefix spring.datasource)显式配置监控数据源在另一个Configuration类里手动定义的DataSourceSpringBoot 的自动配置机制在这里玩了个危险游戏DataSourceAutoConfiguration看到存在自定义数据源配置后会跳过主数据源初始化但HikariAutoConfiguration仍然会尝试基于spring.datasource.hikari.参数构建连接池当监控数据源先完成初始化时主数据源的 Hikari 池会被误判为备用池而悄悄关闭用代码来说错误场景是这样的// 错误配置示例两个数据源配置互相干扰 Configuration public class MonitoringConfig { Bean ConfigurationProperties(monitoring.datasource) public DataSource monitoringDataSource() { return DataSourceBuilder.create().build(); // 这个先初始化了! } } // application.properties spring.datasource.urljdbc:mysql://primary-db spring.datasource.hikari.maximum-pool-size20 monitoring.datasource.urljdbc:mysql://monitoring-db解法用明确的条件注解划清界限正确的做法是强制让自动配置按我们设定的路线走Configuration // 关键注解明确排除自动数据源配置 EnableAutoConfiguration(exclude {DataSourceAutoConfiguration.class}) public class PrimaryDataSourceConfig { Primary Bean ConfigurationProperties(spring.datasource.hikari) public DataSource primaryDataSource() { return DataSourceBuilder.create().type(HikariDataSource.class).build(); } } Configuration public class MonitoringConfig { Bean ConfigurationProperties(monitoring.datasource) public DataSource monitoringDataSource() { return DataSourceBuilder.create().build(); } }性能对比改造后服务启动时间从原来偶尔出现的 15 分钟连接池故障降低到完全稳定的 30 秒内可用。避坑清单多数据源场景下的死亡陷阱隐式依赖陷阱当你混合使用spring-boot-starter-data-jpa和手动数据源时HibernateJpaAutoConfiguration可能偷偷使用错误的数据源连接池参数失效如果没显式指定type HikariDataSource.class连接池参数可能被默认配置覆盖监控指标错乱多个 Hikari 池的 JMX 注册名称冲突会导致监控数据互相覆盖测试环境假象用 H2 内存数据库测试时可能掩盖这个问题因为 H2 的连接管理行为与生产数据库不同写在最后SpringBoot 自动配置的本质是一套精巧的约定优于配置机制但当你需要打破这些约定时必须用显式声明替代隐式魔法。下次看到数据库连接池神秘关闭时不妨先检查是否存在配置边界模糊的问题——你在多数据源项目里还踩过哪些坑欢迎分享你的战场故事。
上周五凌晨我们的支付对账服务突然开始疯狂打印DataSource is closed的报错。监控大盘显示数据库连接池活跃连接数归零而流量明明没有任何波动——这场景是不是让你想起某个不眠夜现象自动配置的智能成了定时炸弹问题出现在一个日均处理 200w 账务记录的 SpringBoot 2.7 服务。在接收到 Kafka 消息后服务会通过 JPA 写入 MySQL核心逻辑简单到只有三行Transactional public void handlePayment(PaymentMessage msg) { paymentRepository.save(new Payment(msg.getTxId(), msg.getAmount())); }但诡异的是当 Kafka 消费者重启时偶尔会触发整个连接池不可用。日志里明晃晃的HikariPool-1 - Database connection pool is closed和Cannot get a connection, pool error交替出现而这时离服务启动已经过去了 15 分钟。根因多数据源下的自动配置博弈经过反复复现和调试发现问题出在 SpringBoot 的自动配置竞速条件上。我们的项目由于历史原因混用了两个数据源主数据源通过ConfigurationProperties(prefix spring.datasource)显式配置监控数据源在另一个Configuration类里手动定义的DataSourceSpringBoot 的自动配置机制在这里玩了个危险游戏DataSourceAutoConfiguration看到存在自定义数据源配置后会跳过主数据源初始化但HikariAutoConfiguration仍然会尝试基于spring.datasource.hikari.参数构建连接池当监控数据源先完成初始化时主数据源的 Hikari 池会被误判为备用池而悄悄关闭用代码来说错误场景是这样的// 错误配置示例两个数据源配置互相干扰 Configuration public class MonitoringConfig { Bean ConfigurationProperties(monitoring.datasource) public DataSource monitoringDataSource() { return DataSourceBuilder.create().build(); // 这个先初始化了! } } // application.properties spring.datasource.urljdbc:mysql://primary-db spring.datasource.hikari.maximum-pool-size20 monitoring.datasource.urljdbc:mysql://monitoring-db解法用明确的条件注解划清界限正确的做法是强制让自动配置按我们设定的路线走Configuration // 关键注解明确排除自动数据源配置 EnableAutoConfiguration(exclude {DataSourceAutoConfiguration.class}) public class PrimaryDataSourceConfig { Primary Bean ConfigurationProperties(spring.datasource.hikari) public DataSource primaryDataSource() { return DataSourceBuilder.create().type(HikariDataSource.class).build(); } } Configuration public class MonitoringConfig { Bean ConfigurationProperties(monitoring.datasource) public DataSource monitoringDataSource() { return DataSourceBuilder.create().build(); } }性能对比改造后服务启动时间从原来偶尔出现的 15 分钟连接池故障降低到完全稳定的 30 秒内可用。避坑清单多数据源场景下的死亡陷阱隐式依赖陷阱当你混合使用spring-boot-starter-data-jpa和手动数据源时HibernateJpaAutoConfiguration可能偷偷使用错误的数据源连接池参数失效如果没显式指定type HikariDataSource.class连接池参数可能被默认配置覆盖监控指标错乱多个 Hikari 池的 JMX 注册名称冲突会导致监控数据互相覆盖测试环境假象用 H2 内存数据库测试时可能掩盖这个问题因为 H2 的连接管理行为与生产数据库不同写在最后SpringBoot 自动配置的本质是一套精巧的约定优于配置机制但当你需要打破这些约定时必须用显式声明替代隐式魔法。下次看到数据库连接池神秘关闭时不妨先检查是否存在配置边界模糊的问题——你在多数据源项目里还踩过哪些坑欢迎分享你的战场故事。
