codecentric
 

Java Memory Leak

In Java ist die Garbage Collection wichtiger Bestandteil der automatischen Speicherverwaltung. Anstelle vom Betriebssystem Speicherbereiche zu allokieren, können Entwickler Objekte direkt auf dem JVM Heap anlegen. Dieser Heap wird von der JVM vom Betriebssystem angefordert und selbsttätig verwaltet. Wenn Objekte nicht mehr benötigt werden wird Speicher frei gegeben. Die Erkennung von nicht mehr benötigten, bzw. besser: nicht mehr referenzierten Objekten, übernimmt die Garbage Collection, welche auch für diverse Wartungsarbeiten im JVM Heap zuständig ist.

OutOfMemoryError

Einen OutOfMemoryError gibt es immer dann, wenn trotz der Garbage Collection keine Objekte mehr entfernt werden können. Häufige Ursache dafür ist ein Java Memory Leak.

Ausfühliche Informationen zum Thema Java Memory Leak gibt es in unserem Blog in der OutOfMemoryError Tragödie:

  1. 1. Akt – Das Java Memory Architektur – Architektur und Aufbau des Speichers innerhalb einer JVM im Detail und wann und wo java.lang.OutOfMemoryError auftreten können.
  2. 2. Akt – Java Memory Leaks und andere Übeltäter – Ursachen von java.lang.OutOfMemoryError – insbesondere Java Memory Leaks und zu hoher Speicherverbrauch in Java Anwendungen.
  3. 3. Akt – Konfiguration und Überwachung der Java Virtual Maschine – Parameter zur Konfiguration des Speichers einer JVM und Werkzeuge um den Speicher zu überwachen.
  4. 4. Akt – Java Heapdumps erzeugen und verstehen – Werkzeuge zur Erstellung von Heapdumps und Auswertung, sowie Details zu den typischen Objekten und Strukturen des Heaps.
  5. 5. Akt – Java Memory Leaks zur Laufzeit aufspüren – Verfahren zur Identifikation von Memory Leaks ohne Heap Dumps, welche auch langsam wachsende Speicherlecks finden können.
  6. 5. Akt – Nachtrag – Memory Leaks mit Plumbr beheben – Tutorial über die Memory Leak Suche mit plumbr.

 

Garbage Collector Konfiguration

Die Konfiguration des Garbage Collectors ist vielfältig. Garbage Collection benötigt immer sogenannte “Stop-The-World”-Pausen. Also Zeiten, in denen kein Java Code ausgeführt werden kann.
Um diese Zeiten so kurz wie möglich zu halten, versuchen verschiedene Verfahren gewisse Aktivitäten nebenläufig zu erledigen. Weitere Möglichkeiten sind in dieser Pause möglichst effizient und mit allen verfügbaren Prozessoren zu agieren.
Bis der G1 getaufte neue Garbage Collector mit Java 7 seine Verbreitung erfährt, bleibt der Concurrent Mark Sweep Collector der wohl am meisten eingesetzte.
Im JavaMagazin August 2009 erläuterte Mirko Novakovic einige Grundlagen. Der Artikel über den “Garbage Collector, das unbekannte Wesen” kann online gelesen werden.