相关疑难解决方法(0)

编辑:这个问题提出的问题在codebulb.ch的这篇文章中得到了很好的解释和证实,包括JSF @ViewScoped,CDI @ViewSCoped和Omnifaces 之间的一些比较@ViewScoped,以及JSF @ViewScoped"设计漏洞" 的明确声明:5月24日, 2015 Java EE 7 Bean范围比较了2的第2部分

编辑:2017-12-05用于这个问题的测试用例仍然非常有用,但原始帖子(和图像)中关于垃圾收集的结论是基于JVisualVM,我发现它们无效.请改用NetBeans Profiler!现在我正在从NetBeans配置,而不是JVisualVM连接到GlassFish /似鲭水狼牙鱼,在这里我感到场得到引用(甚至@PreDestroy称为后)仍持有中强制GC的OmniFaces ViewScoped完全一致的结果与试验应用sessionListeners型的com.sun.web.server.WebContainerListener内ContainerBase$ContainerBackgroundProcessor,他们不会GC.

众所周知,在JSF2.2中,对于使用@ViewScoped bean的页面,使用以下任何一种技术导航(或重新加载)将导致@ViewScoped bean在会话中"悬空"的实例它不会被垃圾收集,导致堆内存不断增长(只要GET引发):

• 使用h:链接获取新页面.

• 使用h:outputLink(或HTML A标记)获取新页面.

• 使用RELOAD命令或按钮在浏览器中重新加载页面.

• 使用键盘重新加载页面在浏览器URL上输入ENTER(也是GET).

相比之下,通过使用一个h:commandButton来传递JSF导航系统会导致@ViewScoped bean的发布,从而可以对其进行垃圾回收.

这是由(由BalusC)在JSF 2.1上解释的.ViewScopedBean @PreDestroy方法未被我的小型NetBeans示例项目/sf/answers/2128728101/在JSF2.2和Mojarra 2.2.9中调用和演示,其中项目说明了各种导航案例,可在此处下载.(编辑:2015-05-28:完整代码现在也可以在下面找到.)

[编辑:2016-11-13现在还有一个改进的测试网络应用程序,包含完整的说明,@ViewScoped并在GitHub上与OmniFaces 和结果表进行比较:https://github.com/webelcomau/JSFviewScopedNav]

我在这里重复一个index.html的图像,它总结了导航案例和堆内存的结果:

问:如何检测由GET导航引起的这种"悬挂/悬挂"@ViewScoped bean并将其删除,或以其他方式呈现垃圾收集？

请注意,我不会在会话结束时询问如何清理它们,我已经看到了各种解决方案,我正在寻找在会话期间清理它们的方法,以便在会话期间堆内存不会过度增长由于无意中的GET导航.