1. 问题现象回顾1.1 应用场景这是一个典型的Java企业级应用场景基于Jakarta EE平台原Java EE和WildFly 37应用服务器构建的数据统计系统。系统核心功能是收集运行时数据并定期持久化到数据库。为了简化架构开发者特意避开了Hibernate/JPA这类ORM框架直接使用JDBC DataSource进行数据库操作。统计逻辑被封装为Singleton EJB企业级Java Bean这种设计确保了统计服务在整个应用生命周期中保持单例状态。通过Schedule定时任务每分钟执行一次内存数据聚合和数据库写入操作这种批处理方式有效减少了数据库写入频率。1.2 异常日志核心信息系统在正常运行时表现稳定但在应用关闭或重新部署时控制台会出现如下错误日志ERROR [DBStatistic] IJ000470: You are trying to use a connection factory that has been shut down这个错误发生在PreDestroy生命周期方法中当系统尝试将最后一批内存统计数据写入数据库时。值得注意的是这种异常不是每次都会出现而是不定期发生这使得问题更加难以排查。2. 核心结论先给答案经过深入分析问题的本质原因是WildFly在应用关闭时数据源(DataSource)的关闭顺序早于EJB的销毁顺序。当PreDestroy方法尝试使用已经被关闭的数据源时自然就会抛出connection factory that has been shut down异常。重要提示这不是代码逻辑错误而是生命周期管理问题。即使代码完全正确在特定条件下仍可能出现此问题。3. 为什么会发生这个问题3.1 WildFly的关闭顺序关键WildFly应用服务器在关闭时遵循特定的资源释放顺序首先关闭数据源和连接池然后销毁EJB实例并调用PreDestroy方法最后释放其他资源这个顺序是由服务器内部设计决定的开发者通常无法直接修改。这就导致了一个时间窗口当PreDestroy方法执行时它依赖的数据源可能已经被关闭了。3.2 PreDestroy的真实语义很多开发者误以为PreDestroy方法是在应用即将关闭但所有资源仍可用时被调用。实际上Jakarta EE规范并没有保证这一点。PreDestroy只表示这个bean即将被销毁并不保证其他资源的状态。3.3 我没用事务是不是问题的一部分确实如此。在这个案例中开发者为了简化设计没有使用事务管理。如果使用了容器管理事务(CMT)WildFly会在事务上下文中保持数据源可用性更长的时间可能降低此问题发生的概率但不是完全避免。4. 为什么定义EJB依赖关系也无法解决有些开发者尝试通过DependsOn注解定义EJB之间的依赖关系希望控制销毁顺序。但这种方法有几个根本缺陷它只能控制EBean之间的销毁顺序无法影响数据源等基础设施组件的生命周期WildFly内部的服务关闭顺序优先级高于应用定义的依赖关系即使所有EBean按预期顺序销毁数据源仍可能提前关闭5. 正确的设计思路重要5.1 不推荐的做法 ❌在PreDestroy中执行关键数据持久化操作依赖未明确的生命周期顺序假设尝试通过配置欺骗服务器改变关闭顺序5.2 推荐的做法 ✅将关键数据的持久化与生命周期方法解耦采用定期刷新(flush)机制而非依赖关闭时的最后写入考虑最终一致性而非强一致性对于必须确保持久化的数据使用更可靠的消息队列或事务日志6. 可落地的解决方案工程实践6.1 方案一最推荐提前Flush而不是Shutdown写库思路将确保数据不丢失的责任从关闭阶段转移到运行阶段。具体做法缩短定时任务的执行间隔如从1分钟改为30秒增加手动flush方法在关键操作后主动调用使用内存队列缓冲数据定时批量写入示例代码Singleton public class StatisticsService { private final BlockingQueueStatData queue new LinkedBlockingQueue(); private final ScheduledExecutorService scheduler Executors.newSingleThreadScheduledExecutor(); PostConstruct public void init() { scheduler.scheduleAtFixedRate(this::flushData, 30, 30, TimeUnit.SECONDS); } public void recordData(StatData data) { queue.offer(data); if(queue.size() 1000) { // 达到阈值立即flush flushData(); } } private void flushData() { ListStatData batch new ArrayList(); queue.drainTo(batch); if(!batch.isEmpty()) { // 使用try-with-resources确保JDBC资源正确释放 try (Connection conn dataSource.getConnection(); PreparedStatement stmt conn.prepareStatement(INSERT_SQL)) { for(StatData data : batch) { stmt.setLong(1, data.getValue1()); stmt.setString(2, data.getValue2()); stmt.addBatch(); } stmt.executeBatch(); } catch(SQLException e) { logger.error(Flush failed, will retry next time, e); // 将失败的数据重新放回队列 queue.addAll(batch); } } } }6.2 方案二使用显式事务 容器管理事务CMT虽然不能完全解决问题但使用事务可以延长数据源可用时间窗口TransactionAttribute(TransactionAttributeType.REQUIRES_NEW) public void flushData() { // 事务方法中的持久化逻辑 }6.3 方案三监听WildFly服务级Shutdown高级通过实现Service接口监听服务器关闭事件Service public class ShutdownListener implements org.jboss.msc.service.ServiceVoid { Inject private StatisticsService stats; Override public void start(StartContext context) { // 服务启动逻辑 } Override public void stop(StopContext context) { context.asynchronous(); // 声明异步停止 try { stats.finalFlush(); // 执行最终flush } finally { context.complete(); // 通知停止完成 } } }6.4 方案四推荐用于统计类数据异步 最终一致性对于非关键统计数据可以采用最终一致性方案使用内存缓存如Caffeine定期异步写入应用关闭时丢失最后少量数据可接受Singleton public class StatsCache { private final CacheString, StatData cache Caffeine.newBuilder() .maximumSize(10_000) .expireAfterWrite(1, TimeUnit.MINUTES) .scheduler(Scheduler.systemScheduler()) .writer(new StatsWriter(dataSource)) .build(); }7. 关键经验总结7.1 本质原因一句话总结数据源先于EBean被关闭的生命周期顺序问题导致PreDestroy中无法可靠使用数据源。7.2 Jakarta EE生命周期红线永远不要假设PreDestroy方法中资源仍然可用关键操作应该在正常运行时完成而非关闭时补救理解并尊重应用服务器的内部资源管理顺序7.3 最佳实践 Checklist[ ] 避免在生命周期方法中执行关键持久化操作[ ] 采用更频繁的flush机制替代最后的全有或全无写入[ ] 对于必须确保的数据考虑使用事务日志或消息队列[ ] 适当放宽一致性要求特别是对于统计类数据[ ] 在开发环境中模拟各种关闭场景进行测试8. 个人实战建议在实际项目中处理类似问题时我发现以下几个技巧特别有用监控数据延迟实现一个简单的指标来监控内存中待持久化数据的量和延迟时间。这能帮助你合理设置flush间隔。双重写入策略对于特别重要的数据可以同时写入本地文件和应用数据库。即使数据库连接不可用仍可以从文件恢复。优雅降级当检测到应用正在关闭时可以自动切换到更简单的持久化机制比如将数据序列化到临时文件。压力测试在预发布环境中模拟各种非正常关闭场景kill -9、断网、数据库故障等验证系统的健壮性。指标可视化使用PrometheusGrafana等工具可视化flush延迟、队列大小等关键指标便于及时发现潜在问题。最后要记住分布式系统中的数据一致性本身就是复杂的问题。根据你的业务需求选择适当的一致性级别避免为了理论上的完美而过度设计解决方案。