Java Stack vs. Heap Memory | W3Docs Learn Java

Au moment de l'exécution, la JVM divise la mémoire qu'elle gère en deux régions aux rôles très différents. La stack conserve le suivi des appels de méthodes — un frame par appel, contenant les variables locales et les valeurs primitives de la méthode. Le heap contient chaque objet créé avec new, partagé par l'ensemble du programme et récupéré par le ramasse-miettes. Presque tous les comportements Java déroutants — pourquoi une méthode « ne peut pas modifier » votre int, pourquoi deux variables « voient » la même modification, pourquoi une récursion profonde provoque un crash — découlent directement de cette séparation.

Ce chapitre couvre ce qui réside dans chaque région, comment leurs cycles de vie diffèrent, pourquoi la règle du passage par valeur de Java découle directement de cette séparation, le cas particulier du pool de chaînes, et ce qui se passe quand l'une ou l'autre région vient à manquer. Pour une vue d'ensemble de la façon dont ces régions s'insèrent dans l'environnement d'exécution, consultez Architecture JVM et le modèle mémoire Java.

Deux régions, deux cycles de vie

La stack est par thread et automatique : quand une méthode est appelée, la JVM pousse un frame, et quand la méthode retourne, ce frame est dépilé et ses variables locales disparaissent instantanément. Le heap est partagé et géré : les objets vivent jusqu'à ce qu'aucune référence ne pointe vers eux, après quoi le ramasse-miettes est libre de récupérer l'espace. Rien sur le heap ne disparaît au moment où une méthode retourne.

Aspect	Stack	Heap
Contient	Frames : variables locales, primitives, références	Objets, tableaux, champs d'instance
Portée	Un par thread	Un partagé par toute la JVM
Durée de vie	Frame dépilé au retour de la méthode	Jusqu'à inaccessibilité, puis GC
Allocation	Push/pop, extrêmement rapide	`new`, géré par l'allocateur
Taille	Limitée (`-Xss`) ; le dépassement lève `StackOverflowError`	Limitée (`-Xmx`) ; l'épuisement lève `OutOfMemoryError`
Nettoyage	Automatique, déterministe	Ramasse-miettes, non déterministe

Ce qui se trouve réellement où

Une variable locale réside toujours dans le frame de pile courant. Ce qu'elle contient dépend de son type. Pour une primitive, le frame contient la valeur elle-même. Pour un type objet, le frame ne contient qu'une référence — l'objet vers lequel elle pointe réside sur le heap.

void example() {
  int count = 5;                 // the value 5 sits in the frame (stack)
  double rate = 0.5;             // likewise on the stack
  int[] data = new int[3];       // 'data' (a reference) is on the stack,
                                 // the 3-element array is on the heap
  Point p = new Point(1, 2);     // 'p' is on the stack, the Point is on the heap
}                                // frame popped: count, rate, data, p all gone;
                                 // the array and Point survive until GC

Les champs d'instance font partie de l'objet, ils résident donc sur le heap avec lui — même un champ de type primitif. Un private int balance à l'intérieur d'un objet Account est de la mémoire heap, pas de la mémoire stack, parce qu'il appartient à l'objet, et non à un appel de méthode particulier.

Java est passage par valeur — toujours

Java copie l'argument dans le paramètre à chaque appel. Pour une primitive, il copie la valeur ; pour un objet, il copie la référence. Il n'y a pas de passage par référence en Java, et cette règle unique (explorée plus en détail dans Paramètres de méthode) explique les trois surprises classiques :

static void bumpPrimitive(int n) { n++; }          // changes the copy only

static void mutate(StringBuilder sb) { sb.append("!"); }  // edits shared object

static void rebind(StringBuilder sb) {             // points the copy elsewhere
  sb = new StringBuilder("new");                   // caller's variable unchanged
}

bumpPrimitive ne peut pas affecter l'appelant : il a reçu une copie du nombre. mutate peut modifier ce que voit l'appelant, car la référence copiée pointe toujours vers l'objet de l'appelant sur le heap. rebind ne le peut pas, car réassigner le paramètre ne modifie que la copie locale de la référence, pas la variable de l'appelant.

Le pool de chaînes, un cas particulier du heap

Les littéraux String sont internés : des littéraux identiques partagent un seul objet dans le pool de chaînes, donc == (identité de référence) renvoie true pour eux. Écrire new String("hi") force la création d'un objet heap distinct, donc == renvoie false même si les caractères correspondent. C'est pourquoi vous comparez les chaînes avec .equals(), qui vérifie le contenu, pas l'identité.

String a = "hi";
String b = "hi";
String c = new String("hi");
a == b;        // true  — both point at the pooled literal
a == c;        // false — c is a distinct heap object
a.equals(c);   // true  — same characters

Quand les régions viennent à manquer

Chaque région a une limite et son propre mode d'échec. Une récursion non bornée continue d'empiler des frames jusqu'à l'épuisement de la stack, levant StackOverflowError. Allouer des objets plus vite que le GC peut les récupérer épuise le heap, levant OutOfMemoryError. Les deux sont des Errors, pas des Exceptions — signes d'un problème structurel (un cas de base manquant, une fuite) plutôt que quelque chose à intercepter en routine.

static int countDown(int n) {
  return countDown(n - 1);   // no base case -> StackOverflowError
}

Un exemple concret : observer les deux régions en action

Ce programme illustre toutes les règles ci-dessus en une seule exécution : une primitive passée par valeur, deux références vers un même objet heap, une mutation que l'appelant voit, une réassignation qu'il ne voit pas, le pool de chaînes, un dépassement de pile délibéré, et l'abandon de la dernière référence vers un objet.

java— editable, runs on the server

public class StackVsHeapDemo {

// An object on the heap. Two references can point at the SAME instance.
  static class Counter {
    int value;
  }

// Primitive parameter is COPIED (pass-by-value): caller is unaffected.
  static int tryToChangePrimitive(int n) {
    n = n + 100;        // mutates only this frame's copy
    return n;           // returned so main controls print order
  }

// The REFERENCE is copied, but it points at the same heap object,
  // so a mutation through it is visible to the caller.
  static void mutateThroughReference(Counter c) {
    c.value = 999;
  }

// Reassigning the local reference does NOT affect the caller's reference.
  static void reassignReference(Counter c) {
    c = new Counter();
    c.value = -1;
  }

// Unbounded recursion overflows the per-thread stack.
  static int deepen(int depth) {
    return deepen(depth + 1);
  }

public static void main(String[] args) {
    // 1. Primitives live in the stack frame; passing one copies the value.
    int score = 10;
    int inside = tryToChangePrimitive(score);
    System.out.println("inside the method, n = " + inside);
    System.out.println("back in caller, score = " + score);

// 2. Objects live on the heap; variables hold references to them.
    Counter a = new Counter();
    a.value = 1;
    Counter b = a;                 // b and a reference the SAME object
    b.value = 42;
    System.out.println("a.value = " + a.value + ", b.value = " + b.value);
    System.out.println("a == b (same reference)? " + (a == b));

// 3. Mutating through a passed reference is visible to the caller.
    mutateThroughReference(a);
    System.out.println("after mutateThroughReference, a.value = " + a.value);

// 4. Reassigning the parameter does not rebind the caller's variable.
    reassignReference(a);
    System.out.println("after reassignReference, a.value = " + a.value);

// 5. Identical strings: literals are pooled, 'new' forces a heap copy.
    String lit1 = "hi";
    String lit2 = "hi";
    String obj = new String("hi");
    System.out.println("lit1 == lit2 (pooled)?   " + (lit1 == lit2));
    System.out.println("lit1 == obj  (new heap)? " + (lit1 == obj));
    System.out.println("lit1.equals(obj)?        " + lit1.equals(obj));

// 6. Each thread has its own stack; overflow it and the JVM tells you.
    try {
      deepen(0);
    } catch (StackOverflowError e) {
      System.out.println("caught StackOverflowError (the stack is finite)");
    }

// 7. When no reference remains, the heap object is eligible for GC.
    Counter temp = new Counter();
    temp = null;  // the previous object is now unreachable -> collectable
    System.out.println("temp set to null; old object now eligible for GC");
  }
}

Ce qu'il faut retenir de l'exécution :

score reste 10 tandis que le n de la méthode atteint 110. La primitive a été copiée dans le nouveau frame, donc rien de ce que la méthode a fait ne pouvait atteindre main — c'est le passage par valeur pour les primitives, rendu visible.
a.value et b.value valent tous les deux 42 et a == b est true, car Counter b = a a copié une référence, pas l'objet. Une seule instance sur le heap, deux variables de pile pointant dessus — modifiez via l'une et les deux « voient » la modification.
Après mutateThroughReference(a), a.value vaut 999. La méthode a reçu une copie de la référence, mais la copie pointait toujours vers le même objet heap, donc la modification du champ est visible par l'appelant.
Après reassignReference(a), a.value vaut toujours 999, pas -1. Réassigner le paramètre n'a modifié que la copie locale de la référence dans la méthode ; le a de l'appelant n'a jamais bougé. Muter l'objet fonctionne ; rebinder la variable ne fonctionne pas.
lit1 == lit2 est true mais lit1 == obj est false, tandis que .equals est true pour les deux. Les littéraux dans le pool partagent un seul objet heap ; new String en force un distinct. Le StackOverflowError attrapé-mais-survivable et le temp = null final illustrent les limites des deux régions et comment le heap devient récupérable quand sa dernière référence disparaît.

Exercices pratiques

Pratique

Une méthode reçoit un paramètre de type StringBuilder. À l'intérieur de la méthode, vous appelez sb.append('x'). Après le retour de la méthode, le StringBuilder de l'appelant affiche le 'x' ajouté. Pourquoi ?

La référence a été copiée par valeur, mais la copie pointe toujours vers le même objet heap, donc muter cet objet est visible par l'appelantJava passe les objets par référence, donc le paramètre et la variable de l'appelant sont la même variableStringBuilder est stocké sur la stack, et les valeurs de la stack sont partagées entre les framesL'append a créé un nouvel objet que Java a automatiquement recopié dans la variable de l'appelant

Chapitres associés

Architecture JVM — où la stack et le heap se situent dans l'environnement d'exécution.
Modèle mémoire Java — comment la mémoire se comporte entre les threads.
Ramasse-miettes — comment les objets heap inaccessibles sont récupérés.
Paramètres de méthode — le passage par valeur en profondeur.
Références — comment les variables pointent vers les objets heap.
Le pool de chaînes — pourquoi les littéraux identiques partagent un seul objet.