Java Stack vs. Heap-Speicher | W3Docs Learn Java

Zur Laufzeit teilt die JVM den verwalteten Speicher in zwei Bereiche mit sehr unterschiedlichen Aufgaben auf. Der Stack enthält die Verwaltungsdaten für Methodenaufrufe — einen Frame pro Aufruf, mit den lokalen Variablen und primitiven Werten der Methode. Der Heap enthält jedes Objekt, das Sie mit new erstellen, wird vom gesamten Programm gemeinsam genutzt und vom Garbage Collector freigegeben. Fast jedes verwirrende Java-Verhalten — warum eine Methode Ihren int „nicht ändern kann", warum zwei Variablen dieselbe Bearbeitung „sehen", warum tiefe Rekursion zum Absturz führt — resultiert direkt aus dieser Aufteilung.

Dieses Kapitel behandelt, was in jedem Bereich gespeichert wird, wie sich ihre Lebenszyklen unterscheiden, warum Javas Pass-by-Value-Regel direkt aus der Aufteilung folgt, den Sonderfall des String-Pools und was passiert, wenn einer der Bereiche erschöpft ist. Für das größere Bild, wie diese Bereiche in die Laufzeit passen, siehe JVM-Architektur und das Java Memory Model.

Zwei Bereiche, zwei Lebenszyklen

Der Stack ist thread-spezifisch und automatisch: Wenn eine Methode aufgerufen wird, legt die JVM einen Frame an, und wenn die Methode zurückkehrt, wird dieser Frame entfernt und seine lokalen Variablen verschwinden sofort. Der Heap ist gemeinsam genutzt und verwaltet: Objekte leben, bis keine Referenz mehr auf sie zeigt, wonach der Garbage Collector den Speicher freigeben kann. Nichts auf dem Heap verschwindet in dem Moment, in dem eine Methode zurückkehrt.

Aspekt	Stack	Heap
Enthält	Frames: lokale Variablen, Primitive, Referenzen	Objekte, arrays, Instanzfelder
Geltungsbereich	Einer pro Thread	Einer, geteilt von der gesamten JVM
Lebensdauer	Frame wird bei Methodenrückkehr entfernt	Bis unerreichbar, dann GC
Allokation	Push/Pop, extrem schnell	`new`, verwaltet durch den Allokator
Größe	Begrenzt (`-Xss`); Überlauf wirft `StackOverflowError`	Begrenzt (`-Xmx`); Erschöpfung wirft `OutOfMemoryError`
Bereinigung	Automatisch, deterministisch	Garbage Collector, nicht-deterministisch

Was tatsächlich wo gespeichert ist

Eine lokale Variable lebt immer im aktuellen Stack-Frame. Was sie enthält, hängt von ihrem Typ ab. Bei einem Primitiv enthält der Frame den Wert selbst. Bei einem Objekttyp enthält der Frame nur eine Referenz — das Objekt, auf das sie zeigt, lebt auf dem 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

Instanzfelder sind Teil des Objekts und leben daher zusammen mit ihm auf dem Heap — auch ein Feld eines primitiven Typs. Ein private int balance innerhalb eines Account-Objekts ist Heap-Speicher, kein Stack-Speicher, weil es zum Objekt gehört, nicht zu einem einzelnen Methodenaufruf.

Java ist immer Pass-by-Value

Java kopiert das Argument bei jedem Aufruf in den Parameter. Bei einem Primitiv kopiert es den Wert; bei einem Objekt kopiert es die Referenz. Es gibt kein Pass-by-Reference in Java, und diese eine Regel (weiter untersucht in Methodenparameter) erklärt die drei klassischen Überraschungen:

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 kann den Aufrufer nicht beeinflussen: Es empfing eine Kopie der Zahl. mutate kann das ändern, was der Aufrufer sieht, weil die kopierte Referenz immer noch auf das Objekt des Aufrufers auf dem Heap zeigt. rebind kann das nicht, weil das Neuzuweisen des Parameters nur die lokale Kopie der Referenz umleitet, nicht die Variable des Aufrufers.

Der String-Pool, ein Heap-Sonderfall

String-Literale werden interniert: identische Literale teilen sich ein Objekt im String-Pool, sodass == (Referenzidentität) für sie true zurückgibt. Das Schreiben von new String("hi") erzwingt ein separates Heap-Objekt, sodass == false zurückgibt, obwohl die Zeichen übereinstimmen. Deshalb vergleichen Sie Strings mit .equals(), das den Inhalt prüft, nicht die Identität.

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

Wenn die Bereiche erschöpft sind

Jeder Bereich hat eine Grenze und seinen eigenen Fehlermodus. Unbegrenzte Rekursion legt immer mehr Frames an, bis der Stack erschöpft ist und StackOverflowError ausgelöst wird. Objekte schneller zu allozieren, als der GC sie freigeben kann, erschöpft den Heap und löst OutOfMemoryError aus. Beide sind Errors, keine Exceptions — Zeichen eines strukturellen Problems (ein fehlender Basisfall, ein Leak) und nicht etwas, das routinemäßig abgefangen werden sollte.

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

Ein Arbeitsbeispiel: Die zwei Bereiche in Aktion

Dieses Programm berührt in einem Durchlauf alle oben genannten Regeln: ein Primitiv, das per Wert übergeben wird, zwei Referenzen auf ein Heap-Objekt, eine Mutation, die der Aufrufer sieht, eine Neuzuweisung, die er nicht sieht, den String-Pool, einen absichtlichen Stack-Overflow und das Fallen-Lassen der letzten Referenz auf ein Objekt.

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");
  }
}

Was man aus dem Durchlauf mitnehmen kann:

score bleibt 10, während das n der Methode 110 erreicht. Das Primitiv wurde in den neuen Frame kopiert, sodass nichts, was die Methode tat, zurück in main reichen konnte — das ist Pass-by-Value für Primitive, sichtbar gemacht.
a.value und b.value sind beide 42 und a == b ist true, weil Counter b = a eine Referenz kopiert hat, nicht das Objekt. Eine Heap-Instanz, zwei Stack-Variablen, die darauf zeigen — über eine davon bearbeiten und beide „sehen" es.
Nach mutateThroughReference(a) ist a.value 999. Die Methode erhielt eine Kopie der Referenz, aber die Kopie zeigte noch auf dasselbe Heap-Objekt, sodass die Feldänderung für den Aufrufer sichtbar ist.
Nach reassignReference(a) ist a.value immer noch 999, nicht -1. Das Neuzuweisen des Parameters hat nur die lokale Kopie der Referenz der Methode umgeleitet; das a des Aufrufers wurde nie bewegt. Das Mutieren des Objekts funktioniert; das Neubinden der Variable nicht.
lit1 == lit2 ist true, aber lit1 == obj ist false, während .equals für beide true ist. Gepoolte Literale teilen sich ein Heap-Objekt; new String erzwingt ein separates. Der erreichbare, aber überlebbare StackOverflowError und das abschließende temp = null zeigen die Grenzen der beiden Bereiche und wie der Heap sammelbar wird, wenn seine letzte Referenz fällt.

Übungen

Übung

Eine Methode erhält einen Parameter vom Typ StringBuilder. Innerhalb der Methode rufen Sie sb.append('x') auf. Nach der Rückkehr der Methode zeigt das StringBuilder-Objekt des Aufrufers das angehängte 'x'. Warum?

Die Referenz wurde per Wert kopiert, aber die Kopie zeigt noch auf dasselbe Heap-Objekt, sodass die Mutation dieses Objekts für den Aufrufer sichtbar istJava übergibt Objekte per Referenz, sodass der Parameter und die Variable des Aufrufers dieselbe Variable sindStringBuilder wird auf dem Stack gespeichert, und Stack-Werte werden über Frames hinweg geteiltDas Append hat ein neues Objekt erstellt, das Java automatisch in die Variable des Aufrufers zurückkopiert hat