Je sais que les faibles références sont un bon candidat à Memoizing potentiellement volumineux ensembles de données, et L'article de Wikipedia sur les références faibles ne répertorie que "la tenue de la trace des variables actuelles référencées dans l'application" et La déclaration "Une autre utilisation de références faibles consiste à écrire un cache".
Quelles sont les autres situations (plus spécifiques que les "résultats de la mise en cache") où l'utilisation de références faibles est une bonne idée tm ?
4 Réponses :
in Flex, Utilisez des références faibles pour éviter les fuites de mémoire .
Si un gestionnaire d'événements est un membre d'un objet d'instance de courte durée, passant le gestionnaire comme une référence forte à un objet qui vivra plus longtemps peut conserver une instance de courte vie inutilement.
J'utilise de faibles références pour quelques objets ...
J'aime créer des "événements faibles" dans .NET pour éviter que les observateurs vivent trop longtemps.
J'ai également utilisé des événements faibles pour
en Python, le collecteur des ordures utilise le comptage de référence pour décider quand "détruire" ou autrement annouez un objet. Une référence circulaire normale peut entraîner des objets ne perçoivent jamais des ordures recueillies car leur référence de référence reste respectivement à 1 ou plus; mais Utiliser des références faibles permettra aux deux / tous les objets d'être correctement nettoyés lorsqu'ils sortir de la portée.
L'utilisation correcte principale pour les faibles références consiste à identifier les choses dont l'importance découle de l'existence de références fortes à leur . Les deux scénarios les plus courants sont soit:
Un objet détient une référence à quelque chose qui n'est pas parce qu'il "se soucie" de l'objet en question, mais plutôt parce que d'autres entités qui se soucient de l'objet pourraient vouloir faire quelque chose avec elle. Si, après un certain temps, personne ne se soucie de l'objet plus, il n'y a aucune raison pour que les autres entités devraient continuer à le manipuler au nom de «toutes les entités qui s'en soucient à ce sujet».
Le coût de la mémoire de la maintien de nombreuses références au même objet immuable peut être beaucoup plus bas que le coût de la mémoire de détenir des références à de nombreux objets identiques et la comparaison des références au même objet peut être beaucoup plus rapide que la comparaison d'objets identiques. . Le coût de la mémoire de la création d'un objet immuable, l'abandonnant, l'avoir obtenu, et la création d'un objet identique est essentiellement identique au coût de la création d'un objet et de renvoyer une deuxième référence à une seconde référence. Retourner une référence à un objet existant qui devrait être conservé de toute façon est une grosse victoire; Renvoyer une référence à un objet admissible à la collecte mais n'avait pas encore été collecté, mais peut ne pas être une victoire (c'est généralement une légère victoire, mais dans un GC générationnel, cela peut parfois blesser la performance); Dans de nombreux cas, ces derniers avantages ne seraient pas suffisants pour justifier de maintenir un objet en vie plus longtemps que ne seraient autrement nécessaire.
Pourquoi ce wiki communautaire? C'est une question sérieuse!
C'est cw car il n'y a pas une réponse correcte.