垃圾收集 – CDI应用程序和依赖范围可以共谋影响垃圾收集?
我们开始尝试使用CDI实现我们的后端服务.情况是这样的:
使用@Startup的EJB在部署EAR时启动.将ApplicationScoped bean注入到此: @ApplicationScoped public class JobPlatform { private PooledExecutor threadHolder; @Inject @Any private Instance<Worker> workerSource; ... bean还有一个Observer方法,当观察到事件时,从Instance workerSource获取一个工作bean,并将其放在threadPool上,最终运行到完成. 所有工作都很好但是…我们已经开始看到垃圾收集问题. JMAP堆直方图显示,这些工作者中有许多人悬挂在垃圾收集站. 我们认为这是CDI范围的结合. @Dependant(http://docs.jboss.org/cdi/api/1.0-SP1/javax/enterprise/context/Dependent.html)的API页面更清楚地说明了文档中的内容:
所以,遵循: > workerSource bean绑定到JobPlatform,因此具有ApplicationScoped的生命周期 有人使用CDI同意吗?您是否遇到过这样的垃圾收集缺陷,如果是,您能否提出任何解决方法? 工作人员不能被ApplicationScoped,但平台必须是.如果我们要创建一个自定义的WorkerScope(呃哦…)并用它来注释每个工作类,那么这样做足以分离worker和instance source之间的依赖关系? 还有一些建议,在Is it possible to destroy a CDI scope?我会看,但想要一些备份是否范围界定看起来像一个有效的理由. 希望你能帮忙,谢谢.
你的理解是正确的.这是规范的监督,而在CDI 1.1中将会被修正.实例可能会出现内存泄漏,就像您在长时间运行的范围(如SessionScoped或ApplicationScoped)中所描述的那样.您将需要做的是掌握实例的上下文或Bean,并以此方式销毁.
为了正在做什么,为避免内存泄漏,您最好使用BeanManager方法来创建实例(这样您也可以在Bean上具有一个句柄,并且可以销毁它)而不是Instance. (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |