JSF:Mojarra与OmniFaces @ViewScoped:@PreDestroy被调用，但是无法对bean进行垃圾收集

解决方案此问题的原因似乎是由于JVisualVM附加到Glassfish/Payara时的奇怪行为引起的.用于该问题的测试用例仍然非常有用，但是有关垃圾回收的结论原始帖子(和图像)是基于JVisualVM的，此后我发现它们无效. 请改用NetBeans Profiler！现在，通过从NetBeans Profiler强制使用GC的测试应用程序，OmniFaces ViewScoped可以获得完全一致的结果(每个打开的选项卡上剩下1个omnifaces视图作用域的bean).当使用附加到GlassFish/Payara的JVisualVM时，即使在ContainerBase$ContainerBackgroundProcessor中类型为com.sun.web.server.WebContainerListener的字段sessionListeners中，引用仍保持引用(即使在@PreDestroy调用之后)，并且它们不会GC.图像显示了连接到Payara的JVisualVM的屏幕快照，无论打开GC的频率如何，它仅打开1个选项卡，但仍保留9个OmniViewBean实例. 在NetBeans IDE 8.2 Profiler中使用Mojarra-2.3.0和OmniFaces-2.6.6更新了结果表 更新了测试应用序列:This question is specific to the OmniFaces @ViewScoped bean (however of interest to wider discussion about memory leakage and resource disposal with JSF @ViewScoped). It is based on the results of this NetBeans8.1 test web app available on GitHub:Investigation of undesirable holding of references to various forms of JSF @ViewScoped beans by navigation typehttps://github.com/webelcomau/JSFviewScopedNavThat test web app has a comprehensive README with complete instructions, as well as annotated test web pages comparing obsolete JSF2.0-style @ManagedBean @ViewScoped, JSF2.2-style CDI-friendly @Named @ViewScoped, and OmniFaces @Named @ViewScoped beans.The results using JVisualVM for diagnosis are summarised in a downloadable spreadsheet (see also screenshot below), and indicate that while the OmniFaces-2.5.1 @ViewScoped bean invokes @PreDestroy methods under GET-based navigation cases when leaving a view (giving the opportunity to release most resources), it does not seem to permit garbage collection of the actual bean (at least not with the current context parameter settings).In web.xml the application is set to use:com.sun.faces.numberOfViewsInSession 4com.sun.faces.numberOfLogicalViews 4By default this OmniFaces-specific parameter is commented out:org.omnifaces.VIEW_SCOPE_MANAGER_MAX_ACTIVE_VIEW_SCOPESThe javax.faces.STATE_SAVING_METHOD defaults to 'server'.The main question is:Q1: Is it correct that these OmniFaces @ViewScoped beans can't by design be garbage collected "live" (meaning through say provocation using a Profiler's garbage collectiong action, not waiting until a session is over) ?Q2: If this is so, how can (should) one best force release of them on navigating away from pages (especially under GET navigations) ?Q3: If not so (if my results are incorrect because of some other setting) why aren't I witnessing provoked garbage collection of them, and what can I do to ensure they are indeed automatically released ?Since the test web app is downloadable, well documented and hopefully self-explanatory, I won't give code here, but simply the comparitive results so far, as well as screenshots of the test web app pages in action: 解决方案 The cause of this problem seems to be due to strange behaviour JVisualVM when attached to Glassfish/Payara.The test case used for this question is still extremely useful, however the conclusions concerning Garbage Collection in the original post (and images) were based on JVisualVM, and I have since found they are not valid.Use the NetBeans Profiler instead !I am now getting completely consistent results for OmniFaces ViewScoped with the test app on forcing GC from within the NetBeans Profiler (with 1 omnifaces view scoped bean left per open tab).When using JVisualVM attached to GlassFish/Payara I am getting references still held (even after @PreDestroy called) by field sessionListeners of type com.sun.web.server.WebContainerListener within ContainerBase$ContainerBackgroundProcessor, and they won't GC.The image shows a screenshot of JVisualVM attached to Payara with only 1 tab open but still 9 OmniViewBean instances held, no matter how often GC is forced.Updated results table using Mojarra-2.3.0 vs OmniFaces-2.6.6 in NetBeans IDE 8.2 ProfilerUpdated test app sequence: 这篇关于JSF:Mojarra与OmniFaces @ViewScoped:@PreDestroy被调用，但是无法对bean进行垃圾收集的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！ 上岸，阿里云！