[JAVA] L'histoire de @ViewScoped dévore la mémoire

environnement

application Web

Java 8
Java EE 7 (Payara 4)
JSF 2.2

phénomène

L'application est morte dans OutOfMemory. Le bean de gestion de l'écran fermé est vivant et R.I.P.

Partie suspecte

Long timeout de session
Certains haricots de gestion mangent la mémoire

Flux initial

Explication commune

Annotation	Espace de nom	Durée de vie
`@RequestScoped`	javax.enterprise.context.RequestScoped	Une requête HTTP/réponse
`@ViewScoped`	javax.faces.view.ViewScoped	Alors que les vues sont les mêmes
`@SessionScoped`	javax.enterprise.context.SessionScoped	Début-fin de session
`@ApplicationScoped`	javax.enterprise.context.ApplcationScoped	Pendant que l'application est en cours d'exécution
`@Dependent`	javax.enterprise.context.Dependent	Dépend de la portée de la destination injectée
`@ConversationScoped`	javax.enterprise.context.ConversationScoped	Vous pouvez spécifier le début et la fin de manière arbitraire
`@FlowScoped`	javax.enterprise.context.FlowScoped	Du début à la fin d'un flux prédéfini

Ma compréhension

Hmm. ** Il est pratique si @ ViewScoped est généré lorsque l'écran est ouvert et jeté lorsqu'il est fermé. ** ** Vous pouvez donner à @ SessionScoped les informations de l'utilisateur connecté et créer un écran professionnel avec @ ViewScoped.

Vous pouvez également spécifier le nombre de "vues" qu'une session contient dans "web.xml".

/web.xml
    <context-param>
        <param-name>javax.faces.STATE_SAVING_METHOD</param-name>
        <param-value>sever</param-value>
    </context-param>
    <context-param>
        <param-name>com.sun.faces.numberOfLogicalViews</param-name>
        <param-value>20</param-value>
    </context-param>
    <context-param>
        <param-name>com.sun.faces.numberOfViewsInSession</param-name>
        <param-value>20</param-value>
    </context-param>

Sachez s'il sera libéré si la limite supérieure est dépassée.

Quand j'ai fait quelque chose comme ça, le bean de gestion de @ ViewScoped, qui aurait dû être détruit, était très vivant et la mémoire était écrasée.

Réellement

Apparemment, le bean de gestion de @ ViewScoped ne sera pas publié à moins qu'il n'ait le modèle suivant.

Postback sans résultat
La session a expiré

Par conséquent, il survit dans le modèle suivant.

ACCÉDER à une autre page
Actualisation de la page
Lorsque le nombre maximum de vues logiques dans une session est dépassé (expire mais n'est pas détruit)

Solution

Utilisez OmniFaces @ViewScoped au lieu du standard @ ViewScoped. Utilisez simplement l'annotation @ ViewScoped de ʻOmniFaces et elle la publiera lorsque vous récupérerez l'événement ʻunload de votre navigateur. Il est conçu pour ne pas affecter autant que possible la dépendance par défaut, je me demande donc s'il peut être introduit simplement pour utiliser @ ViewScoped.

Épilogue

Je pensais carrément que View serait géré écran par écran, mais ce n'est pas une unité basée sur un écran, mais une unité basée sur une arborescence de composants, il est donc faux de s'attendre à ce qu'elle soit publiée lorsque l'écran est fermé.

C'est un comportement d'interruption qui n'est pas ignoré même si le nombre maximal de vues logiques est dépassé.

~~ Ne tenez pas la session pendant longtemps et ne la rendez pas énorme ~~

Les références

jsf-2 - Pourquoi les @ViewScoped Beans qui ont expiré ne sont pas détruits avant l'expiration de la session stack overflow : JSF 2.2 Memory Consumption: Why does Mojarra keep the ViewScoped Beans of the last 25 Views in Memory?