Comment résoudre oscillation des fuites de mémoire de l'auditeur?

Question

Historique

Je lis souvent que des fuites de mémoire dans les applications Swing proviennent de l'utilisation de différents auditeurs (souris, clé, mise au point, etc.). Essentiellement, parce que vous enregistrez un objet en tant qu'auditeur et oublier de désenregistrer l'objet, le notifiant finit par tenir sur la référence de l'objet, et fuit un peu de mémoire.

Je savais que notre demande n'a pas été désenregistrement auditeurs et fait un peu de recherche sur les solutions possibles:

J'ai trouvé une approche dans le traitement du problème a été l'utilisation d'un WeakReference, les détails sur l'approche avec les auditeurs swing peuvent être trouvés ici .

Je suis alors devenu curieux de savoir comment le éditeur de formulaire de NetBeans a été génération de code pour nettoyer après les auditeurs ajoutés à la forme et a découvert que NetBeans enregistrait les auditeurs au moyen d'un objet emballage ie

argTypeComboBox.addItemListener(new java.awt.event.ItemListener() {
    public void itemStateChanged(java.awt.event.ItemEvent evt) {
      argTypeComboBoxItemStateChanged(evt);
    }
});

Mais le code généré ne semble pas jamais nettoyer en appelant removeItemListener.

Questions

est l'objet d'emballage agissant comme une référence faible? Pour moi, il semble que cela pourrait couler une petite quantité de mémoire (la taille de l'objet d'emballage)?

Avez-vous des approches alternatives lorsqu'ils traitent avec les auditeurs pour veiller à ce qu'ils sont toujours déchets collectés lorsque vous avez terminé avec eux?

Answer 1

D'abord une correction, la fuite potentielle ici est pas minuscule. Une classe interne anonyme contient une référence à la classe externe, donc tant que l'auditeur est accessible, il tiendra à la classe.

Cependant, cela est généralement pas un problème, que vous ajoutez des auditeurs à des objets sur un cadre. Lorsque ce cadre est disposé (important qu'il soit disposé à, cependant) et n'a pas plus de références (ce qui est assez typique), tous ses composants deviennent inaccessibles (si vous ne faites rien de fantaisie) et l'ensemble devient déchets collectés.

Une fois, j'eu affaire à une application, cependant, qui a fait faire des choses fantaisistes, telles que l'enregistrement des fenêtres ouvertes avec une autre fenêtre, donc si la fenêtre était fermée, il était encore enregistré - grande fuite de mémoire de temps - ces fenêtres étaient pas minuscule .

Ainsi, la ligne de fond est que NetBeans ne fait rien pour provoquer la mémoire « fuites » ici en tant que composant est référencé par le cadre et non à l'extérieur de celui-ci et la composante fait référence à la classe anonyme, ce qui fait référence au cadre - disposer le cadre et le graphe entier est inaccessible, mais vous devez être prudent avec les auditeurs, comme ils peuvent le faire pour vous.