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

该测试网络应用程序有一个全面的自述文件和完整的说明，以及比较过时的 JSF2.0 风格的带注释的测试网页 @ManagedBean @ViewScoped，JSF2.2 风格的 CDI 友好 @Named @ViewScoped 和 OmniFaces @Named @ViewScoped bean。

使用 JVisualVM 进行诊断的结果汇总在可下载的电子表格中(另请参见下面的屏幕截图)，并表明当 OmniFaces-2.5.1 @ViewScoped bean 在基于 GET 的情况下调用 @PreDestroy 方法时离开 View 时的导航情况(提供释放大部分资源的机会)，它似乎不允许对实际 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 默认为“服务器”。

---

主要问题是:

问题 1:这些 OmniFaces @ViewScoped bean 不能通过设计被“实时”垃圾收集(意味着通过使用 Profiler 的垃圾收集操作的挑衅，而不是等到 session 结束)结束)？

Q2:如果是这样，如何(应该)在离开页面(尤其是在 GET 导航下)时强制释放它们？

问题 3:如果不是这样(如果我的结果由于某些其他设置不正确)为什么我没有看到它们被激发的垃圾收集，我该怎么做才能确保它们确实自动释放？

由于测试网络应用程序是可下载的、有据可查的并且希望是不言自明的，所以我不会在这里给出代码，而是简单地给出到目前为止的比较结果，以及正在运行的测试网络应用程序页面的屏幕截图:

Answer 1

这个问题的原因似乎是 JVisualVM 在附加到 Glassfish/Payara 时的奇怪行为。

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

改用 NetBeans Profiler!

我现在在 OmniFaces ViewScoped 上获得了与测试应用程序完全一致的结果，该测试应用程序从 NetBeans Profiler 中强制执行 GC(每个打开的选项卡留下 1 个 omnifaces View 作用域 bean)。

当使用附加到 GlassFish/Payara 的 JVisualVM 时，我得到的引用仍然被字段保留(即使在调用@PreDestroy 之后)sessionListeners类型 com.sun.web.server.WebContainerListener在 ContainerBase$ContainerBackgroundProcessor 内, 他们不会 GC。

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

---

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

已更新 test app顺序:

---

---

---

---