如何在Java中开发多数据源动态切换应用_AbstractRoutingDataSource与ThreadLocal实战-java教程-PHP中文网

AbstractRoutingDataSource 必须配 ThreadLocal，因其不保存数据源标识，每次 getConnection() 时依赖 determineCurrentLookupKey() 动态获取键，而该键需通过 ThreadLocal 在线程上下文中传递，否则多线程下会因共享状态导致路由错乱、连接异常或跨库查询。

如何在java中开发多数据源动态切换应用_abstractroutingdatasource与threadlocal实战

为什么 AbstractRoutingDataSource 必须配 ThreadLocal

因为 AbstractRoutingDataSource 本身不保存数据源标识，它只在每次 getConnection() 时调用 determineCurrentLookupKey() 查一次键——这个键得靠外部线程上下文传进来。不用 ThreadLocal，多线程下会互相覆盖、路由错乱。

常见错误现象：Connection closed 或查到别的库的表，尤其在 Spring MVC 异步请求、定时任务、CompletableFuture 场景下高频复现。

必须在业务入口（如 Controller 方法开始）就用 DataSourceContextHolder.set("slave1") 显式设键，不能依赖“上一个请求留下的值”
ThreadLocal 需手动 remove()，否则线程复用（如 Tomcat 线程池）会导致脏数据；建议用 try-finally 包裹
Spring AOP 切面里设键时，注意切点是否覆盖了异步方法（@Async 默认新开线程，原 ThreadLocal 不继承）

AbstractRoutingDataSource 的 determineCurrentLookupKey 返回 null 怎么办

返回 null 会触发 NoSuchBeanDefinitionException: No bean named 'null' available，本质是 Spring 尝试从 targetDataSources Map 中找 key 为 null 的数据源。

使用场景：切换逻辑有分支未覆盖（比如没处理默认主库）、或 ThreadLocal 取值前没初始化。

务必在 determineCurrentLookupKey() 开头加空值兜底：return DataSourceContextHolder.get() != null ? DataSourceContextHolder.get() : "master"
不要在 determineCurrentLookupKey() 里做耗时操作（如查 DB、远程调用），它在每次获取连接时都执行，直接影响 SQL 性能
如果用枚举管理数据源名，确保 toString() 或 name() 和 targetDataSources 的 key 完全一致（大小写敏感）

多数据源事务失效的典型原因

Spring 原生 @Transactional 只绑定单个 DataSource，跨数据源时事务无法传播——不是配置问题，是底层 JDBC/XA 限制。

java-api-doc-generator

分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。

下载

错误现象：主库插入成功、从库更新失败，但主库未回滚；或抛出 Cannot change transaction isolation level after connection has been obtained。

同一个事务内禁止切换数据源（即不能在 @Transactional 方法中调用两次不同 set()）
需要强一致性时，改用 JtaTransactionManager + XA 数据源（如 Atomikos），但性能损耗明显，且 MySQL 8.0.30+ 才完整支持 XA PREPARE
多数业务用最终一致性：主库写后发 MQ，下游服务消费并更新其他库，通过本地事务表+定时补偿

动态增删数据源时如何避免 ConcurrentModificationException

AbstractRoutingDataSource 的 targetDataSources 是 Map，直接 put 或 remove 会触发 ConcurrentModificationException，因为 afterPropertiesSet() 内部会遍历该 Map 构建缓存。

性能影响：频繁修改会导致路由逻辑锁竞争，吞吐量断崖下跌。

必须用线程安全容器替代：ConcurrentHashMap，并在构造时传入，而非用父类默认的 LinkedHashMap
修改 targetDataSources 后，需显式调用 super.setTargetDataSources(...) 和 afterPropertiesSet() 刷新内部缓存
生产环境慎用动态增删——DNS 切换、数据库扩缩容等应走发布流程，而非运行时热插拔

最易被忽略的一点：自定义的 DataSource Bean 如果用了 HikariCP，它的 setJdbcUrl() 等方法不是线程安全的，动态改配置前必须先 close() 原连接池。