Ich habe letzte Woche einige Zeit mit dem Eclipse Profiler verbracht, um ein merkwürdiges Memory Leak in unserer Software zu finden. Eigentlich ist das ja nicht mein Job, aber da mich der Bug von einer Kunden Demo abgehalten hat, und da ich es hasse wenn ich die Ursachen von solchen Problemen nicht kenne, habe ich ein paar Stunden meiner Freizeit im Debugger verbracht.
Problem war, dass eine unserer Komponenten sowohl synchron, als auch asynchron (mittels eigenem Thread Pool) aufgerufen werden kann. Beim synchronen Aufruf der Funktion lief aber reproduzierbar und schnell der Speicher zu. Meine Vermutung war ja erst, dass der Thread Handler am Ende der run methode noch irgendwelche cleanup tasks übernimmt, die der selten benutzte synchrone Code vergisst. Aber die Ursache ist an einer anderen Stelle, tief in der Java API zu suchen:
Na wer findet das Memory Leak bei Starter.start(false)? Auflösung im nächsten Blog Eintrag.
BTW: hat jemand eine Ahnung wie ich einfach Java Quelltext in S9Y pasten kann (am besten mit Syntax Coloring). Oder wie ich NL2BR partiell deaktivieren kann?
Problem war, dass eine unserer Komponenten sowohl synchron, als auch asynchron (mittels eigenem Thread Pool) aufgerufen werden kann. Beim synchronen Aufruf der Funktion lief aber reproduzierbar und schnell der Speicher zu. Meine Vermutung war ja erst, dass der Thread Handler am Ende der run methode noch irgendwelche cleanup tasks übernimmt, die der selten benutzte synchrone Code vergisst. Aber die Ursache ist an einer anderen Stelle, tief in der Java API zu suchen:
public class Processor extends Thread {
public Processor() {
}
public void run() {
// do something important
}
}
public class Starter {
public void start(boolean async) {
Processor p = new Processor();
if (async) {
p.start();
} else {
p.run();
}
}
}Na wer findet das Memory Leak bei Starter.start(false)? Auflösung im nächsten Blog Eintrag.
BTW: hat jemand eine Ahnung wie ich einfach Java Quelltext in S9Y pasten kann (am besten mit Syntax Coloring). Oder wie ich NL2BR partiell deaktivieren kann?
Kommentare
Ansicht der Kommentare:
(Linear | Verschachtelt)
Ob es tut habe ich noch nicht getestet.
--
Object of a class extended from Thread class remains in memory if only the object has been created but the thread has not been started (with .start()). The gabage collector doesn't remove this object.
You can resolve this problem if you start and stop immediatly the thread after the creation of object. It's possible you need to modify your code in the run() methode for this case.
--
Andere Lösung: Nicht von Thread erben, sondern Runnable implementieren (was ja eh immer die bevorzugte Lösung sein sollte - verbaut man sich nicht die Vererbungshierarchie)
Den weg mit Runable habe ich dann auch vorgeschlagen. Der hat in der Tat noch weitere Vorteile. Unter anderem auch eine flexiblerer Art und Weise wie der Job gestartet werden kann.
Layout by Ricky Wilson | Serendipity Template by Carl Galloway | Login
Impressum
Bernd Eckenfels
Mörscher Str. 8
76185 Karlsruhe
bernd-10@eckenfels.net
Read More
Suche
Kategorien
Verlinkung
Eingehende Links
- www.toysrhers.com [20]
- www.espnnn.com [16]
- www.google.de [4]
- www.google.de [4]
- stolyr.100webspace.net [4]
- proxyexplorer.net [4]
- groups.google.com [3]
- www.google.de [3]
- www.google.de [3]
- www.google.de [3]
- www.google.de [3]
- groups.google.com [2]
- groups.google.com [2]
- www.google.de [2]
- www.google.de [2]
Umfrage
Wirtschaftskrise
Archive
Archive
Kommentare
Bernd Eckenfels zu Private Nutzung
2010-03-27 20:24
Thomas zu Private Nutzung
2010-03-27 19:43
Helena zu Private Nutzung
2010-03-27 10:56
Mela zu Private Nutzung
2010-03-27 03:10
Quix0r zu Strategien gegen Open Source - vom Profi
2010-03-17 01:46
Bernd Eckenfels zu Durchschnittsalter der Parteimitglieder
2010-02-02 20:16
Herbert5000 zu Freies WLAN Karlsruhe (not!)
2010-01-10 18:07
Leonie zu Durchschnittsalter der Parteimitglieder
2010-01-10 15:43
Bernd Eckenfels zu Freies WLAN Karlsruhe (not!)
2010-01-10 15:13

Nach meiner Quizzfrage gab es einige Diskussionen über das Problem. Meine Analyse fand ein Problem im Konstruktur der Klasse Thread. Wannimmer ein Thread Objekt erzeugt wird, registriert es sich an der zugehörigen (aktuellen) ThreadGroup. Das hat den Effe
Aufgenommen: Aug 06, 23:35