核心问题是旧数据源未真正关闭导致内存泄漏；需配置defaultdatasourcedestroyer bean、启用grace-destroy、清理threadlocal上下文、激活连接池泄漏防护，并通过actuator和jvm工具验证销毁效果。
核心问题不是切换快，而是旧数据源对象在被替换后没有真正关闭——连接池没停、线程上下文没清、资源引用还挂着。物理堆空间持续上涨甚至oom，往往就卡在这“关不干净”三个字上。
确保 DefaultDataSourceDestroyer 正确注册并启用优雅销毁
dynamic-datasource 默认不启动销毁逻辑，必须显式配置：
- 在 Spring 配置类中声明 DefaultDataSourceDestroyer Bean，它是唯一支持 Hikari/Druid/DBCP2 连接池主动检测与关闭的实现
- 开启优雅销毁开关：spring.datasource.dynamic.grace-destroy=true；否则移除数据源时会跳过等待活跃连接归还的流程，直接丢弃，导致连接悬空
- 避免自定义销毁器未实现 DataSourceActiveDetector 接口——否则无法判断连接是否真为空闲，可能误关或漏关
强制清理 ThreadLocal 中残留的数据源上下文
DynamicDataSourceContextHolder 使用 ThreadLocal
- 所有 Filter、Interceptor、AOP 切面中调用 push() 的地方，必须包裹在 try-finally 块内，并在 finally 中执行 DynamicDataSourceContextHolder.clear()
- 禁止在 CompletableFuture、@Async 方法等异步线程中直接复用主线程上下文；如需传递，须手动拷贝 key 并确保子线程结束前 clear
- 用 MAT 分析堆转储，重点检查 LOOKUP_KEY_HOLDER 的引用链，确认是否有框架层（如事务代理）意外持有未释放引用
激活连接池自身的泄漏防护与生命周期控制
仅靠 dynamic-datasource 的销毁器不够，底层连接池必须同步参与防控：
- HikariCP：设置 leak-detection-threshold=60000（单位毫秒），触发时打印完整堆栈，精准定位哪段代码忘了 close() 或 return connection
- Druid：启用 removeAbandonedOnMaintenance=true 和 removeAbandonedTimeoutMillis=60000，让连接池定期回收疑似泄漏连接
- 统一配置 max-lifetime 小于数据库的 wait_timeout，防止连接因服务端主动断连而滞留在池中变成“僵尸连接”
验证销毁是否真实生效，不止看日志
不能只信控制台输出的 “destroyed”，要实测连接数是否归零：
- 通过 /actuator/datasources（需引入 spring-boot-starter-actuator）实时查看各数据源当前活跃连接数、总连接数
- 执行数据源移除操作后，用 jstat -gc
观察老年代使用率是否回落，配合 jmap -histo 检查是否存在大量未释放的 Connection/PoolEntry 实例 - 对关键节点加日志：在 DefaultDataSourceDestroyer#asyncDestroy 执行前后打点，确认方法确实被调用且无异常中断
