Probleme mit dem Java heap

[Gast2]

Hi,
ich habe ein großes Problem mit einem memory leak.
Mein Java heap space wächst und wächst bis schließlich eine Out of Memory Exception kommt.
Das Programm ist eine rel. große Swinganwendung mit ca. 20k LoC. Ich habe leider keine Erfahrung mit memory leaks, daher melde ich mich hier und hoffe darauf dass mir jemand helfen kann

Hier einige kurze Infos zu meinem Problem:
Wie gesagt wächst der heap space stetig an bis schließlich das Programm abschmiert.
Ich habe mithilfe von jhat und jmap einen kurzen Blick in den heap geworfen.

12007 instances of class com.mysql.jdbc.ByteArrayRow
10700 instances of class com.mysql.jdbc.ConnectionPropertiesImpl$BooleanConnectionProperty
2800 instances of class com.mysql.jdbc.ConnectionPropertiesImpl$StringConnectionProperty
2500 instances of class com.mysql.jdbc.ConnectionPropertiesImpl$IntegerConnectionProperty
1785 instances of class com.mysql.jdbc.Buffer
1334 instances of class com.mysql.jdbc.Field
832 instances of class com.mysql.jdbc.JDBC4ResultSet
829 instances of class [Lcom.mysql.jdbc.Field;
424 instances of class com.mysql.jdbc.RowDataStatic
328 instances of class com.mysql.jdbc.StatementImpl
300 instances of class com.mysql.jdbc.ConnectionPropertiesImpl$MemorySizeConnectionProperty
179 instances of class com.mysql.jdbc.log.StandardLogger
100 instances of class com.mysql.jdbc.ConnectionPropertiesImpl$LongConnectionProperty
99 instances of class com.mysql.jdbc.JDBC4Connection
99 instances of class com.mysql.jdbc.JDBC4DatabaseMetaData
98 instances of class com.mysql.jdbc.MysqlIO
98 instances of class com.mysql.jdbc.StandardSocketFactory
98 instances of class com.mysql.jdbc.util.ReadAheadInputStream
94 instances of class cnc.gui.Mainframe$3
85 instances of class com.mysql.jdbc.jdbc2.optional.JDBC4ConnectionWrapper
85 instances of class com.mysql.jdbc.jdbc2.optional.JDBC4MysqlPooledConnection
85 instances of class com.mysql.jdbc.jdbc2.optional.JDBC4StatementWrapper
82 instances of class cnc.gui.ConnectionsDialog$1
66 instances of class com.mysql.jdbc.VersionedStringProperty
53 instances of class org.jdesktop.application.ApplicationAction
49 instances of class $Proxy3
41 instances of class cnc.util.listItems.ConnectionListItem

Hier ein kleiner Ausschnitt aller Instanzen (nach ca. 10min Laufzeit). Hier direkt meine erste Frage, sind zahlen wie 10.000 bzw. 12.000 normal?

Da ich mit jmap nicht viel weiter gekommen bin habe ich den Eclipse Memory Analyzer angeschmissen, der mir dann folgendes ausgegeben hat:

The class "java.lang.ref.Finalizer", loaded by "<system class loader>", occupies 7.435.408 (41,44%) bytes. The memory is accumulated in one instance of "java.lang.ref.Finalizer" loaded by "<system class loader>".

Keywords
java.lang.ref.Finalizer

41,44% werden von Finalizer Objekten verbraucht? Finalizer hat doch irgendwas mit Garbage Collection zu tun, oder nicht?

Darauf hin habe ich meinen Quellcode dahingehend modifiziert und führe manuell per System.gc() die Garbage Collection durch. Wenn ich jetzt mal ein Profiling starte sieht es so aus, als ob nach jeder gc der heap wieder auf ~15MB reduziert wird, es scheint also dann nichtmehr zu einer Out of Memory Exception zu kommen.

Wäre es unter Umständen ungünstig wenn ich z.b. alle 60Minuten mal die Garbage Collection anschmeiße um so den Heap wieder auf die "normalen" 15MB zu reduzieren?
Ich Frage mich außerdem warum Java das nicht automatisch macht, wenn doch soviel "Müll" im Speicher liegt?!

Das non plus ultra wäre natürlich wenn mir jemand einen Tipp geben könnte um das Übel an der Wurzel zu packen und das anwachsen des Heaps zu verhindern.

 

[Marco13]

44% sind in diesem Fall ja nur 7 MB ... Mehr als den Tipp, nochmal genauer mit dem Memory Analyzer zu gucken, und zu überprüfen, ob irgendwo etwas angelegt wird, was eine "ByteArrayRow" erstellt, und das dann in eine Collection gelegt wird, kann ich anhand des geposteten auch nicht geben.
Aber einen wichtigen Hinweis noch: Es sollte NIE (NIE) notwendig sein, System.gc() aufzurufen!

 

[bygones]

mit wieviel MB startest du denn die anwendung ?

wenn irgendwo du mal eben zig millionen datensaetze aus einer DB laedst oder so und moeglichweise sonstiges noch offen hast koennten die 64M standart knapp werden...

einfach mal mehr speicher der VM geben ?

 

[tfa]

Schließt du deine Connections nicht?

99 instances of class com.mysql.jdbc.JDBC4Connection

 

[Gast2]

mit wieviel MB startest du denn die anwendung ?

wenn irgendwo du mal eben zig millionen datensaetze aus einer DB laedst oder so und moeglichweise sonstiges noch offen hast koennten die 64M standart knapp werden...

Ich starte die VM mit dem Standardwert, sollten 256MB sein (zumindest schmiert mir das Programm ab sobald der heap größer als 256MB wird).
Die Datenbank ist eigentlich nicht sehr groß, 5 Tabellen, 4 davon mit <20 Datensätze, eine mit ~300 Datensätzen. In der großen Datenbank fallen pro Zeile vllt allerhöchstens 10kb an. Eigentlich sogar nur viel weniger.

einfach mal mehr speicher der VM geben ?

Ich kann mir schwer vorstellen dass mein Programm mehr als 256MB speicher braucht, ich schätze wenn ich dem Prog mehr Speicher zur Verfügung stelle dauerts halt nur etwas länger bis alles voll ist :bae:

Schließt du deine Connections nicht?

99 instances of class com.mysql.jdbc.JDBC4Connection

Doch. Ich habe gestern erst alles was die Datenbank betrifft umgeschrieben und bin von einer Eigenimplementierung eines connection pool auf den cp vom treiber umgestiegen, weil ich schon vorher vermutet habe dass die Datenbank da irgend nen humbug veranstaltet. Hat leider nichts geholfen.
Ich schließe alle ResultSets, Statements und Connections wenn diese nichtmehr gebraucht werden.

44% sind in diesem Fall ja nur 7 MB ... Mehr als den Tipp, nochmal genauer mit dem Memory Analyzer zu gucken, und zu überprüfen, ob irgendwo etwas angelegt wird, was eine "ByteArrayRow" erstellt, und das dann in eine Collection gelegt wird, kann ich anhand des geposteten auch nicht geben.
Aber einen wichtigen Hinweis noch: Es sollte NIE (NIE) notwendig sein, System.gc() aufzurufen!

Ok, ich werde mir das dann nochmal genauer anschauen müssen. Und dass man System.gc() nicht aufrufen sollte seh ich ein, aber wenns hilft?

 

[maki]

Zeig mal den Code wie du die RS & Connections schliesst.

 

[Gast2]

So schließe ich meine Verbindungen:

try {
    rs.close();
    rs = null;
    myStmt.close();
    myStmt = null;
    myCon.close();
    myCon = null;
} catch (SQLException sqle) {
    logger.error(sqle);
}

Um ne neue Verbindung zu holen wird diese Methode aufgerufen:

public static Connection getConnection() {
        Connection con = null;
        try {
            con = dataSource.getPooledConnection().getConnection();
        } catch (SQLException sqle) {
            logger.error("Fehler beim Verbinden zur Datenbank");
            logger.debug("Username: " + dataSource.getUser());
            logger.debug("Password: " + dataSource.getPasswordCharacterEncoding());
            logger.debug("URL: " + dataSource.getUrl());
        }
        return con;
    }

datasource ist vom Typ MysqlConnectionPoolDataSource. In der API steht, dass durch den Aufruf von Connection.close(); die Verbindung zurück in den Pool gelegt wird. Ich kann mir höchstens vorstellen, dass der connection pool der Meinung ist dass die Verbindungen offen gelassen werden sollten?!

 

[bygones]

So schließe ich meine Verbindungen:

try {
    rs.close();
    rs = null;
    myStmt.close();
    myStmt = null;
    myCon.close();
    myCon = null;
} catch (SQLException sqle) {
    logger.error(sqle);
}

im falle einer exception schliesst du nix... das setzen auf null sollte eigentlich unnuetz sein

 

[tfa]

Ich kann mir höchstens vorstellen, dass der connection pool der Meinung ist dass die Verbindungen offen gelassen werden sollten?!

Das haben Connection-Pools so an sich. Allerdings bleiben nur eine gewisse Anzahl Connections offen, je nachdem, wei der Pool konfiguriert ist. Keine Ahnung wie das bei dem MysqlConnectionPoolDataSource funktioniert. Wieso benutzt du den? Verwenden einen Technologie-unabhängigen Pool, dann hast du später keine Probleme, wenn du mal die DB wechseln willst.

 

[Gast2]

Das haben Connection-Pools so an sich. Allerdings bleiben nur eine gewisse Anzahl Connections offen, je nachdem, wei der Pool konfiguriert ist. Keine Ahnung wie das bei dem MysqlConnectionPoolDataSource funktioniert. Wieso benutzt du den? Verwenden einen Technologie-unabhängigen Pool, dann hast du später keine Probleme, wenn du mal die DB wechseln willst.

Aber 99 Verbindungen aufrecht zu erhalten halte ich für ein wenig übertrieben
Ich habe in der API nichts gefunden wie ich die maximale Anzahl der Verbindungen beschränken kann. Aber darin liegt wohl auch nicht unbedingt das Problem mit dem memory leak :/

 

[tfa]

Aber 99 Verbindungen aufrecht zu erhalten halte ich für ein wenig übertrieben

Ich auch.

Ich habe in der API nichts gefunden wie ich die maximale Anzahl der Verbindungen beschränken kann.

Das ist schlecht. Dann schmeiß testweise den Pool ganz raus und versuche es nur mit einer Connection.

Aber darin liegt wohl auch nicht unbedingt das Problem mit dem memory leak :/

Wie kommst du darauf?

 

[Gast2]

Habe den Pool jetzt rausgenommen und durch eine MysqlDataSource ersetzt. Das ganze auf nur eine Verbindung zu begrenzen ist nicht möglich weil mehrere Threads auf die DB zugreifen müssen.
Aber durch den Wegfall des pools sollten ja jetzt die Verbindungen ganz geschlossen werden.

Hier im Anhang nen Screenshot vom Profiling. Die "Hügel" kommen dadurch zustande dass ich dem Programm ein bißchen was zutun gegeben habe und er da jeweils immer ein Fenster öffnet.
Trotzdem kann man glaub ich erkennen dass ne kleine Steigung zu erkennen ist.

 

[tfa]

Keine Ahnung was eine MysqlDataSource macht. Vielleicht betreibt die auch Pooling.
Ich verwende DBCP, das funktioniert.

Wenn du den GC aufrufst, bleiben dann deine 99 Connections bestehen?

 

[maki]

MySQL :: Re: MysqlConnectionPoolDataSource leaving dangling connections

Ist zwar älter, aber die Aussage ist sehr klar: MysqlConnectionPoolDataSource sollte man nicht verwenden.

Soll heissen: Du hast gar keine Connections gepooled, sondern immer eine neue geöffnet, und geschlossen hast du sie auch nicht.

Das sollte eigentlich alles erklären.

Würde da auch DBCP empfehlen.

 

[Gast2]

Danke euch, ich habe nun auf DBCP umgestellt und es scheint so, dass sich das Problem damit erledigt hat. Zumindest bleibt der Heap im "Leerlauf" nun konstant und steigt nicht weiter.
Werde wohl noch den rest durchtesten müssen, aber das hat schonmal geholfen