Frage zu Memory Leak, Garbage Collection und Profiler-Tools

[-frank]

ich habe das Problem dass der Speicherverbrauch meiner Applikationen in bestimmten Situationen rapide ansteigt (von wenigen MB zu ~70MB). der Speicher steigt nicht ins Unendliche an (sondern eben nur bis auf ~70MB), aber diese 70MB werden nie wieder freigegeben.
ich habe ein den Profiler JProbe verwendet um das Problem aufzuspüren. dort sehe ich, dass wie gesagt etwa 60/70 MB gebraucht werden (70 alloziert, 60MB wirklich genutzt). Diese werte ändern sich auch nach Minuten noch nicht. Klicke ich nun in JProbe auf "request Garbage Collection" sinkt der Speicherverbrauch auf 3/10 MB ab. Meine erste Frage nun: tut JProbe da irgendetwas besonders? wieso funktioniert es, wenn JProbe den "Befehl" zum Aufräumen gibt?

zweite frage: ich habe einige Forum-Threads zu dem Thema überflogen und bin auf System.gc() gestoßen. ALso hab ich meiner Applikation einen Button spendiert, der System.gc() aufruft. Und siehe da, auch das reduziert den Speicherverbrauch enorm! --> zweite frage ist ähnlich wie die erste: was macht System.gc(), was die normale Garbage Collection nicht macht? (Laut Dokumentation sagt es dem System doch nur, dass jetzt ein guter Zeitpunkt zum Aufräumen wäre.)

Dritte Frage: wenn System.gc() bzw. JProbe den Speicher aufräumen können, das ganze aber nicht automatisch passiert, deutet das dann eher auf einen Bug hin oder liegt der Fehler vermutlich trotzdem bei mir? Wenn er bei mir liegen sollte: kann mir jemand einen Beispiel-Code nennen, der den Speicherverbrauch so erhöht, dass er von der automatischen GC nicht mehr reduziert werden kann, sehr wohl aber von System.gc()? (mich verwirrt dies alles ein wenig, da ich mich um die GC in Java noch nie gekümmert habe...)

 

[maki]

+~70MB

Wohl eher 64MB bzw. knapp darunter, 64MB ist der Standard Speicher für die VM.

Der GC rennt erst los, wenn diese 64MB fast voll sind, nicht vorher.
Mit System.gc() kann man dem System vorschlagen, den GC aufzurufen.

Wenn nach dem GC der Speicher wieder frei ist, ist es kein echtes Memoryleak, sondern eher ein Hinweis darauf, dass deine Anwendung eben diesen Bedarf hat.

Vielleicht kann man den Speicher"verbrauch" noch optimieren, aber dazu müsste man schon Details kennen.

 

[-frank]

hmm, korrekt, im Profiler sinds exakt 64MB.

okay, verstehe ich das richtig?:
es gibt vereinfacht gesagt Garbage Collection auf verschiedenen Leveln. Manche, für die GC "offensichtliche" Objekte/Referenzen werden auch unter 64MB gelöscht. Beispiel: eine schleife, die 500000000 strings erzeugt verbraucht bei mir laut Profiler nie mehr als 1MB.
Andere ebenfalls löschbare Objekte werden schwerer erkannt, wodurch das Aufspüren mehr Performance kostet. Deswegen wird diese "volle" Garbage Collection (per Default) erst bei 64MB ausgelöst oder eben durch System.gc().

Wenn mein Programm (fast) auf die 64MB kommt, aber durch System.gc() locker wieder auf 5MB runter geht, bedeutet das, dass ich solche "schwer aufzuspürenden" Objekte habe. Es ist aber weder ein Java-Bug noch ein Bug in meinem Programm. korrekt?

und die "volle" GC wird automatisch unter 64MB nie ausgeführt und über 64MB auch nur soweit, dass das Programm wieder weniger als 64MB braucht (was erklärt, warum der Speicherverbrauch nie wieder reduziert wird).

oder hab ich das jetzt komplett falsch verstanden?

 

[maki]

Manche, für die GC "offensichtliche" Objekte/Referenzen werden auch unter 64MB gelöscht.

Nein, normalerweise läuft der GC nie an, bis eben der Speicher fast voll ist, oder du mit System.gc() sugerrierst das er starten sollte.

Andere ebenfalls löschbare Objekte werden schwerer erkannt, wodurch das Aufspüren mehr Performance kostet. Deswegen wird diese "volle" Garbage Collection (per Default) erst bei 64MB ausgelöst oder eben durch System.gc().

Wenn der GC läuft, steht alles andere im System!
Deswegen läuft er auch nur wenn es sein muss

Es gibt imho keine "schwer" oder "leicht" erkennbaren "löschbare Objekte", entweder ein Objekt kann recycled werden, oder eben nicht.

Beispiel: eine schleife, die 500000000 strings erzeugt verbraucht bei mir laut Profiler nie mehr als 1MB.

Schlechtes Beispiel, da der Kompilier speziell String sehr gut optimieren kann.
Vergleiche doch mal deinen Originalcode mit dem dekompilierten code aus zB. Frontend Plus, du wirst überrascht sein da eine andere Klasse zu finden (zB. StringBuilder)
Auch kann die Hotspot VM zur Laufzeit deinen Code optimieren, ist alles keine exakte Wissenschaft..

 

[-frank]

hab das aus diesem absatz:

A third category where developers often mistakenly think they are helping the garbage collector is the use of System.gc(), which triggers a garbage collection (actually, it merely suggests that this might be a good time for a garbage collection). Unfortunately, System.gc() triggers a full collection, which includes tracing all live objects in the heap and sweeping and compacting the old generation. This can be a lot of work. In general, it is better to let the system decide when it needs to collect the heap, and whether or not to do a full collection. Most of the time, a minor collection will do the job.

quelle: http://www.ibm.com/developerworks/java/library/j-jtp01274.html

wurde hier gepostet im forum.

der speicherverbrauch meiner applikation ändert sich laut Profiler alle paar sekunden (und geht auch manchmal nach unten). also IMO wird die GC da schon automatisch gestartet. wenn nicht, müsste ja eine simple applikation die nur ein popup-menu anzeigt auf 64MB kommen, wenn man oft genug das menu anzeigen und wieder verschwinden lässt.

 

[maki]

Das mit der "minor collection" wusste ich nicht, danke.

 

[-frank]

Das mit der "minor collection" wusste ich nicht, danke.

auch ich nicht bis vor ner stunde

aber danke auch an dich. das mit den 64MB hat mir sehr geholfen, da ich jetzt weiß, dass ich keinen bug bzw. kein memory leak habe, sondern einfach nur Objekte, die nicht "so leicht" zu entfernen sind.

falls es wen interessiert: das problem entsteht im zusammenhang mit Font.deriveFont(float). wenn man viele Font objekte von einander ableitet, bleiben anscheinend alle bestehen (bzw. zumindest manche referenzen/objekte). nur die "volle" garbage collection findet diese objekte dann. dafür ist deriveFont anscheinend auch schneller als new Font(..) (wobei ich das jetzt nur in einer schleife kurz getestet habe).