En dépit de la présence d'un Garbage Collector (GC) assurant la gestion automatique de la mémoire en Java, les applications peuvent subir des fuites de mémoire. Ce phénomène, distinct de l'erreur OutOfMemoryError, survient lorsque des objets inutilisés restent référencés de manière involontaire, empêchant le GC de libérer l'espace heap. Dans un environnement de production, cette accumulation progressive dégrade les performances, provoque des fréquences élevées de passage du GC (entraînant des "lags"), et peut finalement mener à l'arrêt brutal de l'application.
Causes courantes des fuites de mémoire
L'identification de la source de la fuite est la première étape vers la résolution. Voici les scénarios les plus fréquents.
1. Utilisation excessive de collections statiques
Les variables statiques ont une durée de vie liée à celle du chargeur de classe (ClassLoader). Stocker des données dynamiques ou des collections croissantes dans un champ statique empêche la collecte des objets contenus tant que l'application est en cours d'exécution.
public class GlobalCache {
// Risque : cette map persiste tant que la JVM est active
private static final Map<String, Object> STORAGE = new HashMap<>();
public void store(String key, Object payload) {
STORAGE.put(key, payload);
}
public static void main(String[] args) {
GlobalCache cache = new GlobalCache();
// Boucle infinie simulant un ajout continu
while (true) {
cache.store(UUID.randomUUID().toString(), new LargeObject());
}
}
}
class LargeObject {
private byte[] data = new byte[1024 * 1024]; // 1 MB
}
Dans cet exemple, la référence statique STORAGE empêche la récupération des instances de LargeObject, saturant progressivement le tas mémoire.
2. Mauvaise gestion de la méthode finalize()
Bien que dépréciée, la méthode finalize() (héritée de Object) peut encore poser problème. Si un objet surcharge cette méthode et qu'il n'est pas finalisé promptement par le GC, il reste en mémoire plus longtemps que nécessaire. Pire, un objet peut "se ressusciter" en créant une nouvelel référence vers lui-même lors de la finalisation.
public class ResurrectedObject {
private static ResurrectedObject savedRef;
@Override
protected void finalize() throws Throwable {
super.finalize();
// Action dangereuse : l'objet se réattribue à une référence statique
savedRef = this;
}
}
3. Rétention inutile d'objets
Une erreur de logique peut conduire à conserver des références vers des objets qui ne sont plus nécessaires. Cela se produit souvent lors de l'implémentation de structures de données personnalisées ou de gestionnaires d'état.
public class StackManager {
private Object[] elements;
private int size = 0;
public StackManager(int capacity) {
this.elements = new Object[capacity];
}
public Object pop() {
if (size == 0) throw new EmptyStackException();
// Fuite potentielle : l'objet est dépilé mais la référence dans le tableau persiste
return elements[--size];
}
}
Lors de la méthode pop(), l'objet est extrait, mais la case du tableau elements[size] contient toujours la référence ancienne. Pour corriger cela, il faut explicitement assigner null à la position du tableau après l'extraction.
4. Ressources non libérées (IO, JDBC)
Les connexions à la base de données, les flux de fichiers ou les sockets utilisent des ressources natives et de la mémoire heap. Oublier de fermer ces ressources maintient des objets système actifs, bloquant des file descriptors et de la mémoire Java.
public class DataReader {
public void readFile(String path) {
try {
FileInputStream fis = new FileInputStream(path);
BufferedReader reader = new BufferedReader(new InputStreamReader(fis));
String line;
while ((line = reader.readLine()) != null) {
// Traitement des données
}
// Fuite : 'fis' et 'reader' ne sont pas fermés en cas d'exception ou de sortie normale
} catch (IOException e) {
e.printStackTrace();
}
}
}
L'utilisation de blocs try-with-resources est la solution recommandée pour garantir la libération automatique.
5. Mauvaise utilisation de ThreadLocal
ThreadLocal permet de stocker des données locales à un thread. Chaque thread possède sa propre ThreadLocalMap. Si un ThreadLocal est instancié, utilisé, puis que sa référence est mise à null sans appeler remove(), et que le thread concerné (par exemple dans un pool de threads) reste actif, l'objet valeur ne peut pas être collecté.
public class RequestContext {
private static final ThreadLocal<String> userContext = new ThreadLocal<>();
public void processRequest(String user) {
try {
userContext.set(user);
// Logique métier
} finally {
// Correct : nettoyage explicite pour éviter la fuite dans les pools de threads
userContext.remove();
}
}
}
Si remove() est omis, la valeur reste dans la map du thread tant que celui-ci n'est pas détruit.
Méthodes de détection et outils
Commandes JVM standard
Il est possible d'analyser l'état de la mémoire via les outils fournis avec le JDK :
- jps : Liste les processus Java en cours d'exécution.
- jstat : Surveille les statistiques du compilateur et du Garbage Collector (ex:
jstat -gcutil <pid>). - jmap : Permet de visualiser la configuration du tas mémoire et de générer des dumps (ex:
jmap -dump:format=b,file=heap.bin <pid>). - jstack : Affiche les traces de la pile des threads Java pour détecter les interblocages ou l'activité intense.
Outils d'analyse et de profilage
Pour une analyse approfondie, l'utilisation d'outils graphiques est recommandée :
- VisualVM : Outil fourni avec le JDK (ou séparément) permettant de visualiser l'usage du CPU, de la mémoire, et de réaliser des dumps.
- Java Mission Control (JMC) : Fournit des détails de bas niveau sur la JVM et le GC.
- JProfiler / YourKit : Outils commerciaux puissants pour tracer les allocations d'objets, identifier les références gardiennes et localiser les fuites.
- Eclipse Memory Analyzer (MAT) : Spécialisé dans l'analyse de fichiers
.hprof, il aide à identifier les objets dominants et les chemins de GC Roots.
L'activation des logs de GC (-verbose:gc ou -Xlog:gc* en versions récentes) fournit également des informations précieuses sur la fréquence et la durée des cycles de nettoyage, indicateurs clés d'une suspicion de fuite.