在EJB定时任务中，将CDI Instance传入ManagedExecutorService Runnable是否可行？

我用无状态会话Bean（EJB）仅为借助@Schedule注解让容器定时触发代码。代码通过@Inject @Any标注的Instance<OutboundMessageProcessor>动态注入CDI Bean作为工作器，这些OutboundMessageProcessor实现Runnable接口，会被提交至ManagedExecutorService并行执行：

@Inject @Any 
private Instance<OutboundMessageProcessor> outboundMessageProcessorFactory;

// 创建处理器 
OutboundMessageProcessor outboundMessageProcessor = outboundMessageProcessorFactory.get();

// 提交执行 
Future<?> future = managedExecutorService.submit(outboundMessageProcessor);

但该实现引发内存泄漏：因OutboundMessageProcessor为@Dependent作用域，其生命周期与注入它的EJB一致，而EJB被容器池化长期存活，导致这些实例无法被垃圾回收器回收。

正确的解决方式是使用完Bean后调用outboundMessageProcessorFactory.destroy()销毁，但EJB不能等待Future完成，否则失去异步执行的意义。

我设想将outboundMessageProcessorFactory实例传给OutboundMessageProcessor，让它在Runnable的run()方法结束时自行调用destroy()销毁自身。想问此方案是否合理？是否会因线程作用域问题出现故障？若不可行，还有哪些解决内存泄漏的方案？

你的方案合理性分析 #

把Instance实例传给OutboundMessageProcessor并在run()末尾调用destroy()的方案可行且合理，不会存在线程作用域问题：

• Instance是CDI提供的上下文无关对象，不绑定特定线程，可安全在异步线程中使用；
• 在run()方法结束时调用destroy()，能确保@Dependent作用域的Bean在任务完成后立即销毁，切断与池化EJB的关联，让GC可以正常回收实例，从根源解决内存泄漏。

需要注意的细节：

• 确保OutboundMessageProcessor持有Instance的引用不会造成额外内存占用；
• 将destroy()调用放在finally块中，避免异常情况下的资源泄漏。

其他可选方案 #

如果不想让任务自身处理销毁逻辑，可选择以下替代方案：

1. 改用@RequestScoped作用域：
   手动启动并管理请求上下文，获取Bean后提交任务，随后关闭上下文。代码示例：

   @Inject
   private BeanManager beanManager;
   
   // 定时任务方法内
   RequestContext requestContext = beanManager.createInstance().select(RequestContext.class).get();
   requestContext.activate();
   try {
       OutboundMessageProcessor processor = outboundMessageProcessorFactory.get();
       managedExecutorService.submit(() -> {
           try {
               processor.run();
           } finally {
               outboundMessageProcessorFactory.destroy(processor);
           }
       });
   } finally {
       requestContext.deactivate();
   }
   

2. 实现自定义异步任务作用域：
   创建@AsyncTaskScoped这类专属作用域，让Bean生命周期绑定到异步任务而非EJB，任务结束时自动销毁Bean。但该方案需要自定义CDI作用域，实现成本较高。
3. 工厂模式手动创建实例：
   如果OutboundMessageProcessor无需依赖注入，或依赖可手动解决，直接用new创建实例，脱离CDI容器管理，自然不会有生命周期绑定问题。但此方式会失去CDI依赖注入的便利性。

我最终采用了缓存/池化处理器实例复用的方案：

• 既避免了内存泄漏，还带来小幅性能提升；
• 因需缓存的处理器数量较少，内存开销可忽略不计。

内容的提问来源于stack exchange，提问作者Mario Köhler