G
Gast2
Gast
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.
Da ich mit jmap nicht viel weiter gekommen bin habe ich den Eclipse Memory Analyzer angeschmissen, der mir dann folgendes ausgegeben hat:
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.
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.
Hier ein kleiner Ausschnitt aller Instanzen (nach ca. 10min Laufzeit). Hier direkt meine erste Frage, sind zahlen wie 10.000 bzw. 12.000 normal?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
Da ich mit jmap nicht viel weiter gekommen bin habe ich den Eclipse Memory Analyzer angeschmissen, der mir dann folgendes ausgegeben hat:
41,44% werden von Finalizer Objekten verbraucht? Finalizer hat doch irgendwas mit Garbage Collection zu tun, oder nicht?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
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.