Avantages et inconvénients des écouteurs en tant que références faibles

Question

Quels sont les avantages et les inconvénients de conserver les auditeurs en tant que WeakReferences ?

Le grand "pour", bien sûr, c'est que.. :

L'ajout d'un écouteur en tant que WeakReference signifie que l'écouteur n'a pas besoin de s'effacer.

Pour ceux qui s'inquiètent du fait que l'écouteur a la seule référence à l'objet, pourquoi ne peut-il pas y avoir 2 méthodes, addListener() et addWeakRefListener() ?

Ceux qui ne se soucient pas de la suppression peuvent utiliser cette dernière.

Answer 1

Tout d'abord, l'utilisation de WeakReference dans les listes d'écoute donnera à votre objet différents sémantique puis en utilisant des références dures. Dans le cas d'une référence directe, addListener(...) signifie "notifier l'objet fourni d'un ou de plusieurs événements spécifiques". jusqu'à ce que je l'arrête explicitement avec removeListener(..)", dans le cas d'une référence faible, cela signifie "notifier à l'objet fourni un ou plusieurs événements spécifiques". jusqu'à ce que cet objet ne soit plus utilisé par personne d'autre (ou arrêter explicitement avec removeListener)". Notez qu'il est parfaitement légal, dans de nombreuses situations, d'avoir un objet qui écoute certains événements et qui n'a pas d'autres références qui le maintiennent dans la GC. Le logger peut être un exemple.

Comme vous pouvez le voir, l'utilisation de WeakReference ne résout pas seulement un problème ("Je dois garder à l'esprit de ne pas oublier de supprimer l'écouteur ajouté quelque part"), mais en soulève également un autre -- "Je dois garder à l'esprit que mon écouteur peut cesser d'écouter à tout moment quand il n'y a plus de référence à lui". Vous ne résolvez pas le problème, vous échangez juste un problème contre un autre. Regardez, de quelque manière que ce soit vous êtes obligé de définir clairement, de concevoir et de tracer la durée de vie de votre auditeur, d'une manière ou d'une autre.

Donc, personnellement, je suis d'accord avec la mention que l'utilisation de WeakReference dans les listes d'écoute est plus comme un hack qu'une solution. C'est un modèle qui vaut la peine d'être connu, parfois il peut vous aider -- pour faire fonctionner correctement un code hérité, par exemple. Mais ce n'est pas un pattern de choix :)

P.S. Il faut également noter que WeakReference introduit un niveau supplémentaire d'indirection, qui, dans certains cas avec des taux d'événements extrêmement élevés, peut réduire les performances.

Answer 2

Ce n'est pas une réponse complète, mais la force même que vous citez peut aussi être sa principale faiblesse. Considérez ce qui se passerait si les écouteurs d'action étaient mis en œuvre de manière faible :

button.addActionListener(new ActionListener() {
    // blah
});

Ce listener d'action va être collecté à tout moment ! Il n'est pas rare que la seule référence à une classe anonyme soit l'événement auquel vous l'ajoutez.

Answer 3

J'ai vu des tonnes de code où les listeners n'étaient pas désenregistrés correctement. Cela signifie qu'ils étaient toujours appelés inutilement pour effectuer des tâches inutiles.

Si une seule classe dépend d'un listener, alors il est facile de le nettoyer, mais que se passe-t-il lorsque 25 classes en dépendent ? Il devient beaucoup plus délicat de les désenregistrer correctement. Le fait est que votre code peut commencer avec un objet référençant votre listener et se retrouver dans une version ultérieure avec 25 objets référençant ce même listener.

Ne pas utiliser WeakReference équivaut à prendre le risque de consommer inutilement de la mémoire et du processeur. C'est plus compliqué, plus délicat et cela demande plus de travail avec les références dures dans le code complexe.

WeakReferences sont pleins de pros, car ils sont nettoyés automatiquement. Le seul inconvénient est que vous ne devez pas oublier de conserver une référence dure ailleurs dans votre code. Typiquement, ce serait dans les objets s'appuyant sur ce listener.

Je déteste le code créant des instances de classes anonymes d'écouteurs (comme mentionné par Kirk Woll), car une fois enregistrés, vous ne pouvez plus désenregistrer ces écouteurs. Vous n'avez pas de référence à eux. C'est vraiment un mauvais codage IMHO.

Vous pouvez également null une référence à un auditeur lorsque vous n'en avez plus besoin. Vous n'avez plus besoin de vous en préoccuper.

Answer 4

Il n'y a pas vraiment d'avantages. Une référence faible est généralement utilisée pour des données "facultatives", comme un cache où vous ne voulez pas empêcher la collecte des déchets. Vous ne voulez pas que votre écouteur soit ramassé, vous voulez qu'il continue à écouter.

Mise à jour :

Ok, je pense que j'ai peut-être compris où vous voulez en venir. Si vous ajoutez des écouteurs à courte durée de vie à des objets à longue durée de vie, il peut être avantageux d'utiliser une weakReference. Ainsi, par exemple, si vous ajoutez des PropertyChangeListeners à vos objets de domaine pour mettre à jour l'état de l'interface graphique qui est constamment recréée, les objets de domaine vont s'accrocher aux interfaces graphiques, ce qui pourrait s'accumuler. Pensez à un grand dialogue popup qui est constamment recréé, avec une référence d'écouteur à un objet Employee via un PropertyChangeListener. Corrigez-moi si je me trompe, mais je ne pense pas que le modèle PropertyChangeListener soit encore très populaire.

D'autre part, si vous parlez d'écouteurs entre les éléments de l'interface graphique ou si vous avez des objets de domaine qui écoutent les éléments de l'interface graphique, vous n'achèterez rien, car lorsque l'interface graphique disparaîtra, les écouteurs disparaîtront aussi.

Voici quelques lectures intéressantes :

http://www.javalobby.org/java/forums/t19468.html

Comment résoudre les fuites de mémoire de l'écouteur swing ?

Answer 5

Pour être honnête, je n'adhère pas vraiment à cette idée et à ce que vous espérez faire avec un addWeakListener. Peut-être que c'est juste moi, mais cela semble être une fausse bonne idée. Au début, c'est séduisant mais les problèmes que cela pourrait impliquer ne sont pas négligeables.

Avec weakReference, vous n'êtes pas sûr que le listener ne sera plus appelé lorsque le listener lui-même ne sera plus référencé. Le ramasseur d'ordures peut libérer la mémoire quelques ms plus tard ou jamais. Cela signifie qu'il peut continuer à consommer le CPU et faire des choses étranges comme lancer une exception parce que le listener ne sera pas appelé.

Un exemple avec swing serait d'essayer de faire des choses que vous ne pouvez faire que si votre composant d'interface utilisateur est réellement attaché à une fenêtre active. Cela pourrait déclencher une exception et affecter le notificateur, le faisant planter et empêchant les auditeurs valides d'être notifiés.

Le deuxième problème, comme on l'a déjà dit, est celui des auditeurs anonymes, qui peuvent être libérés trop tôt et ne pas être notifiés du tout ou seulement quelques fois.

Ce que vous essayez de faire est dangereux car vous ne pouvez plus contrôler le moment où vous cessez de recevoir des notifications. Elles peuvent durer éternellement ou s'arrêter trop tôt.