Ein Service startet alle paar Tage mit einem OutOfMemoryError neu. Wie findest du die Ursache?

Lies zuerst die Meldung, denn Heap Space, Metaspace, Direct Buffer und GC Overhead Limit Exceeded zeigen auf sehr unterschiedliche Ursachen. Lass den Prozess mit Heap Dump on Out of Memory laufen, damit du den Zustand beim Fehler festhältst, öffne den Dump dann in einem Memory Analyzer und schau in den Dominator Tree, um zu sehen, was am meisten hält. Vergleich Dumps über die Zeit, um ein echtes Leak von einem Working Set zu trennen, das schlicht größer ist als der Heap.

Die Variante zählt. Java Heap Space heißt, lebende Objekte füllen den Heap wirklich, Metaspace heißt, Klassen werden geladen und nie freigegeben, und ein Direct-Buffer-Fehler zeigt auf NIO oder eine native Bibliothek statt auf meine Objekte. Das lese ich also zuerst und stelle dann sicher, dass die JVM mit Heap Dump on Out of Memory läuft, mit einem Pfad auf einem Volume, das den Neustart überlebt, denn Raten ohne Dump kostet Tage. Mit dem Dump schaue ich auf Retained statt Shallow Size, und der Dominator Tree nennt mir den Übeltäter meist in ein paar Minuten. Was ich tatsächlich finde, wiederholt sich: eine Map als Cache ohne Eviction, ein Thread Local, das auf einem gepoolten Thread gesetzt und nie geleert wurde und deshalb so lange lebt wie der Pool, oder eine Repository-Methode, die jede Zeile liefert, weil jemand die Pagination rausgeworfen hat. Ich schaue außerdem in die Garbage-Collection-Logs, um zu sehen, ob der Heap stetig gestiegen ist oder bei bestimmten Requests Spitzen hatte. Der Fix ist, etwas zu begrenzen, ein Cache mit Maximalgröße und Ablauf oder eine gestreamte Query, und dann beobachte ich das Live Set über eine Woche, um zu bestätigen, dass es flach ist.