garbage-collection - CDI 应用程序和从属范围会合谋影响垃圾收集吗？

Question

我们开始尝试使用 CDI 实现我们的后端服务。场景是这样的:

使用 @Startup 的 EJB 在 EAR 部署时启动。一个 ApplicationScoped bean 被注入(inject)到这个:

@ApplicationScoped
public class JobPlatform {

    private PooledExecutor threadHolder;

    @Inject @Any
    private Instance<Worker> workerSource;
...

该 bean 还有一个 Observer 方法，当观察到一个事件时，它会从 Instance workerSource 中获取一个工作 bean 并将其放在 threadPool 上，最终运行到完成。

一切都很好。然而......我们已经开始看到垃圾收集问题。 JMAP 堆直方图显示有许多这样的 worker 在附近闲逛，没有收集垃圾。

我们认为这要归功于 CDI 范围界定的组合。 @Dependant ( http://docs.jboss.org/cdi/api/1.0-SP1/javax/enterprise/context/Dependent.html ) 的 API 页面更清楚地强化了文档中的内容:

• An instance of a bean with scope @Dependent injected into a field, bean constructor or initializer method is a dependent object of the bean or Java EE component class instance into which it was injected.
• An instance of a bean with scope @Dependent injected into a producer method is a dependent object of the producer method bean instance that is being produced.
• An instance of a bean with scope @Dependent obtained by direct invocation of an Instance is a dependent object of the instance of Instance.

所以，按照这个:

workerSource bean 绑定(bind)到 JobPlatform，因此具有 ApplicationScoped 生命周期

使用该实例检索到的任何工作 bean 都绑定(bind)到它，因此具有 ApplicationScoped 生命周期

因为 ApplicationScoped 上下文的 beanstore(我对术语的了解在这里有点模糊)仍然引用了工作 bean，所以它们没有被销毁/垃圾收集

使用 CDI 的人是否同意这一点？您是否经历过这种缺乏垃圾收集的情况，如果是的话，您能提出任何解决方法吗？

worker 不能是 ApplicationScoped，但平台必须是。如果我们要创建一个自定义的 WorkerScope(呃哦……)并用它来注释每个工作类，这是否足以分离工作人员和实例源之间的依赖关系？

Is it possible to destroy a CDI scope? 也有一些建议我会看一下，但想要一些关于范围界定是否是一个正当理由的备份。

希望你能帮忙，谢谢。

Answer 1

你的理解是正确的。这是规范中的疏忽，将在 CDI 1.1 中修复。 Instance 可能会发生内存泄漏，就像您在长时间运行的范围(例如 SessionScoped 或 ApplicationScoped )中使用时所描述的那样。您需要做的是获取实例的 Contextual 或 Bean 并以这种方式销毁它。

对于你正在做的事情，为了避免内存泄漏，你最好使用 BeanManager 方法来创建实例(这样你也将在 Bean 上有一个句柄并可以销毁它)而不是 Instance 。