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.