invokedynamic是JVM指令，专用于运行时动态绑定方法调用目标（MethodHandle），支持动态语言和Lambda表达式，不参与数据源路由或数据库连接选择。
Java 多数据源切换中，invokedynamic 并不参与数据源路由或连接选择，它无法用于动态绑定底层数据库连接。
invokedynamic 的真实作用范围
invokedynamic 是 JVM 5.2 引入的字节码指令，专为支持动态语言（如 Groovy、JRuby）和 Lambda 表达式设计。它的核心职责是：在运行时**动态解析并绑定一个方法调用目标（MethodHandle）**，比如把 list.forEach(x -> ...) 编译成一次性的调用点，后续直接跳转到具体实现。
它操作的是Java 方法调用链路，不是数据访问层，更不接触 DataSource、Connection 或 JDBC 驱动。JDBC 连接的获取始终走的是标准接口：
— DataSource.getConnection()
— DriverManager.getConnection()
这些调用由 Spring 的 DataSourceUtils 或连接池（HikariCP/Druid）管理，与 invokedynamic 完全无关。
真正起作用的是 AbstractRoutingDataSource + ThreadLocal
多数据源切换依赖的是 Spring 提供的路由机制，关键组件包括：
- 继承
AbstractRoutingDataSource，重写determineCurrentLookupKey() - 用
ThreadLocal<String>（或栈式Deque<String>）保存当前线程要使用的数据源标识（如"master"、"tenant_003"） - 在 AOP 切面、注解拦截或业务入口处
push("slave")，执行完后poll()清理 - Spring 在获取连接时，自动调用路由类的
determineCurrentLookupKey()，再从targetDataSources映射中取出对应的真实DataSource
为什么不能用 invokedynamic 替代？
因为两者解决的问题域完全不同：
-
invokedynamic解决的是“调用哪个方法”的符号绑定问题，发生在字节码执行期，粒度是方法句柄 - 数据源切换解决的是“用哪个数据库实例”的运行时决策问题，发生在应用逻辑层，依赖上下文（租户ID、读写意图、事务状态）
- 没有 JVM 规范或 Spring 框架约定让
invokedynamic去干预getConnection()的实际目标 DataSource 实例
如果你看到相关说法，大概率是混淆了概念
某些文章可能误将“动态”一词泛化使用——比如把“运行时决定用哪个库”叫作“动态绑定”，但技术上这属于策略模式 + 上下文路由，和 JVM 的 invokedynamic 指令毫无关系。Lambda 表达式背后确实用了 invokedynamic，但它只负责把 x -> userMapper.selectById(x) 绑定到某个函数式接口实现，不会、也不能改变这个 mapper 最终连的是 master 还是 slave 数据源。
