Du hast memory leaks in einem Java Programm??

Sollt die Java Runtime sich nicht ums Garbage Collecting kümmern?
(Ich komm ja mehr aus der .NET, C#, C++ Welt, aber ich dachte das wär so...)

[EDIT:]
Anscheined schon, aber net wirklich perfekt:
http://www.ibm.com/developerworks/java/library/j-leaks/

Vielleicht hilft dir eins von diesen weiter:
http://www.quest.com/jprobe/ (10-Tage Trial)
http://www.geocities.com/moellep/debug/HeapInspector.html (Schaut nach Freeware aus)

Zitat von Saruman

Anscheined schon, aber net wirklich perfekt:
http://www.ibm.com/developerworks/java/library/j-leaks/

Dort wird ein Memory Leak in Java an folgendem Beispiel erklärt: "Now let's suppose class B is some user interface widget that is displayed and eventually dismissed by the user. Even though class B is no longer needed, if the reference that class A has to class B is not cleared, class B will continue to exist and to take up memory space even after the next garbage collection cycle is executed."

Das ist doch meiner Meinung nach gar kein Memory Leak aus technischer Sicht. A hat noch eine Referenz auf B, damit wird B potentiell noch benötigt. Woher soll der GC wissen dass es in Wirklichkeit nicht mehr verwendet wird?

Wikipedia meint zu Memory Leaks: "... ein solches Leck entsteht, wenn ein laufender Prozess einen Speicherbereich belegt, diesen jedoch im Zuge der Ausführung nicht mehr freigibt und durch einen Programmfehler auch selbst nicht mehr nutzen kann."

Letzteres ist aber nicht gegeben: B kann ja noch verwendet werden. Ein richtiges Memory Leak ist es doch nur, wenn man einen Speicherbereich nicht freigibt und dann auch sämtliche Pointer darauf löscht, oder? Und das kann in Java nicht passieren.

Zitat von Christoph R.

Das ist doch meiner Meinung nach gar kein Memory Leak aus technischer Sicht. A hat noch eine Referenz auf B, damit wird B potentiell noch benötigt. Woher soll der GC wissen dass es in Wirklichkeit nicht mehr verwendet wird?

Hmm, irgendwie hast du schon recht...

Ich versteh das eher so, dass Memory Leaks in Java zwar keine Memory Leaks im herkömmlichen Sinn sind, aber trotzdem ähnliche Probleme verursachen können:
Nehmen wir an, A hat zwar noch eine Referenz auf B, B wird aber nicht mehr "verwendet" bzw. ist durch irgendeine Eigenschaft als inaktiv markiert.

Das nächste Mal, wenn B benötigt wird, stellt das Programm fest, dass es kein aktives B mehr gibt und legt ein neues an, A bekommt eine zusätzliche Referenz auf das neue B.

Wenn das ganze jetzt sehr oft hintereinander passiert, hast du schnell eine sehr hohe Anzahl an Bs, die der Garbage Collector nicht löscht, weils ja noch Referenzen drauf gibt.

Das ist jetzt zwar ein sehr konstruiertes Beispiel mit besonders miesem Programmierstil, aber so ist denk ich ein "Memory Leak" möglich.

Memory leaks sind in Java andere als die, die man von C, C++, etc. kennt. Die GC verleitet sehr oft dazu, das man vergisst, alle reverenzen auf ein nicht mehr gebrauchtes Object auf null zu setzten (Hashtables, Vector, EventListener, etc.):

Another common problem occurs when you register a class as an event listener without bothering to unregister when the class is no longer needed. Also, many times member variables of a class that point to other classes simply need to be set to null at the appropriate time.

Zwar ist die "Art" des leaks eine andere, aber im endeffekt passiert das selbe, der speicher wird einfach "vollgemacht", weil man vergisst (aktiv [free] oder passiv mit GC, weil man auf manche reverenzen vergisst) speicher frei-zu-geben.

bei dem "mit dem selber nicht mehr nutzen kann" geb ich dir recht.

Zitat von samyjr

reverenzen

vor allem die tatsache, dass in LinkedLists jedes element eine reverenz auf das naechste element hat (meines wissens nach steckt hinter der LinkedLists implementierung sowieso eine doppelt verkettete zyklische liste, also noch schlimmer) kann dem GC die arbeit erschweren.

und bzgl profiling tool:

- jhat (heapanalyse)
- BEA JRockit JVM (hat ein integriertes memoryleak analysetool)
- JProbe, JProfiler, yourKit (sehr gute tools, jedoch nicht kostenlos) // JProfiler ist mein liebling
- dynaTrace diagnostics, Quest PerformanSure, CA/Wily Introscope (performance-/memory analyse tools)

Ja, JProfiler ist genial, kann ich absolut empfehlen; sein eher hoher Preis ist absolut gerechtfertigt.
(Ist auch mein bevorzugtes Profiling-Tool)

mfg, lb

Wir verwenden in der Arbeit yourkit und sind damit auch mehr als zufrieden.

FProfiler ist ein open source profiler aus den eigenen Reihen ( Mihi hatte das Projekt erst letzten Monat abgegeben), weitere freie profiling software findet sich z.B. hier . Eclipse Profile ist auch nicht uebel.

Was aber hier auch unbedingt erwähnen sollte: Es wird ja auch bereits ein Profiler zusammen mit dem Java SDK von Sun ausgeliefert: http://java.sun.com/developer/tech…ming/HPROF.html

Oh, und dann gibt es ja auch noch java.lang.System.currentTimeMillis() . Das reicht oft voellig aus.