Thread: was passiert nach run()?

[maseru]

Hallo liebe Javagemeinde,

ich hab eine grundlegende Frage. Was passiert eigentlich mit einer Klasse, die von Thread abgeleitet ist und deren run() Methode endet :?:. Stirbt dann diese Klasse und der Garbage Collector gibt die Ressourcen frei. Es ist mir schon öfter aufgefallen, das trotz interrupt und finalize Aufruf, sowie System.gc() der Speicher den die Klasse benötigt nicht immer freigegeben wird.
Kann mir jemand darauf eine Erklärung geben?

mfg
maseru

 

[André Uhres]

Der Thread stirbt und der Garbage Collector kann die Ressourcen freigeben.
Wann das geschieht ist weder definiert noch kann man es beeinflussen.

 

[Oskar]

Der Thread stirbt und der Garbage Collector kann die Ressourcen freigeben.
Wann das geschieht ist weder definiert noch kann man es beeinflussen.

Ist meines Erachtens nicht ganz korrekt. Nach run() stirbt der Thread. Ich kann allerdings weiterhin in meinem Program eine Referenz auf das Objekt haben auf dem die run() aufgerufen wurde. Dann existiert das Objekt so lange im Speicher bis ich diese Referenz wegräume.

Es ist mir schon öfter aufgefallen, das trotz interrupt und finalize Aufruf, sowie System.gc() der Speicher den die Klasse benötigt nicht immer freigegeben wird.

Dadurch kommt es dann auch dazu, dass der GC das Objekt nicht wegräumt.

 

[maseru]

okay
ich habe ein Server Client Anwendung geschrieben.
Der Client sendet ein Kommando an den Server, bsp Dekompression eines Bildes und sendet das Bild an den Client.
Dies geschieht durch Threads, damit mehrere Anfragen "gleichzeitig" bearbeitet werden können.
Sende ich nun n Anfragen an den Server, so belegen nun die Threads mit den dekomprimierten Bildern auf dem Server Speicher, obwohl die run Methode beendet und die Referenz auf null gesetzt wird (die Threads liegen in einer verketteten Liste und tragen sich kurz vor Ende der run Methode aus der Liste aus). Nun das Kuriose, sende ich danach einen Anderen Befehl , bsp. der Server soll n Bytes an den Client senden, wird der Speicher für die Threads derdekomprimierten Bilder freigegeben.
Obwohl die Threads für die unterschiedlichen Befehle identisch aufgebaut sind.
???:L

 

[Oskar]

Sende ich nun n Anfragen an den Server, so belegen nun die Threads mit den dekomprimierten Bildern auf dem Server Speicher, obwohl die run Methode beendet und die Referenz auf null gesetzt wird (die Threads liegen in einer verketteten Liste und tragen sich kurz vor Ende der run Methode aus der Liste aus). Nun das Kuriose, sende ich danach einen Anderen Befehl , bsp. der Server soll n Bytes an den Client senden, wird der Speicher für die Threads derdekomprimierten Bilder freigegeben.

Du willst damit sagen, dass der Speicher der zur Dekomprimierung der Bilder belegt wird in dem Moment wieder freigegeben wird, in dem du die andere Anfrage (n Bytes zu senden) an den Server stellst?

Sende ich nun n Anfragen an den Server, so belegen nun die Threads mit den dekomprimierten Bildern auf dem Server Speicher, obwohl die run Methode beendet und die Referenz auf null gesetzt wird

Nur das eine Referenz auf null gesetzt ist heist noch lange nicht, dass der GC das Objekt auch wegräumt. Dies geschieht automatisch nur dann wenn ein bestimmter Speicherbereich "vollgelaufen" ist. Der Aufruf System.gc() ist hier auch nicht verbinlich sondern nur eine Bitte an die JVM, dass der GC mal laufen sollte (such mal nach System.gc() im Forum, wurde schon häufiger behandelt).

Wenn du ein akutes Speicherproblem auf dem Server hast würde ich mal die Heapsize der JVM mittels eines der vielen -XParam Start-Parameter (kenne den genauen nicht --> Forumsuche) mal hochzusetzen.

 

[Leroy42]

Nun das Kuriose, sende ich danach einen Anderen Befehl , bsp. der Server soll n Bytes an den Client senden, wird der Speicher für die Threads derdekomprimierten Bilder freigegeben.

Genau das ist ja auch Sinn der Sache: Wird neuer Speicher benötigt, räumt der GC vorher auf.
Ansonsten ist er faul genug sich zu denken: "Wieso überhaupt".

Fast wie im richtigen Leben: Ich kenne da ein Pärchen, daß seine Bude auch nur dann
richtig aufräumt, wenn Schwiegerteil-Besuch ansteht...

Ansonsten siehe Oskars Erklärung.

 

[maseru]

Danke Jungs :toll:
Allerdings dekomprimiere ich große Bilder (Jpeg2000), da wäre eine dynamische Speicherfreigabe nicht schlecht.

 

[Illuvatar]

Schau auch mal hier: http://www.java-forum.org/de/viewtopic.php?t=19773

 

[maseru]

ja in diesem Beispiel sehe ich das auch ein. Nur nach dem Senden des Bildes exisitert beim Server keine Referenz mehr darauf .

 

[Oskar]

So um jetzt mal zu zeigen, dass ich hin und wieder Beiträge lese sei hier auch dieser Link zum Thema Weak-References angefügt. :roll:

Zwar bin ich noch nicht zur Lektüre des Inhaltes gekommen, aber vielleicht hilft es dir. Ich vermute es könnte deinem Speicherproblem abhilfe schaffen.

[edit] siehe auch diesen Eintrag im Forum

 

[maseru]

okay ich hab mir mal das Beispiel auf access1.sun.com/techarticles/weak.references.html angesehen. Dies sieht ja sehr vielversprechend aus.
Nun kann ich mich an die Überarbeitung meines Source Codes machen.
Nochmals vielen Dank :toll:

 

[maseru]

Hey ich hab ne Beobachtung gemacht, die mich in Erstaunen versetzt.
ich sende mehrere Anfragen an meinen Server.
ich überprüfe die Speicherbelegung mit Netbeans Profiler ->Speicherauslastung ca. 80MB
nach Abarbeitung der Anfragen Netbeans Profiler ->Speicherauslastung ca. 15MB
Windows TaskManager ->Speicherauslastung ca. 80MB
Wenn ich mein JFrame(Server-GUI) Minimiere und wieder Maximiere zeigt auch der TaskManager 15 MB an.
kurios oder?

 

[Leroy42]

Ich vermute mal, daß dein Profiler dir jeweils den aktuell genutzten Speicherverbrauch
anzeigt, während der Taskmanager den insgesamt angeforderten Speicher anzeigt.

Ich weiß nämlich nicht, ob die JVM nicht mehr benötigten Speicher an das BS zurückgibt.