Speicher und Garbage Collector in Java: Was wirklich unter der Haube passiert

Wie Java den Speicher verwaltet: Nicht nur „Müllabfuhr“

Viele Entwickler, die von C++ oder Python zu Java wechseln, freuen sich zunächst: „Hurra, ich muss nicht über Speicherlecks nachdenken!“. Und dann bekommen sie zur ungünstigsten Zeit einen OutOfMemoryError und verstehen – die Speicherverwaltung in Java erfordert ein tiefes Verständnis. Heute werfen wir einen Blick unter die Haube der JVM und analysieren, wie Speicher und Garbage Collector in Java tatsächlich funktionieren.

Dieser Artikel wird sowohl für Anfänger nützlich sein, die das Java Memory Model verstehen wollen, als auch für erfahrene Entwickler, die nach Optimierungsmöglichkeiten für die Garbage Collection Java suchen. Los geht's!

Wie der Speicher in Java aufgebaut ist: Heap, Stack und Metaspace

Bevor wir über den Java Garbage Collector sprechen, müssen wir verstehen, wo genau Ihre Objekte „leben“. Die JVM teilt den Speicher in mehrere Schlüsselbereiche auf:

\n
• Heap (Halde) – hier werden alle erstellten Objekte gespeichert. Dies ist das Hauptarbeitsfeld der Garbage Collection Java.
\n
• Stack (Stapel) – speichert primitive Typen und Referenzen auf Objekte im Heap. Jeder Thread hat seinen eigenen Stack.
\n
• Metaspace – hat PermGen in Java 8 ersetzt, speichert Metadaten von Klassen.
\n
• Code Cache – vom JIT-Compiler kompilierter Code.
\n

Hier ist ein einfaches Beispiel, das zeigt, wohin die Daten gelangen:

public class MemoryDemo {\n    public static void main(String[] args) {\n        int number = 42;                    // Primitiv – im Stack\n        String text = "Hello";              // Referenz im Stack, Objekt im Heap\n        List<String> list = new ArrayList<>(); // Referenz im Stack, Liste im Heap\n        list.add("Java");                   // String "Java" – ebenfalls im Heap\n    }\n}\n

Der entscheidende Punkt: Alle Objekte, die mit new erstellt werden, landen im Java Heap. Genau diesen Bereich „überwacht“ der Garbage Collector in Java.

Warum der Garbage Collector kein Feind, sondern ein Freund ist (wenn man seine Logik versteht)

Viele Entwickler fürchten den Java GC wegen der „Stop-The-World“-Pausen. Aber sehen wir der Wahrheit ins Auge: Ohne automatische Java Speicherverwaltung müssten wir manuell free() schreiben und Segfaults einfangen. Der Java Garbage Collector ist kein böser Dämon, sondern ein komplexer, intelligenter Mechanismus.

Die grundlegenden Prinzipien der Garbage Collection Java:

\n
• Ein Objekt gilt als „Müll“, wenn es keine aktiven Referenzen vom Stack oder aus statischen Feldern gibt.
\n
• Der GC kann ein Objekt nicht löschen, auf das noch eine Referenz existiert (selbst wenn Sie sie vergessen haben).
\n
• Verschiedene GC-Algorithmen haben unterschiedliche Ziele: minimale Pausen, maximaler Durchsatz oder Speichereffizienz.
\n

Hier ist ein klassisches Beispiel für ein Speicherleck, bei dem ein Objekt „vergessen“ wird, aus einer Sammlung zu entfernen:

public class LeakExample {\n    private static List<byte[]> cache = new ArrayList<>();\n\n    public static void addToCache() {\n        byte[] data = new byte[1024 * 1024]; // 1 MB\n        cache.add(data); // Referenz bleibt – GC rührt es nicht an\n    }\n\n    public static void main(String[] args) {\n        for (int i = 0; i < 1000; i++) {\n            addToCache();\n        }\n        // Hier wird ein OutOfMemoryError auftreten, obwohl die Objekte nicht mehr benötigt werden\n    }\n}\n

Fazit: Der Speicher in Java wird nicht freigegeben, solange Sie eine Referenz halten. Dies zu verstehen, ist der erste Schritt zum Schreiben effizienten Codes.

Arten von Garbage Collectors in Java: Von Serial bis ZGC

Modernes Java bietet mehrere Implementierungen der Garbage Collection Java. Die Wahl hängt von Ihren Anforderungen ab:

1. Serial GC – für kleine Anwendungen

Ein Single-Thread-Collector, der die gesamte Anwendung „einfriert“. Wird standardmäßig