OutOfMemoryError in Java: Heap, Metaspace und was der Dump verrät

Ursache

Ein Leck im klassischen Sinn: Objekte bleiben erreichbar, obwohl sie fachlich nicht mehr gebraucht werden. Der Sammler kann sie deshalb nicht entfernen. Typische Quellen sind statische Sammlungen, die nur wachsen, Caches ohne Verdrängung, Listener und Callbacks, die nie abgemeldet werden, und Objekte, die in einer ThreadLocal-Variablen liegen, während der Thread aus einem Vorrat stammt und ewig lebt.

Lösung

In den Protokollen des Garbage Collectors prüfen, ob der belegte Speicher nach jeder vollständigen Sammlung wieder auf denselben Wert zurückfällt oder ob der Boden ansteigt. Steigt er, den Heap-Dump im Memory Analyzer öffnen und über den Dominatorbaum gehen: Er zeigt, welche wenigen Objekte den Großteil des Speichers festhalten. Von dort führt der Pfad zur Wurzel meist in wenigen Schritten zur verantwortlichen Stelle im Code. Eine Erhöhung der Heap-Größe verschiebt hier nur den Termin.

Ursache

Keine dauerhaft wachsende Struktur, sondern eine einzelne Operation, die kurzfristig sehr viel belegt. Häufige Auslöser sind eine Datenbankabfrage ohne Begrenzung der Ergebnismenge, das vollständige Einlesen einer hochgeladenen Datei in den Speicher, das Zusammenbauen einer großen Antwort als Zeichenkette und Serialisierungsvorgänge, die eine tiefe Objektstruktur vollständig aufbauen.

Lösung

Im Heap-Dump nach dem größten einzelnen Objektbaum suchen, nicht nach der Summe vieler kleiner. Meist steht dort ein Feld oder eine Liste mit sehr vielen Einträgen, und der Stacktrace des Threads, der den Fehler ausgelöst hat, zeigt die Operation. Die Lösung liegt im Code und nicht in der Konfiguration: Ergebnismengen begrenzen, im Datenstrom verarbeiten statt vollständig zu laden und Obergrenzen für Nutzlasten setzen.

Ursache

Im Metaspace liegen die Metadaten der geladenen Klassen. Er wächst, wenn Klassen geladen, aber ihre Klassenlader nicht freigegeben werden. Der klassische Fall ist das wiederholte Ausrollen einer Anwendung in einen laufenden Application Server: Jede Auslieferung bringt einen neuen Klassenlader mit, und wenn irgendetwas noch eine Referenz darauf hält, kann keiner davon abgeräumt werden. Die zweite Quelle sind Bibliotheken, die zur Laufzeit Klassen erzeugen, etwa für dynamische Proxies, Ausdrucksauswertung oder Objektabbildung.

Lösung

Prüfen, wie viele Klassenlader im Dump vorhanden sind, denn der Memory Analyzer zeigt sie als eigene Gruppe. Sind es mehrere Generationen derselben Anwendung, ist die Ursache das Ausrollen im laufenden Betrieb, und der Ausweg ist der Neustart des Prozesses bei jeder Auslieferung, was im Container ohnehin der Normalfall ist. Wachsen dagegen erzeugte Klassen einer Bibliothek, gehört die Zwischenspeicherung dieser Bibliothek überprüft. Eine Obergrenze für den Metaspace zu setzen, ist sinnvoll, um den Fehler früh und mit Dump statt spät und als Container-Abbruch zu bekommen.

Ursache

Hier ist nicht der Heap ausgegangen, sondern die Möglichkeit, einen weiteren Betriebssystem-Thread anzulegen. Entweder ist eine Grenze des Betriebssystems erreicht, etwa die zulässige Anzahl an Prozessen oder Threads für den Benutzer, oder der Speicher außerhalb des Heaps reicht nicht mehr, weil jeder Thread einen eigenen Stack belegt. Die häufigste Ursache im Code ist ein Thread-Pool ohne Obergrenze oder eine Stelle, an der pro Anfrage ein neuer Thread entsteht und nie endet.

Lösung

Zuerst die Anzahl der Threads im laufenden Prozess ermitteln und die Grenzen des Betriebssystems dagegen halten. Steigt die Zahl dauerhaft, ist es kein Kapazitätsproblem, sondern ein Leck: Ein Thread-Dump zeigt die Gruppen mit gleichlautenden Namen, und daraus lässt sich die erzeugende Stelle ablesen. Ist die Zahl stabil und schlicht hoch, hilft entweder eine kleinere Stackgröße pro Thread oder ein Umbau auf einen begrenzten Vorrat. Bei blockierenden Aufrufen sind Virtual Threads ab Java 21 die strukturelle Antwort, weil sie keinen Betriebssystem-Thread belegen, solange sie warten.

Ursache

Direktpuffer liegen außerhalb des Heaps und werden erst freigegeben, wenn das zugehörige Java-Objekt eingesammelt wurde. Wird auf dem Heap wenig Druck erzeugt, läuft der Sammler selten, und die Puffer stauen sich an, obwohl im Heap reichlich Platz ist. Verstärkt wird das durch Netzwerkbibliotheken, die eigene Puffervorräte verwalten, und durch eine Obergrenze für Direktpuffer, die niemand bewusst gesetzt hat.

Lösung

Die Obergrenze für Direktpuffer ausdrücklich setzen, damit der Fehler früh und benannt auftritt, statt den Container zu sprengen. Danach mit Native Memory Tracking prüfen, wie groß der Anteil außerhalb des Heaps tatsächlich ist. Im Code sind zwei Dinge zu prüfen: ob Puffer aus einem Vorrat wieder zurückgegeben werden und ob Ressourcen wie Kanäle und Ströme zuverlässig geschlossen werden. Bei Netzwerkbibliotheken mit eigenem Puffervorrat lohnt sich deren Leckerkennung im Testbetrieb.

Ursache

Das ist kein Java-Fehler, sondern das Betriebssystem: Die Summe aus Heap, Metaspace, Code-Zwischenspeicher, Thread-Stacks, Direktpuffern, Verwaltungsstrukturen des Sammlers und nativen Bibliotheken hat die Speichergrenze des Containers überschritten. Die virtuelle Maschine bekommt davon nichts mit, deshalb gibt es weder Meldung noch Heap-Dump. Häufigste Konstellation: Die maximale Heap-Größe wurde von Hand auf einen Wert nahe der Containergrenze gesetzt, ohne Luft für alles andere.

Lösung

Erst prüfen, ob es wirklich ein Abbruch durch das Betriebssystem war, denn der Beendigungscode des Containers und die Ereignisse eurer Plattform zeigen das an. Danach die Heap-Größe über die prozentualen Optionen statt über einen festen Wert setzen und den Rest der Grenze als Reserve behandeln. Wie viel Reserve nötig ist, sagt Native Memory Tracking. Und richtet die Überwachung so ein, dass sie den gesamten Speicherbedarf des Prozesses zeigt und nicht nur den Heap, sonst sieht die Kurve bis zum Abbruch unauffällig aus.