flyway 使用 datasource 时不会自动关闭底层 jdbc 连接，导致连接泄漏；正确做法是改用 url/username/password 构造方式，或显式释放 datasource 资源。本文提供兼容 tomcat 环境的适配方案及推荐实践。
在基于 JSF + MySQL 的传统 Java EE 应用中（如部署于 Tomcat），若通过 DataSource 实例初始化 Flyway（如 config.dataSource(ds)），Flyway 仅借用该数据源获取连接，但不会负责关闭或归还连接——尤其当 DataSource 来自容器（如 JNDI）时，其连接生命周期由容器管理，Flyway 无法主动释放。这会导致迁移完成后连接仍处于活跃状态，长期运行可能引发连接池耗尽或数据库会话堆积。
根本解决思路是：避免将容器管理的 DataSource 直接传入 Flyway，转而使用显式的 JDBC 连接参数（URL、username、password）初始化 Flyway。这样 Flyway 内部会自行创建并完全管理连接（包括打开与关闭），确保迁移结束后资源被及时释放。
以下为适配 Tomcat 环境的完整实践方案（以 tomcat-dbcp 或 tomcat-jdbc 为例）：
import org.apache.tomcat.dbcp.dbcp2.BasicDataSource;
private Flyway configureFlyway() {
FluentConfiguration config = new FluentConfiguration();
// 安全提取 JDBC 参数：仅当 DataSource 是 Tomcat DBCP 实现时才尝试解析
if (getDs() instanceof BasicDataSource dsImpl) {
String url = dsImpl.getUrl();
String username = dsImpl.getUsername();
String password = dsImpl.getPassword();
// ✅ 关键：使用三参数方式，Flyway 将自主管理连接生命周期
config.dataSource(url, username, password);
} else {
// 兜底：若非预期类型，可抛出配置异常或记录警告
throw new IllegalStateException("Unsupported DataSource type: " + getDs().getClass().getName());
}
return Flyway.configure()
.dataSource(url, username, password)
.baselineOnMigrate(true)
.cleanDisabled(true)
.outOfOrder(true)
.validateMigrationNaming(true)
.validateOnMigrate(false)
.locations("classpath:alter-scripts")
.loggers("log4j2")
.load(); // 注意：.load() 返回 Flyway 实例，替代 new Flyway(config)
}⚠️ 注意事项：
- 依赖对齐：确保项目中引入了与运行环境匹配的 DataSource 实现类（如 Tomcat 10+ 推荐 org.apache.tomcat:tomcat-jdbc，旧版可用 tomcat-dbcp），并在 pom.xml 中声明 provided 作用域，避免冲突；
- 敏感信息防护：生产环境不建议硬编码数据库凭证，应结合 JNDI 属性或外部配置中心动态注入 URL/username/password；
- JNDI 数据源复用限制：若必须复用容器 DataSource（例如因事务管理需求），则需在 makeMigration() 后手动调用 flyway.close()（Flyway ≥ 8.0 支持），或确保应用服务器在部署结束时能正常回收资源；
- Flyway 版本一致性：示例基于 Flyway 9.x，.load() 是推荐的构建方式；旧版本（
总结：Flyway 的连接生命周期语义取决于初始化方式——传入 DataSource 意味着“委托管理”，而传入 JDBC 三元组则意味着“自主管理”。在无容器事务强依赖的场景下，优先选用后者，既解耦又可控，是解决连接泄漏最直接、最可靠的方式。
