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 为例）：
酷纬企业网站管理系统Kuwebs是酷纬信息开发的为企业网站提供解决方案而开发的营销型网站系统。在线留言模块、常见问题模块、友情链接模块。前台采用DIV+CSS，遵循SEO标准。 1.支持中文、英文两种版本，后台可以在不同的环境下编辑中英文。 3.程序和界面分离，提供通用的PHP标准语法字段供前台调用，可以为不同的页面设置不同的风格。 5.支持google地图生成、自定义标题、自定义关键词、自定义描
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 三元组则意味着“自主管理”。在无容器事务强依赖的场景下，优先选用后者，既解耦又可控，是解决连接泄漏最直接、最可靠的方式。
