Java heap space error trotz -Xmx512m

[feng]

Hallo,
ich habe da eine Frage bezüglich der Fehlermeldung:

Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space

Ich habe 2 GB Ram in meinem System mit Windows Vista SP1 und habe das JRE 1.6Update11 installiert.

Mein Problem: Obwohl ich meine Anwendung mit den Parametern -Xmx512m -Xms512m oder einfach nur -Xmx512 starte, wird die o.g. Fehlermeldung erzeugt. Beim Starten der Anwendung belegt javaw.exe ca. 60MB Speicher, laut Taskmanager. Sobald javaw.exe mehr als 100 MB Speicher belegt, wird dieser Fehler geworfen und zwar immer wieder, sobald ich auf eine Methode meiner Swing-View zugreife. Wenn ich meine Anwendung nicht neustarte, dann geht das soweit, dass zum Teil Datenbankzugriffe auf meine MySQL-Datenbank mit SQLExceptions abgebrochen werden. Die SQLException liefert dann ebenfalls die Meldung:

java.lang.OutOfMemoryError: Java heap space.

Hat jemand eine Idee, woran das liegen könnte?

Mit freundlichen Grüßen
feng

 

[The_S]

An Fehlerhafter Programmierung.

 

[Zed]

Ich nehme mal an du hast irgendwo eine Funktion die massig Objecte erstellt. Ich nehme auch an diese Funktion ist schlecht durchdacht und implementiert.

 

[maki]

Endlosschleifen neigen dazu so einen Fehler zu produzieren.

 

[feng]

Danke für die aufschlussreichen Antworten. Ich habe daraufhin in zahlreichen Foren gestöbert und viele Lösungsansätze ausprobiert. Inzwischen habe ich mein Programm derart überarbeitet, dass solche Fehler nicht auftreten dürften. Dennoch tun sie es.

Durch Zufall bin ich nun darauf gestoßen, was den Fehler verursacht.

Der Fehler tritt nicht auf, weil ich "fehlerhaft" programmiert habe, sondern, weil die JavaVM im Bereich javax.swing ein Speicherleck (Memoryleak) hat. Es ist ja auch sehr seltsam, dass die JVM trotz erlaubten 512MB Speicher bei ca. 100MB benutzem Speicher die Heap Space Errors erzeugt.


Die Reproduktion des JVM Bugs ist ziemlich einfach:

import javax.swing.JFrame;

public class JFrameLeak {
    public static void main(String[] arg) {
        JFrame f = new JFrame();
        f.setSize(200,100);
        f.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
        f.setVisible(true);
    }
}

1. Diesen Code kompilieren und starten.
2. Die Auflösung des Desktops ändern, z.b. 800x600 und zurück.

Bei jedem Ändern der Auflösung verbraucht die JVM mehr Speicher. Der Garbage Collector erkennt den Datenmüll nicht.

Ich vermute, dass bei den Zeichenmethoden von javax.swing, die bei jeder Auflösungsänderungen ausgeführt werden, bestimmte Objekte, die für die vorige Auflösung benutzt wurden, für den Garbage Collector nicht freigegeben werden.

Es kann natürlich sein, dass es auf anderen Betriebssystemen nicht reproduzierbar ist.

 

[Wolfgang Lenhard]

Java geht großzügig mit Speicher um, solange genügend zur Verfügung steht. Tatsächlich geht der Speicher hoch, wenn Du die Bildschirmauflösung änderst. Allerdings wird dieser später auch wieder frei gegeben. Um an die Grenze zu kommen müsstest Du außerdem extrem oft die Bildschirmauflösung ändern. Ein solcher Anwendungsfall ist zuminest mir nicht bekannt. Daran kann es also nicht liegen.
Der Fehler muss in Deinem Programm woanders sein.

Ciao,
Wolfgang

 

[feng]

Bei dem kleinen Beispielprogramm steigt der Speicher ja schon recht schnell.
Bei meiner eigenen Anwendung steigt der Speicherverbrauch pro Auflösungswechsel (hin und zurück) um 5-7 MB und es genügen schon wenige (ca. 6) Auflösungsänderungen bis die JVM 100 MB Speicher verbraucht und anfängt Heap Space Errors zu erzeugen.

Ein solcher Anwendungsfall ist zuminest mir nicht bekannt. Daran kann es also nicht liegen.
Der Fehler muss in Deinem Programm woanders sein.

Ein einfacher Anwendungsfall: am Rechner, wo die Swinganwendung ausgeführt wird, spielt der Nutzer Spiele mit anderen Auflösungen als die des Desktops. Der Spieler tabbt mehrfach aus dem Spiel auf den Desktop und zurück. Es müssen nicht unbedingt Spiele sein. Es geht um jede Anwendung, die im exklusiven Fullscreenmodus und in einer anderen Auflösung als die des Desktops läuft.

Allerdings wird dieser später auch wieder frei gegeben.

Bei mir nach mehrfachem Testen nicht. Auch wenn ich speziell den Garbage Collector aufrufe. Dass System.gc() den Garbage Collector nicht zwingt aufzuräumen, ist mir bekannt. Doch wenn ich den Garbage Collector mehrfach aufrufe und den GUI-Thread anschlissend sogar mit Thread.yield() oder Thread.sleep(50) pausiere, räumt der Garbage Collector diesen speziellen Objektmüll nicht auf und es kommt trotzdem zu Heap Space Errors.

 

[Wolfgang Lenhard]

Ah, tatsächlich. Ein entsprechender Bug wird in der Bug-Database von Sun beschrieben: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6209673 und http://weblogs.java.net/blog/enicholas/archive/2006/04/leaking_evil.html
Ich weiß allerdings nicht, wie es aktuell aussieht. Gibt da wohl eine Reihe an doppelten Einträgen. Würde sich ggf. lohnen, sich da entlang zu hangeln um eine Lösung zu finden.

Ciao,
Wolfgang

P.S.: Welche Version hat Deine Runtime?

 

[feng]

Vielen Dank für den Hinweis. Ich war auch gerade in der Bugdatabase am Stöbern, bin aber nicht so schnell fündig geworden und hätte schon fast einen eigenen Report erstellt.

Ich muss auch einen Eintrag ergänzen, wo ich mich eingangs beim Erstellen dieses Threads geirrt habe. Ich habe noch JRE 1.6Update10 und nicht Update11 benutzt. Ich habe soeben das neue JDK1.6U11 installiert und die Heap Space Errors werden nun erst nach Erreichen der maximal angegebenen 512MB erzeugt und nicht schon nach ca. 100MB.
Der Bug mit dem Objektmüll bleibt allerdings. Bei jedem Auflösungswechsel steigt der Speicherverbrauch.

Ich bin erstmal froh an die richtige Adresse verwiesen worden zu sein.
Nochmals einen großen Dank an dich Wolfgang.

Mit freundlichen Grüßen
feng

 

[feng]

So, das Problem ist jetzt behoben. Ich habe das Workaround auf der Bugseite von Sun benutzt. Beim ausgiebigen Testen habe ich keinen einzigen Heap Space Error erhalten. Nach ca. 8 Stunden Laufzeit und zahlreichen Auflösungsänderungen ist meine Anwendung nicht mal auf 90 MB Speicherverbrauch gekommen.


Die Lösung sieht so aus:

import java.awt.Dimension;
import java.awt.EventQueue;
import java.awt.GraphicsEnvironment;

import sun.awt.DisplayChangedListener;

import javax.swing.RepaintManager;


public class DisplayChangeHandler implements DisplayChangedListener, Runnable {
	// We must keep a strong reference to the DisplayChangedListener,
	// since SunDisplayChanger keeps only a WeakReference to it.
	private static DisplayChangeHandler displayChangeHack;
	static {
		GraphicsEnvironment env = GraphicsEnvironment.getLocalGraphicsEnvironment();
		
		if ( displayChangeHack == null ) {
			displayChangeHack = new DisplayChangeHandler();
		}
		// Add ourselves as a listener to the GraphicsEnvironment if possible.
		try {
			env.getClass().getMethod(
				"addDisplayChangedListener",
				DisplayChangedListener.class
			).invoke(env, displayChangeHack);
		} catch (Exception e) {
			System.out.println("Could not create DisplayChangeHandler: " + e.getMessage());
		}
	}

	public void displayChanged() {
		EventQueue.invokeLater(this);
	}
	
	public void paletteChanged() {
		EventQueue.invokeLater(this);
	}
	
	public void run() {
		// Force the RepaintManager to clear out all of the VolatileImage back-buffers that it has cached.
		// See Sun bug 6209673.
		// [url]http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6209673[/url]
		RepaintManager rm = RepaintManager.currentManager(null);
		Dimension size = rm.getDoubleBufferMaximumSize();
		rm.setDoubleBufferMaximumSize(new Dimension(0, 0));
		rm.setDoubleBufferMaximumSize(size);
	}
}

Die o.g. Klasse muss im Controller oder in der View, ist an sich belanglos, einmal instanziiert werden. Wie in den Kommentaren der Klasse selbst schon steht, beinhaltet es eine eigene starke Referenz auf sich selbst und es genügt ein einfaches: new DisplayChangeHandler() um das Objekt zu erzeugen. Anschliessend werden bei jeder Auflösungsänderung die 4 Zeilen in der run() Methode ausgeführt. Was diese Zeilen genau machen, kann man auf der Bugseite nachlesen.

Mit freundlichen Grüßen
feng