Architecture Mémoire de la JVM
Cours Universitaire
Dr. Badr EL KHALYLY
Année Universitaire 2025–2026
Résumé
La Java Virtual Machine (JVM) constitue le cœur de l’écosystème Java. Une
compréhension approfondie de son architecture mémoire est essentielle pour analyser
les performances, diagnostiquer les erreurs d’exécution et concevoir des applications
robustes et concurrentes.
Ce cours présente de manière structurée :
— les différents espaces mémoire de la JVM et leur rôle,
— les liens avec le bytecode, le chargement de classes et le ramasse-miettes (Garbage
Collector),
— des exemples concrets de code Java et de messages d’erreur,
— quelques notions avancées (Metaspace, générations, tuning mémoire).
Table des matières
1 Introduction 3
1.1 Rappel sur la philosophie Java . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Pourquoi étudier l’architecture mémoire ? . . . . . . . . . . . . . . . . . . . 3
1.3 Vue d’ensemble . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Vue Globale de la Mémoire JVM 4
2.1 Espaces mémoire partagés vs privés . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Carte conceptuelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3 Method Area et Metaspace 4
3.1 Définition générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2 Rôle et contenu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.3 Runtime Constant Pool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.4 Caractéristiques de la Method Area / Metaspace . . . . . . . . . . . . . . . 5
3.5 Exemple de fuite de Metaspace . . . . . . . . . . . . . . . . . . . . . . . . 5
4 Heap Area 5
4.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2 Fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.3 Générations (Young / Old / Survivor) . . . . . . . . . . . . . . . . . . . . 5
4.4 Impact sur les performances . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.5 Tuning du Heap (aperçu) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1
5 Stack Area (Java Stack) 6
5.1 Pile d’exécution par thread . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.2 Structure d’une Stack Frame . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.3 Exemple simple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.4 Erreurs liées à la Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.5 Caractéristiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6 PC Register (Program Counter) 7
6.1 Rôle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.2 Importance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.3 Remarque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7 Native Method Stack 8
7.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.2 Caractéristiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.3 Lien avec la sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8 Erreurs Mémoire Courantes 8
8.1 StackOverflowError . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.2 OutOfMemoryError: Java heap space . . . . . . . . . . . . . . . . . . . . 9
8.3 OutOfMemoryError: Metaspace . . . . . . . . . . . . . . . . . . . . . . . . 9
9 Lien entre Modèle de Mémoire et Concurrence (Aperçu) 9
9.1 Partage du Heap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.2 Isolation des Stacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.3 Effets sur le Garbage Collector . . . . . . . . . . . . . . . . . . . . . . . . . 10
10 Résumé et Conclusion 10
10.1 Résumé des zones mémoire . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.2 Importance pour l’ingénieur Java . . . . . . . . . . . . . . . . . . . . . . . 10
2
1 Introduction
1.1 Rappel sur la philosophie Java
Java est un langage orienté objet reposant sur le principe « Write Once, Run Anyw-
here ». Les programmes Java ne sont pas compilés directement en code machine natif,
mais en bytecode stocké dans des fichiers .class, puis exécuté par la Java Virtual
Machine (JVM).
La JVM agit comme une couche d’abstraction entre le programme Java et le système
d’exploitation :
— le compilateur javac produit du bytecode indépendant de la plateforme ;
— la JVM, spécifique à une plateforme (Windows, Linux, macOS, ARM, x86...), in-
terprète ou compile (JIT) ce bytecode en instructions machine ;
— la gestion de la mémoire (allocation, libération, fragmentation) est prise en charge
par la JVM via le Garbage Collector.
1.2 Pourquoi étudier l’architecture mémoire ?
Une bonne compréhension de la mémoire de la JVM permet :
— d’expliquer l’origine de certaines erreurs (OutOfMemoryError, StackOverflowError) ;
— d’interpréter des profils mémoire (via VisualVM, JMC, YourKit, etc.) ;
— d’optimiser les performances (taille du Heap, choix du GC, réduction des alloca-
tions inutiles) ;
— de concevoir des programmes concurrentiels mieux scalables.
1.3 Vue d’ensemble
Sans entrer dans les détails d’une implémentation particulière (HotSpot d’Oracle/O-
penJDK étant la plus courante), la mémoire gérée par la JVM peut être découpée logi-
quement en plusieurs zones :
— des zones partagées entre tous les threads (Heap, Method Area/Metaspace, code
JIT, etc.) ;
— des zones privées à chaque thread (Java Stack, Program Counter, Native Method
Stack).
Dans la suite, nous décrirons chacune de ces zones, leur contenu, leurs caractéristiques
et les principaux problèmes qui peuvent survenir.
3
2 Vue Globale de la Mémoire JVM
2.1 Espaces mémoire partagés vs privés
— Partagés par tous les threads :
— Heap (objets, tableaux) ;
— Method Area / Metaspace (métadonnées de classes, constantes, bytecode) ;
— zones associées au JIT (code compilé, profils d’exécution).
— Spécifiques à chaque thread :
— Java Stack (pile d’exécution des méthodes Java) ;
— PC Register (compteur ordinal, Program Counter) ;
— Native Method Stack (pile utilisée par les méthodes natives via JNI).
2.2 Carte conceptuelle
De manière simplifiée, chaque thread Java dispose de sa propre pile (Stack) et de ses
registres, mais tous les threads manipulent des références vers des objets stockés dans le
Heap partagé. Le Garbage Collector est responsable de la libération de ces objets lorsque
plus aucun thread n’y fait référence.
3 Method Area et Metaspace
3.1 Définition générale
La Method Area est une zone mémoire partagée entre tous les threads, décrite dans
la spécification de la JVM comme contenant des informations de type « structure de
classe ».
Historiquement, dans HotSpot, cette zone était implémentée par la PermGen (Per-
manent Generation). Depuis Java 8, elle est remplacée par le Metaspace, qui est alloué
dans la mémoire native (hors Heap) et peut, en théorie, grandir jusqu’à épuisement de la
mémoire du processus.
3.2 Rôle et contenu
Elle stocke notamment :
— les métadonnées de classes chargées :
— nom de la classe, super-classe, interfaces ;
— champs (attributs) et méthodes (signatures, modificateurs) ;
— informations sur l’héritage et les annotations.
— le bytecode des méthodes ;
— le Runtime Constant Pool de chaque classe :
— littéraux (String, int, float, . . .) ;
— références symboliques vers d’autres classes, méthodes et champs.
3.3 Runtime Constant Pool
Chaque classe ou interface possède un Constant Pool construit à partir du fichier
.class. À l’exécution, ce Runtime Constant Pool est utilisé pour :
4
— résoudre dynamiquement les références vers des méthodes ou des champs (linking) ;
— stocker les littéraux et les chaînes String utilisées dans le bytecode.
3.4 Caractéristiques de la Method Area / Metaspace
— Zone partagée par tous les threads ;
— Allouée et étendue dynamiquement lors du chargement des classes ;
— Peut provoquer une erreur :
— [Link]: Metaspace
si trop de classes sont chargées ou si la taille maximale du Metaspace est atteinte.
3.5 Exemple de fuite de Metaspace
Les fuites de Metaspace surviennent typiquement lorsque des classes sont chargées en
continu (par exemple via des class loaders dynamiques) et ne sont jamais déchargées.
— Serveur d’applications redéployant des applications sans redémarrer la JVM ;
— Génération dynamique de proxies ou de classes (par des frameworks de persistance
ou de mapping).
4 Heap Area
4.1 Définition
Le Heap est la zone mémoire principale utilisée pour l’allocation dynamique des ob-
jets et des tableaux Java. C’est la zone la plus volumineuse et la plus souvent au centre
des analyses de performances.
4.2 Fonctionnement
— Tous les objets créés par l’instruction new (ainsi que les tableaux) sont stockés
dans le Heap ;
— Le Heap est partagé entre tous les threads ;
— Il est géré automatiquement par le Garbage Collector (GC) :
— détection des objets inaccessibles ;
— libération de leur mémoire ;
— éventuellement compaction pour réduire la fragmentation.
4.3 Générations (Young / Old / Survivor)
Dans la plupart des implémentations modernes (HotSpot), le Heap est subdivisé en
générations :
— Young Generation :
— contient les objets « jeunes » (fraîchement alloués) ;
— subdivisée en Eden et deux Survivor Spaces (S0, S1) ;
— collectée fréquemment (Minor GC).
— Old (Tenured) Generation :
— contient les objets « survivants » qui ont vécu plusieurs cycles de GC ;
— collectée moins souvent (Major ou Full GC).
5
4.4 Impact sur les performances
Une mauvaise gestion du Heap peut entraîner :
— des pauses GC fréquentes (Heap trop petit, trop d’allocations) ;
— des pauses GC trop longues (Heap trop grand, GC inadapté) ;
— une [Link]: Java heap space lorsque la mémoire du Heap
est insuffisante et que le GC ne parvient plus à libérer de l’espace.
Exemple de message :
Exception in thread "main" [Link]: Java heap space
4.5 Tuning du Heap (aperçu)
— -Xms : taille initiale du Heap ;
— -Xmx : taille maximale du Heap ;
— paramètres avancés pour choisir l’algorithme de GC (G1, ZGC, Shenandoah, etc.).
5 Stack Area (Java Stack)
5.1 Pile d’exécution par thread
Chaque thread Java possède sa propre Java Stack. Il s’agit d’une pile LIFO (Last-In,
First-Out) où la JVM stocke l’état d’exécution des méthodes.
— À chaque appel de méthode, un nouveau stack frame est empilé ;
— À chaque retour de méthode, le frame est dépilé ;
— La pile n’est pas partagée entre les threads, ce qui favorise l’isolation et la per-
formance.
5.2 Structure d’une Stack Frame
Une stack frame contient :
— un tableau de variables locales (Local Variables Array) :
— paramètres de la méthode ;
— variables locales primitives (int, double, ...) ;
— références vers des objets du Heap.
— une Operand Stack :
— utilisée par le bytecode pour évaluer des expressions ;
— exécution de iadd, imul, invokevirtual, etc.
— une référence vers le Runtime Constant Pool de la classe de la méthode ;
— éventuellement des informations de débogage (numéro de ligne, etc.).
5.3 Exemple simple
1 public class ExempleStack {
2 public static void main ( String [] args ) {
3 int x = 10;
4 int y = carre ( x ) ;
5 System . out . println ( y ) ;
6 }
6
7
8 static int carre ( int n ) {
9 int r = n * n ;
10 return r ;
11 }
12 }
— Appel de main : création d’un frame pour main ;
— Appel de carre : création d’un frame pour carre, contenant n et r ;
— Retour de carre : frame dépilé, la valeur retournée est poussée sur la pile du frame
de main.
5.4 Erreurs liées à la Stack
Une récursion sans condition d’arrêt ou trop profonde peut provoquer :
[Link]
Exemple :
1 public class Recursion {
2 public static void rec () {
3 rec () ; // Appel r c u r s i f sans condition
4 }
5 public static void main ( String [] args ) {
6 rec () ;
7 }
8 }
Chaque appel crée un nouveau frame sur la Stack, jusqu’à dépasser la taille maximale
allouée à la pile de ce thread.
5.5 Caractéristiques
— Taille configurable via -Xss (Stack size) ;
— Accès aux variables locales très rapide ;
— Isolation entre threads, ce qui contribue à la sécurité mémoire.
6 PC Register (Program Counter)
6.1 Rôle
Chaque thread dispose de son propre Program Counter Register. C’est un petit
registre (ou emplacement mémoire) qui :
— indique l’adresse de l’instruction bytecode actuellement exécutée ;
— ou la prochaine instruction à exécuter dans le flux de bytecode.
6.2 Importance
— Permet à la JVM de reprendre l’exécution d’un thread exactement là où il s’était
arrêté, après un changement de contexte ;
7
— Participe au support du multitâche au-dessus du système d’exploitation ;
— Supporte la gestion des exceptions, des sauts conditionnels et des boucles.
6.3 Remarque
Pour les méthodes natives, la définition du PC Register est souvent « indéfinie » dans
la spécification, car l’exécution est alors déléguée au code natif du système.
7 Native Method Stack
7.1 Description
La Native Method Stack est utilisée pour l’exécution des méthodes natives, c’est-
à-dire des méthodes écrites dans un langage comme C ou C++ et appelées depuis Java
via le JNI (Java Native Interface).
1 public class NativeExample {
2 public native void doSomethingNative () ;
3 static {
4 System . loadLibrary ( " mylib " ) ;
5 }
6 }
7.2 Caractéristiques
— Chaque thread peut avoir sa propre pile native (similaire à la pile C classique) ;
— L’organisation interne dépend fortement :
— du système d’exploitation ;
— de l’ABI (Application Binary Interface) ;
— de l’implémentation de la JVM.
— Des erreurs telles que StackOverflowError peuvent également survenir dans ce
contexte si le code natif consomme trop de pile.
7.3 Lien avec la sécurité
Le recours aux méthodes natives :
— permet d’accéder à des fonctionnalités bas niveau (drivers, système de fichiers
spécifique, bibliothèques optimisées) ;
— mais contourne en partie la sécurité et le modèle de mémoire gérés par la JVM.
8 Erreurs Mémoire Courantes
8.1 StackOverflowError
Cause typique Récursion excessive ou boucle d’appels mutuels entre méthodes qui ne
se termine jamais.
8
Symptômes
— Trace de pile très longue ;
— Répétition cyclique des mêmes méthodes dans le stack trace.
8.2 OutOfMemoryError: Java heap space
Causes possibles
— Allocation d’objets volumineux ou trop nombreux ;
— « Fuite de mémoire » logique : références conservées alors qu’elles ne sont plus utiles
(collections jamais vidées, caches non bornés, etc.) ;
— Heap trop petit par rapport aux besoins de l’application.
Pistes de résolution
— Augmenter -Xmx (taille max du Heap) ;
— Analyser le Heap avec un profiler (VisualVM, Eclipse MAT, etc.) ;
— Réduire les allocations et corriger les fuites logiques.
8.3 OutOfMemoryError: Metaspace
Causes possibles
— Chargement dynamique et répété de classes sans déchargement (applications ser-
veurs, OSGi, etc.) ;
— Mauvaise gestion des ClassLoader par les frameworks ou le code applicatif.
Pistes de résolution
— Limiter le nombre de classes chargées (réduire le reload inutile) ;
— Utiliser des outils de diagnostic spécifiques (JFR, JMC) ;
— Augmenter la taille maximale du Metaspace via -XX:MaxMetaspaceSize.
9 Lien entre Modèle de Mémoire et Concurrence (Aperçu)
9.1 Partage du Heap
Le Heap étant partagé :
— plusieurs threads peuvent accéder simultanément aux mêmes objets ;
— il est nécessaire de synchroniser les accès (mots-clés synchronized, volatile, API
[Link]) ;
— le Java Memory Model (JMM) définit précisément les garanties de visibilité et
d’ordre.
9.2 Isolation des Stacks
Les variables locales stockées dans la Stack d’un thread ne sont jamais visibles pour
un autre thread, sauf si elles sont utilisées pour créer des objets dans le Heap qui seront
partagés.
9
9.3 Effets sur le Garbage Collector
— Les threads d’application et les threads du GC coexistent ;
— Des pauses peuvent affecter la latence (stop-the-world) ;
— Les GC modernes essaient de réduire ces pauses (G1, ZGC, Shenandoah).
10 Résumé et Conclusion
10.1 Résumé des zones mémoire
— Heap : objets et tableaux, partagé, géré par GC ;
— Method Area / Metaspace : métadonnées des classes, Constant Pool, bytecode ;
— Java Stack : frames de méthodes, variables locales, operand stack, par thread ;
— PC Register : adresse de l’instruction en cours pour chaque thread ;
— Native Method Stack : pile utilisée lors des appels natifs (JNI).
10.2 Importance pour l’ingénieur Java
La compréhension de l’architecture mémoire de la JVM est un prérequis pour :
— analyser les problèmes de performance et de consommation mémoire ;
— concevoir des applications fiables, scalables et tolérantes aux pannes ;
— maîtriser les interactions entre mémoire, concurrence et Garbage Collector.
Références et Ressources Complémentaires
— Oracle, Java Virtual Machine Specification, [Link]
specs/ ;
— Oracle, Java Platform, Standard Edition HotSpot Virtual Machine Garbage Col-
lection Tuning Guide ;
— J. Bloch, Effective Java, 3e édition ;
— B. Goetz et al., Java Concurrency in Practice ;
— A. Tanenbaum, Structured Computer Organization.
10