# Probleme mit dem Java heap



## Gast2 (3. Sep 2009)

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
> ...


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 (3. Sep 2009)

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 (3. Sep 2009)

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 (3. Sep 2009)

Schließt du deine Connections nicht?


> 99 instances of class com.mysql.jdbc.JDBC4Connection


----------



## Gast2 (3. Sep 2009)

> 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 (3. Sep 2009)

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


----------



## Gast2 (3. Sep 2009)

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 (3. Sep 2009)

EikeB hat gesagt.:


> So schließe ich meine Verbindungen:
> 
> 
> ```
> ...


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


----------



## tfa (3. Sep 2009)

> 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 (3. Sep 2009)

tfa hat gesagt.:


> 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 (3. Sep 2009)

EikeB hat gesagt.:


> 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 (3. Sep 2009)

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 (3. Sep 2009)

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 (3. Sep 2009)

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 (3. Sep 2009)

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


----------

