Wie werden nicht verwendete @ViewScoped-Beans erkannt und (während einer Sitzung) entfernt, die nicht durch Müll gesammelt werden können?
EDIT: Das durch diese Frage aufgeworfene Problem wird in diesem Artikel von codebulb.ch sehr gut erklärt und bestätigt, einschließlich einiger Vergleiche zwischen JSF@ViewScoped, CDI@ViewSCoped und die Omnifaces@ViewScoped und eine klare Aussage, dass JSF@ViewScoped ist von Natur aus undicht: 24. Mai 2015 Java EE 7 Bean-Bereiche verglichen Teil 2 von 2
EDIT: 2017-12-05 Der für diese Frage verwendete Testfall ist immer noch äußerst nützlich, die Schlussfolgerungen bezüglich der Garbage Collection im ursprünglichen Beitrag (und den Bildern) basierten jedoch auf JVisualVM, und ich habe seitdem festgestellt, dass sie nicht gültig sind.Verwenden Sie stattdessen den NetBeans Profiler! Ich erhalte jetzt vollständig konsistente Ergebnisse für OmniFaces ViewScoped mit der Test-App zum Erzwingen von GC über den NetBeans Profiler anstelle von JVisualVM, der an GlassFish / Payara angehängt ist. Dort werden weiterhin Referenzen (auch nach Aufruf von @PreDestroy) von field @ gespeichersessionListeners vom Typcom.sun.web.server.WebContainerListener innerhalbContainerBase$ContainerBackgroundProcessor, und sie werden nicht GC.
Es ist bekannt, dass in JSF2.2 bei einer Seite, die eine @ViewScoped-Bean verwendet, das Navigieren von ihr weg (oder das erneute Laden) unter Verwendung einer der folgenden Techniken dazu führt, dass die @ViewScoped-Bean in der Sitzung "baumelt" damit kein Müll gesammelt wird, was zu einem endlos wachsenden Heap-Speicher führt (solange dies durch GETs provoziert wird):
Verwenden eines h: Link zum Abrufen einer neuen Seite.
Verwenden Sie einen h: outputLink (oder ein HTML A-Tag), um eine neue Seite abzurufen.
Laden Sie die Seite im Browser mit einem RELOAD-Befehl oder einer RELOAD-Schaltfläche erneut.
Laden Sie die Seite mit der EINGABETASTE auf der Browser-URL neu (auch ein GET).
Wenn Sie dagegen das JSF-Navigationssystem mit dem Befehl h: commandButton durchlaufen, wird die @ViewScoped-Bean so freigegeben, dass sie müllsammelbar ist.
Dies wird erklärt (von BalusC) beiJSF 2.1 ViewScopedBean @PreDestroy-Methode heißt nicht und für JSF2.2 und Mojarra 2.2.9 von meinem kleinen NetBeans-Beispielprojekt unter @ demonstriehttps: //stackoverflow.com/a/30410401/67945, welches Projekt zeigt die verschiedenen Navigationsfälle und ist hier zum Download verfügbar. (EDIT: 2015-05-28: Der vollständige Code ist jetzt auch hier unten verfügbar.)
[EDIT: 2016-11-13 Es gibt jetzt auch eine verbesserte Test-Web-App mit vollständiger Anleitung und Vergleich mit OmniFaces@ViewScoped und Ergebnistabelle auf GitHub hier:https: //github.com/webelcomau/JSFviewScopedNav]
Ich wiederhole hier ein Bild der index.html, das die Navigationsfälle und die Ergebnisse für den Heapspeicher zusammenfasst:
F: Wie kann ich solche "hängenden / baumelnden" @ViewScoped-Beans erkennen, die durch GET-Navigationen verursacht wurden, und sie entfernen oder sie auf andere Weise müllsammelbar machen?
Bitte beachten Sie, dass ich nicht frage, wie sie am Ende der Sitzung bereinigt werden sollen. Ich habe bereits verschiedene Lösungen dafür gefunden. Ich suche nach Möglichkeiten, sie während einer Sitzung zu bereinigen, damit der Heapspeicher während einer Sitzung nicht übermäßig wächst Sitzung aufgrund versehentlicher GET-Navigationen.