JSF：Mojarra 与 OmniFaces @ViewScoped：@PreDestroy 调用但 bean 不能被垃圾收集

Question

这个问题是特定于OmniFaces @ViewScoped bean 的（但是更广泛地讨论有关使用 JSF @ViewScoped 处理内存泄漏和资源的问题很有趣）。它基于 GitHub 上提供的这个 NetBeans8.1 测试 Web 应用程序的结果：

Investigation of undesirable holding of references to various forms of JSF @ViewScoped beans by navigation type

https://github.com/webelcomau/JSFviewScopedNav

该测试 Web 应用程序具有包含完整说明的全面自述文件，以及比较过时的 JSF2.0 样式 @ManagedBean @ViewScoped、JSF2.2 样式 CDI 友好 @Named @ViewScoped 和 OmniFaces @Named @ViewScoped 的带注释的测试网页豆子。

使用 JVisualVM 进行诊断的结果在一个可下载的电子表格中进行了总结（另请参见下面的屏幕截图），并表明虽然 OmniFaces-2.5.1 @ViewScoped bean 在离开视图时在基于 GET 的导航案例下调用 @PreDestroy 方法（提供释放大部分资源的机会），它似乎不允许对实际 bean 进行垃圾收集（至少在当前上下文参数设置下不允许）。

在 web.xml 中应用设置为使用：

com.sun.faces.numberOfViewsInSession 4

com.sun.faces.numberOfLogicalViews 4

默认情况下，此 OmniFaces 特定参数被注释掉：

org.omnifaces.VIEW_SCOPE_MANAGER_MAX_ACTIVE_VIEW_SCOPES

javax.faces.STATE_SAVING_METHOD 默认为“服务器”。

---

主要问题是：

Q1：这些 OmniFaces @ViewScoped bean 在设计上不能被“实时”垃圾收集（意思是通过使用 Profiler 的垃圾收集g 操作进行挑衅，而不是等到会话结束），这是否正确？

Q2：如果是这样，如何（应该）在离开页面时（尤其是在 GET 导航下）最好地强制释放它们？

Q3：如果不是这样（如果我的结果由于某些其他设置不正确）为什么我没有看到它们被引发的垃圾收集，我可以做些什么来确保它们确实被自动释放？

由于测试网络应用程序是可下载的、有据可查的并且希望不言自明，我不会在这里提供代码，而只是到目前为止的比较结果，以及测试网络应用程序页面的屏幕截图：

Answer 1

这个问题的原因似乎是由于 JVisualVM 连接到 Glassfish/Payara 时的奇怪行为。

test case used for this question 仍然非常有用，但是原始帖子（和图像）中关于垃圾收集的结论是基于 JVisualVM，我发现它们是无效的。

改用 NetBeans Profiler！

我现在得到了 OmniFaces ViewScoped 与测试应用程序在 NetBeans Profiler 中强制 GC 的完全一致的结果（每个打开的选项卡剩下 1 个omnifaces view scoped bean）。

当使用附加到 GlassFish/Payara 的 JVisualVM 时，我得到的引用仍然被 ContainerBase$ContainerBackgroundProcessor 中类型为 com.sun.web.server.WebContainerListener 的字段 sessionListeners 持有（即使在调用 @PreDestroy 之后），它们不会被 GC。

该图显示了附加到 Payara 的 JVisualVM 的屏幕截图，其中仅打开了 1 个选项卡，但仍持有 9 个 OmniViewBean 实例，无论多久强制执行一次 GC。

---

在 NetBeans IDE 8.2 Profiler 中使用 Mojarra-2.3.0 与 OmniFaces-2.6.6 更新了结果表

更新test app序列：

---

---

---

---