Voici la suite et la fin des articles sur les références Java consacré aux PhantomReferences.

Ces dernières sont très différentes des Weak et Soft Reference. Tout d’abord, tout appel à la méthode get() d’une PhantomReference retournera null.

Pourquoi ? Car les PhantomReference sont utilisées pour référencer des objets « presque morts », et vous ne devez donc pas pouvoir les ressusciter !

Concrètement, les PhantomReference sont utilisées pour détecter la suppression d’un objet en mémoire. Leur utilisation est même préférable à l’utilisation de la méthode finalize() (qui a le fâcheux effet de bord de permettre la résurrection des objets).

Voici le constructeur des PhantomReferences :

PhantomReference(Object referent, ReferenceQueue q);


On constate un paramètre supplémentaire par rapport aux autres références : la ReferenceQueue.

L’intérêt de ce paramètre est de fournir une liste des objets libérés par le garbage collector. Vous pouvez ainsi déterminer quand un objet a été libéré (et exécuter ensuite votre propre libération de ressources, par exemple).

Exemple :

// On alloue 1 objet, par exemple une chaîne
String test = "toto";

// Création de la file et de la référence
ReferenceQueue queue = new ReferenceQueue();
PhantomReference ref = new PhantomReference(test, queue);
System.out.println(test);


// On libère l'objet
test = null;
boolean fin = false;

// Et on attend la libération
while (!fin) {
// Demande de référence avec attente d'une seconde max
Reference phantRef = queue.remove(1000);
if (phantRef == ref) {
System.out.println("Objet libéré");
fin = true;
}
[...]
}


Suite à l’article précédent sur les WeakReferences, voici un petit topo sur les SoftReferences. (ça a mis le temps, mais j’ai eu peu de disponibilités récemment )

Il existe donc un autre type de référence, les SoftReferences, qui sont plus faibles que les WeakReferences, en effet, un objet lié par une SoftReference est éligible à la garbage collection si la JVM est saturée.

En gros, une WeakReference pourra disparaître à la prochaine garbage collection, tandis qu’une SoftReference restera en mémoire jusqu’à saturation, et là, elle sera garbage collectée.

Il ne faut donc utiliser ces références que :

• si vous pouvez facilement remonter l’objet concerné en mémoire
• si vous voulez gérer un cache de données que vous avez déjà remontées et que vous voudriez potentiellement réutiliser.

Par exemple, dans une application qui affiche les couvertures de livres d’un utilisateur de bibliothèque, avec pagination.

Vous pouvez vouloir garder en mémoire les images de chaque livre disponible pour optimiser la navigation, sans pour autant bloquer la mémoire. Vous pouvez mettre en place un mécanisme du type :


public class Livre {
private String titre = null;
private SoftReference couverture = new SoftReference(null);
...
public Image getCouverture() {
Image imageCouverture = couverture.get();
if (imageCouverture == null) {
rechargeImage();
}
}
...
}

Dans ce code, l’image de la couverture est relue depuis le disque si elle n’est pas disponible et reste en mémoire jusqu’à une saturation de la mémoire, puis garbage collection.

Il faut bien faire attention à tester le null, car elle peut disparaître de la mémoire sans prévenir.

[ Ethan Nicholas’s Blog : Understanding Weak References ]

Update :
La bibliothèque Google Guava fournit une classe MapMaker qui permet de générer des ConcurrentMap dont les clés/valeurs peuvent être des Weak ou Soft references.

Voici un petit topo rapide sur un élément peu connu du fonctionnement du Garbage Collector Java : les WeakReferences.

Les WeakReferences permettent de référencer un objet sans le « locker » vis-à-vis du Garbage Collector.

Imaginons que vous ayez un ensemble d’objets dont vous voulez stocker le timestamp de création, vous pouvez par exemple utiliser une HashMap :

Map<MonObjet, Long> maHashMap = new HashMap<MonObjet,Long>();
...
maHashMap.put(unObjet,System.currentTimeMillis());
...


Maintenant, imaginons que votre objet ne soit plus utile.
Si vous oubliez de supprimer cet objet de la hashmap, il restera en mémoire, le garbage collector ne libérera jamais cet objet, car il est référencé par la map.
Vous ne devez donc pas oublier de faire un remove(), sinon, vous aurez une fuite mémoire !

Grâce aux WeakReferences et plus précisément l’objet WeakHashMap, vous avez une alternative face à ce problème. Remplacez votre code par :

Map<MonObjet, Long> maHashMap = new WeakHashMap<MonObjet,Long>();
...
maHashMap.put(unObjet,System.currentTimeMillis());
...


Quelle est la différence ? L’utilisation d’une WeakReference sur la clé de la HashMap !

Concrètement, ça signifie que si votre objet n’est plus référencé nulle part, il disparaîtra de votre Map dès le passage du Garbage Collector. Magique : plus de risque de fuite mémoire !

[ Ethan Nicholas’s Blog : Understanding Weak References ]