La pauvreté dans l’abondance, la mémoire oubliée
J’avais bien étudié la ‘structure de la mémoire’ en cours de Système d’Exploitation ou de Programmation Système à l’école. Je me souviens même que les termes Stack (Pile) et Heap (Tas) étaient des questions d’examen.
Mais pour être honnête, jusqu’à l’obtention de mon diplôme, je ne me suis jamais vraiment soucié de la mémoire. À une époque où les ordinateurs portables personnels ont 16 Go ou 32 Go de RAM par défaut, il était pratiquement impossible de manquer de mémoire avec des projets de niveau universitaire. De plus, avec des langages comme Java où le Garbage Collector (GC) fait le ménage tout seul, je n’avais aucune raison de me soucier des adresses mémoire.
C’est ainsi que, ivre de l’abondance matérielle et du confort du langage, je me suis lancé dans la vie active en ayant oublié ce ‘sens de la mémoire’, pourtant fondamental pour un développeur.
La leçon douloureuse du terrain
Quand je m’entraînais pour les tests de code à l’école, je ne faisais que manipuler quelques nombres dans des tableaux. Les données d’entrée dépassaient rarement les 100 000. Mais en entreprise, c’était une autre histoire. Même dans une petite startup, la base de données (DB) accumulait des millions de données clients réelles.
Sur le terrain, pour manipuler ces données massives confortablement, on utilise une technologie appelée ‘ORM (Object Relational Mapping)’. C’est un outil très appréciable qui permet de manipuler les données comme des objets Java sans avoir à écrire de requêtes SQL manuellement (Hibernate est la référence dans l’écosystème Java).
Le problème, c’est que cet outil est ‘trop confortable’.
En appuyant sur un seul bouton, il récupère les données de la DB sous forme de liste. Je n’avais pas mesuré le poids des données cachées derrière cette simplicité. J’avais juste écrit une ligne de code : « Récupère les infos clients ». Mais en réalité, j’avais chargé en mémoire les informations de dizaines de milliers de personnes et tout leur historique de commandes.
Le résultat fut catastrophique. Les 32 Go de RAM se sont remplis en un instant. Le serveur a souffert d’un ‘Lag extrême’ à cause du GC (le nettoyeur) qui essayait désespérément de libérer de l’espace, avant de finalement s’arrêter net.
Stack familier, Heap inconnu
En décortiquant les logs d’erreur vomis par le serveur, un mot a attiré mon attention.
java.lang.OutOfMemoryError: Java heap space
Le mot ‘Stack’ m’était assez familier. Je l’avais appris jusqu’à l’écœurement en cours de structures de données, et c’est aussi le nom du site que tout développeur visite au moins une fois par jour (Stack Overflow). Je savais aussi par bon sens qu’une fonction récursive mal écrite faisait exploser la Stack.
Mais le coupable que je rencontrais à chaque plantage de serveur en production n’était pas la Stack. Les logs pointaient toujours vers le ‘Heap’.
« Ce n’est pas la Stack qui est pleine, mais l’espace Heap ? »
Un doute m’a traversé l’esprit. Je vois ce qu’est la Stack, mais qu’est-ce que le Heap pour qu’il explose si souvent en production ? Est-ce le même Heap que celui des structures de données ? Pourquoi mon code torture-t-il le Heap et pas la Stack ?
Ce doute m’a ramené vers mes livres de cours poussiéreux et le monde de Google. Et j’ai compris. La ‘Mémoire (RAM)’, la maison où vit mon code, n’est pas un studio unique, mais un ‘espace divisé’ géré strictement selon l’usage.
L’établi et l’entrepôt du Centre Logistique Numérique
Revenons à notre univers du ‘Centre Logistique Numérique’. Ici, la ‘RAM (Mémoire)’ est l’espace où l’ouvrier (CPU) étale ses affaires pour travailler. Mais pour l’efficacité, cet espace est strictement divisé en deux zones.
1. Stack (Pile) : L’établi personnel de l’ouvrier
- Caractéristique : C’est un bureau étroit et haut, situé juste devant l’ouvrier (CPU).
- Usage : On y pose brièvement les variables (locales, paramètres) nécessaires à la tâche (fonction) en cours immédiat.
- Durée de vie : Dès que la tâche (fonction) est finie, on vide complètement le bureau (Pop). La gestion est très facile et rapide.
- Métaphore : Les ingrédients posés sur la planche à découper pendant la cuisine. Une fois le plat fini, on débarrasse tout de suite.
2. Heap (Tas) : L’entrepôt logistique commun
- Caractéristique : C’est un immense entrepôt situé derrière l’établi. L’espace est vaste, mais il faut du temps pour aller chercher un objet.
- Usage : On y stocke les données volumineuses ou qui doivent être conservées longtemps (Objets, Instances).
- Durée de vie : Elles restent là tant que l’utilisateur ne les jette pas ou que le nettoyeur (Garbage Collector) ne passe pas.
- Métaphore : Le frigo ou le garde-manger. Même quand la cuisine est finie, les ingrédients restent là.
[Code Verification] Deux mondes prouvés par l’erreur
La mémoire est-elle vraiment divisée ainsi ? En provoquant volontairement des erreurs par le code, nous pouvons prouver l’existence de ces deux espaces.
1. Faire exploser la Stack (StackOverflowError)
J’ai dit que la Stack était un ‘établi’. L’établi est étroit. Si une fonction ne se termine pas et continue de s’appeler elle-même (Récursion), les dossiers s’empilent sur le bureau jusqu’au plafond et finissent par s’effondrer.
public class StackTest {
public static void recursiveCall(int depth) {
// Récursion infinie : La fonction ne finit jamais et s'empile sur l'établi (Stack)
System.out.println("Stack Depth: " + depth);
recursiveCall(depth + 1);
}
public static void main(String[] args) {
recursiveCall(1);
}
}
Résultat : Après quelques milliers de tours, le programme meurt en crachant une StackOverflowError. Même si l’espace Heap est vide, si la Stack (l’établi) est pleine, le programme plante.
2. Faire exploser le Heap (OutOfMemoryError)
Cette fois, reproduisons mon cauchemar. Similaire à la situation où j’ai chargé des dizaines de milliers d’objets via l’ORM, je vais créer une liste géante et la bourrer dans l’entrepôt (Heap).
import java.util.ArrayList;
import java.util.List;
public class HeapTest {
public static void main(String[] args) {
List<byte[]> warehouse = new ArrayList<>();
while (true) {
// Création continue de données de 1 Mo empilées dans l'entrepôt (Heap)
// Exemple réel : Récupérer des milliers de lignes en DB sans pagination
warehouse.add(new byte[1024 * 1024]);
}
}
}
Résultat : java.lang.OutOfMemoryError: Java heap space. Ce n’est pas un problème d’établi (Stack). L’erreur survient parce qu’il n’y a plus de place pour stocker les marchandises dans l’entrepôt (Heap). C’est le moment où je vois de mes yeux comment mon code torture le Heap.
L’existence du nettoyeur : Garbage Collector (GC)
Il y a ici une différence majeure. La Stack se vide ‘automatiquement’ à la fin de la fonction. Pas besoin de s’en soucier. Mais pour le Heap, si personne ne nettoie, les déchets s’accumulent.
Dans les langages anciens comme le C, le développeur devait nettoyer lui-même avec la commande free(). S’il oubliait, l’entrepôt débordait de déchets (Fuite de mémoire / Memory Leak). En revanche, les langages modernes comme Java, Python ou JavaScript ont embauché un nettoyeur professionnel : le ‘GC (Garbage Collector)’.
« Tiens, personne n’utilise plus cet objet ? » Le GC parcourt périodiquement le Heap, trouve les objets sans propriétaire et les jette. Grâce à lui, nous n’avons pas à écrire de code de libération de mémoire.
Mais rien n’est gratuit. Au moment où le GC fait son grand nettoyage, tout le travail du centre logistique s’arrête momentanément (Stop-the-world). Si votre jeu lag soudainement ou si le serveur se fige une seconde, c’est à cause de ce temps de nettoyage.
Conclusion : L’œil qui voit l’invisible
Après avoir compris la Stack et le Heap, le code sur mon écran a commencé à ressembler à autre chose. Avant, en voyant new Student(), je pensais simplement « J’ai créé un objet ». Mais maintenant, je le vois. « Ah, une boîte vient d’entrer dans l’entrepôt Heap. Si je ne l’efface pas (ou si le GC ne passe pas), elle va continuer à manger de la mémoire. »
Depuis que j’ai acquis cet ‘œil pour voir l’invisible’, je suis sorti de la peur vague. Même si le serveur crache un OutOfMemory, je ne me précipite plus sur le bouton de redémarrage en panique. Au lieu de cela, je demande calmement « Quel objet a envahi le Heap ? » et je lance l’outil d’analyse. Car quand on connaît la cause, on peut résoudre le problème.
Nous avons maintenant conquis l’espace où le code est stocké (Memory). L’entrepôt logistique est parfaitement prêt. Mais alors, qui sont les ‘ouvriers’ qui transportent et assemblent réellement les objets dans cet entrepôt ? Quelle est la différence entre travailler seul et travailler à plusieurs en même temps (Multi-Tasking) ?
La prochaine fois, partons à la découverte de la fleur du système d’exploitation et de l’éternel devoir des développeurs backend : le monde des ‘Processus et Threads (Process & Thread)’.