JSF: Mojarra vs. OmniFaces @ViewScoped: @PreDestroy aufgerufen aber Bean kann nicht Müll gesammelt werden

Diese Frage ist spezifisch für die OmniFaces @ViewScoped bean (jedoch von Interesse für eine breitere Diskussion über Speicherverlust und Ressourcenentsorgung mit JSF @ViewScoped).JSF: Mojarra vs. OmniFaces @ViewScoped: @PreDestroy aufgerufen aber Bean kann nicht Müll gesammelt werden

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

https://github.com/webelcomau/JSFviewScopedNav

Dieser Test Web-App eine umfassende README mit vollständigen Anweisungen hat, sowie kommentierte Test web: Es ist auf GitHub auf den Ergebnissen dieser NetBeans8.1 Test Web-App basiert Seiten vergleichen veraltete JSF2.0-Stil @ManagedBean @ViewScoped, JSF2.2-Stil CDI-freundlich @Named @ViewScoped und OmniFaces @Named @ViewScoped Bohnen.

Die Ergebnisse, die JVisualVM zur Diagnose verwenden, sind in einer herunterladbaren Tabelle zusammengefasst (siehe Abbildung unten) und zeigen an, dass die Bean OmniFaces-2.5.1 @ViewScoped @PreDestroy-Methoden unter GET-basierten Navigationsfällen beim Verlassen einer Ansicht aufruft (die Möglichkeit zu geben, die meisten Ressourcen freizugeben), scheint es keine Speicherbereinigung der tatsächlichen Bean zu erlauben (zumindest nicht mit den aktuellen Kontextparametereinstellungen).

In web.xml wird die Anwendung verwenden gesetzt:

com.sun.faces.numberOfViewsInSession 4 

com.sun.faces.numberOfLogicalViews 4

standardmäßig diese OmniFaces spezifische Parameter wird auf Kommentar:

org.omnifaces.VIEW_SCOPE_MANAGER_MAX_ACTIVE_VIEW_SCOPES

Die javax.faces.STATE_SAVING_METHOD standardmäßig auf ‚Server ".

Die wichtigste Frage ist:

Q1: Ist es richtig, dass diese OmniFaces @ViewScoped Bohnen nicht durch Design Müll „live“ gesammelt werden (was bedeutet, sagen durch Provokation eines Profiler Müll collectiong Aktion verwenden, nicht warten bis eine Sitzung zu Ende ist)?

Q2: Wenn das so ist, wie kann (sollte) man am besten die Freigabe von ihnen beim Navigieren weg von Seiten (vor allem unter GET-Navigationen)?

Q3: Wenn nicht (wenn meine Ergebnisse aufgrund einer anderen Einstellung nicht korrekt sind), warum erlebe ich keine provozierte Garbage Collection von ihnen, und was kann ich tun, um sicherzustellen, dass sie tatsächlich automatisch veröffentlicht werden?

Da die Test-Web-App herunterladbar, gut dokumentiert und hoffentlich selbsterklärend ist, werde ich hier keinen Code geben, sondern einfach die bisherigen Vergleichsergebnisse sowie Screenshots der Test-App-Seiten in Aktion:

Quelle

2016-11-13 Webel IT Australia - upvoter

teilweise verwandte (nur, Duplikate NOT): Meine eigene allgemeinere Frage (nicht spezifisch für OmniFaces) [Wie erkennen und entfernen (während einer Sitzung) ungenutzt '@ViewScoped 'Bohnen, die nicht Müll gesammelt werden können] (http://stackoverflow.com/questions/30410601/how-detect-and-remove-during-a-session-unused-viewscoped-beans-that-cant-be). Und [Speicherimplikationen von OmniFaces ViewScoped Bean?] (Http://stackoverflow.com/questions/21236730/memory-implications-of-omnifaces-viewscoped-bean), aber scheint nicht zwischen '@ PreDestroy' und Garbage Collection zu unterscheiden . –

Die Ursache für dieses Problem scheint auf seltsame Verhalten jvisualvm wenn auf Glassfish/Payara angebracht zu sein.

Die test case used for this question ist immer noch sehr nützlich, aber die Schlussfolgerungen in Bezug auf Garbage Collection in der ursprünglichen Post (und Bilder) wurden auf JVisualVM basiert, und ich habe seitdem festgestellt, dass sie nicht gültig sind.

Verwenden Sie stattdessen den NetBeans Profiler!

Ich bekomme jetzt völlig konsistente Ergebnisse für OmniFaces ViewScoped mit der Test-App zum Erzwingen GC aus dem NetBeans Profiler (mit 1 omnifaces view scoped Bean links geöffnet Registerkarte).

Wenn jvisualvm zu Glassfish/Payara angebracht mit bin ich Referenzen noch gehalten (auch nach @PreDestroy genannt) durch das Feld immer sessionListeners vom Typ com.sun.web.server.WebContainerListener innerhalb ContainerBase$ContainerBackgroundProcessor, und sie werden nicht GC.

Das Bild zeigt einen Screenshot von JVisualVM, der an Payara angehängt ist, wobei nur 1 Tab geöffnet ist, aber immer noch 9 OmniViewBean Instanzen vorhanden sind, egal wie oft GC gezwungen wird.