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.