L'utilisation de références faibles est quelque chose dont je n'ai jamais vu d'implémentation, donc j'essaie de comprendre quel est leur cas d'utilisation et comment l'implémentation fonctionnerait. Quand avez-vous eu besoin d'utiliser un WeakHashMapou WeakReferenceet comment l'a-t-il été?

Un problème avec les références fortes est la mise en cache, en particulier avec les très grandes structures comme les images. Supposons que vous ayez une application qui doit fonctionner avec des images fournies par l'utilisateur, comme l'outil de conception de site Web sur lequel je travaille. Naturellement, vous voulez mettre ces images en cache, car leur chargement à partir du disque coûte très cher et vous voulez éviter la possibilité d'avoir deux copies de l'image (potentiellement gigantesque) en mémoire à la fois.

Parce qu'un cache d'images est censé nous empêcher de recharger des images lorsque nous n'en avons pas absolument besoin, vous vous rendrez vite compte que le cache doit toujours contenir une référence à toute image déjà en mémoire. Avec des références fortes ordinaires, cependant, cette référence elle-même forcera l'image à rester en mémoire, ce qui vous obligera à déterminer quand l'image n'est plus nécessaire en mémoire et à la supprimer du cache, afin qu'elle devienne éligible pour le garbage collection. Vous êtes obligé de dupliquer le comportement du garbage collector et de déterminer manuellement si un objet doit ou non être en mémoire.

Comprendre les références faibles , Ethan Nicholas

WeakReference contre SoftReference

Une distinction sur laquelle il faut être clair est la différence entre a WeakReferenceet a SoftReference.

Fondamentalement, un WeakReferencesera GC-d par la JVM avec impatience, une fois que l'objet référencé n'y aura pas de références matérielles . Un SoftReferenceobjet d, d'autre part, aura tendance à être laissé par le ramasse-miettes jusqu'à ce qu'il ait vraiment besoin de récupérer la mémoire.

Un cache où les valeurs sont conservées dans WeakReferences serait assez inutile (dans a WeakHashMap, ce sont les clés qui sont faiblement référencées). SoftReferencessont utiles pour envelopper les valeurs lorsque vous souhaitez implémenter un cache qui peut augmenter et diminuer avec la mémoire disponible.

Une utilisation courante de WeakReferences et WeakHashMaps en particulier consiste à ajouter des propriétés aux objets. Parfois, vous souhaitez ajouter des fonctionnalités ou des données à un objet, mais le sous-classement et / ou la composition ne sont pas une option.Dans ce cas, la chose évidente à faire serait de créer un hashmap reliant l'objet que vous souhaitez étendre à la propriété que vous souhaitez ajouter . puis chaque fois que vous avez besoin de la propriété, vous pouvez simplement la rechercher sur la carte. Cependant, si les objets auxquels vous ajoutez des propriétés ont tendance à être détruits et créés beaucoup, vous pouvez vous retrouver avec un grand nombre d'objets anciens dans votre carte occupant beaucoup de mémoire.

Si vous utilisez à la WeakHashMapplace, les objets quitteront votre carte dès qu'ils ne seront plus utilisés par le reste de votre programme, ce qui est le comportement souhaité.

Je devais le faire pour ajouter quelques données java.awt.Componentpour contourner un changement dans l'entre JRE et 1,5 1.4.2, je aurais pu la réparer par le sous - classement tous les composants que j'étais intéressé int ( JButton, JFrame, JPanel....) mais cela était beaucoup plus facile avec beaucoup moins de code.

Un autre cas utile pour WeakHashMapet WeakReferenceest une implémentation de registre d'écoute .

Lorsque vous créez quelque chose qui veut écouter certains événements, vous enregistrez généralement un auditeur, par exemple

manager.registerListener(myListenerImpl);

Si le managerstocke votre auditeur avec un WeakReference, cela signifie que vous n'avez pas besoin de supprimer le registre, par exemple avec un manager.removeListener(myListenerImpl)car il sera automatiquement supprimé une fois que votre auditeur ou votre composant contenant l'écouteur devient indisponible.

Bien sûr, vous pouvez toujours supprimer manuellement votre auditeur, mais si vous ne le faites pas ou si vous l'oubliez, cela ne provoquera pas de fuite de mémoire et n'empêchera pas votre auditeur d'être récupéré.

D'où WeakHashMapvient la photo?

Le registre d'écouteurs qui souhaite stocker les écouteurs enregistrés en tant que WeakReferences a besoin d'une collection pour stocker ces références. Il n'y a pas d' WeakHashSetimplémentation dans la bibliothèque standard Java seulement WeakHashMapmais nous pouvons facilement utiliser cette dernière pour "implémenter" la fonctionnalité de la première:

Set<ListenerType> listenerSet =
    Collections.newSetFromMap(new WeakHashMap<ListenerType, Boolean>());

Avec cela listenerSetpour enregistrer un nouvel écouteur il suffit de l'ajouter à l'ensemble, et même s'il n'est pas supprimé explicitement, si l'écouteur n'est plus référencé, il sera automatiquement supprimé par la JVM.

Ce billet de blog montre l'utilisation des deux classes: Java: synchronisation sur un ID . L'utilisation va quelque chose comme ceci:

private static IdMutexProvider MUTEX_PROVIDER = new IdMutexProvider();

public void performTask(String resourceId) {
    IdMutexProvider.Mutex mutext = MUTEX_PROVIDER.getMutex(resourceId);
    synchronized (mutext) {
        // look up the resource and do something with it
    }
}

IdMutextProvider fournit des objets basés sur l'ID sur lesquels se synchroniser. Les exigences sont:

• doit renvoyer une référence au même objet pour une utilisation simultanée d'ID équivalents
• doit renvoyer un objet différent pour différents ID
• pas de mécanisme de libération (les objets ne sont pas retournés au fournisseur)
• ne doit pas fuir (les objets inutilisés sont éligibles pour le garbage collection)

Ceci est réalisé en utilisant une carte de stockage interne de type:

WeakHashMap<Mutex, WeakReference<Mutex>>

L'objet est à la fois clé et valeur. Lorsque rien d'extérieur à la carte n'a de référence ferme à l'objet, il peut être récupéré. Les valeurs de la carte sont stockées avec des références matérielles, de sorte que la valeur doit être encapsulée dans un WeakReference pour éviter une fuite de mémoire. Ce dernier point est traité dans le javadoc .

Si vous voulez par exemple garder une trace de tous les objets créés d'une certaine classe. Pour continuer à permettre à ces objets d'être récupérés, vous conservez une liste / une carte des références faibles aux objets au lieu des objets eux-mêmes.

Maintenant, si quelqu'un pouvait m'expliquer des références fantômes, je serais heureux ...

Comme indiqué ci-dessus, les références faibles sont conservées aussi longtemps qu'une référence forte existe.

Un exemple d'utilisation serait d'utiliser WeakReference dans les écouteurs, afin que les écouteurs ne soient plus actifs une fois que la référence principale à leur objet cible a disparu. Notez que cela ne signifie pas que WeakReference est supprimé de la liste des écouteurs, le nettoyage est toujours nécessaire mais peut être effectué, par exemple, à des heures planifiées. Cela a également pour effet d'empêcher l'objet écouté de contenir des références fortes et éventuellement d'être une source de ballonnement mémoire. Exemple: composants d'interface graphique Swing faisant référence à un modèle ayant un cycle de vie plus long que la fenêtre.

En jouant avec les auditeurs comme décrit ci-dessus, nous avons rapidement réalisé que les objets sont collectés «immédiatement» du point de vue de l'utilisateur.

Une utilisation dans le monde réel que j'ai eue de WeakReferences est si vous avez un seul objet très grand qui est rarement utilisé. Vous ne voulez pas le garder en mémoire lorsqu'il n'est pas nécessaire; mais, si un autre thread a besoin du même objet, vous n'en voulez pas non plus deux en mémoire. Vous pouvez conserver quelque part une référence faible à l'objet et des références matérielles dans les méthodes qui l'utilisent; lorsque les deux méthodes se terminent, l'objet sera collecté.

J'ai fait une recherche de code google pour "new WeakHashMap ()".

J'ai eu un tas de correspondances du projet de classpath GNU et

1. Projet Apache xbean: WeakHashMapEditor.java
2. Projet Apache Lucene: CachingWrapperFilter.java

vous pouvez utiliser lowhashmap pour implémenter une mise en cache sans ressources pour une création d'objets étendue.

mais notez qu'il n'est pas souhaitable d'avoir des objets mutables. Je l'ai utilisé pour mettre en cache les résultats de la requête (qui prennent environ 400 ms à exécuter) sur un moteur de recherche de texte, qui est rarement mis à jour.