Timer-Objekt und Garbage Collector

[Petroy]

Hallo. Ich habe eine Frage zu folgendem Code :

	void eineMethode() {
		Timer t = new Timer();
		t.schedule(new TimerTask() {

			@Override
			public void run() {
				// Irgendwelche Anweisungen
				
			}
			
		}, 5000);
	}

Beim Aufruf dieser Methode wird ein Timer-Objekt erstellt. Dieses wird aber nicht wie alle anderen Variablen in der Methode nach deren Ausführung gelöscht. Nach dem Ende der Methode existiert dieser Timer immer noch im RAM und nach 5 Sekunden wird run() im TimerTask ausgeführt.

Nun die Frage:
Löscht der Garbage Collector den Timer nach der Ausführung von run() ?

Gruß,
Petroy

 

[Wildcard]

schedule trägt den Task in eine Queue ein. Ist er aus der Queue entfernt, und keine weitere starke Referenz vorhanden, wird er eingesammelt.

 

[Beni]

Sehr wahrscheinlich haben die Leute bei Sun was gedacht als sie Timer schrieben und kein Memoryleak produziert -> es wird gelöscht :wink:

[Edit: hmpf, Wildcards Erklärung ist viel besser als meine :? ]

 

[Petroy]

:lol: vielen Dank für die schnellen Antworten. Ich konnte mir auch nicht vorstellen, dass es anders ist. Aber mein Programm erstellt sehr viele Timer-Objekte in kurzer Zeit (bedingt durch die Animation einer SVG-Grafik) und im Taskmanager habe ich festgestellt, dass javaw.exe kontinuierlich immer mehr RAM-Speicher schluckt. Aber dann muss dieser Effekt wohl woanders her kommen.

 

[Wildcard]

Der Speicher den der Prozess belegt ist nicht immer der Speicher den dein Programm braucht.
Solange du keinen agressive GC verwendest, wird der GC einmal allokierten Speicher nicht wieder ans OS zurückgeben, solange er das nicht für nötig erachtet. Interssant ist eher die XMX Grenze, bzw, ob du einen OutOfMemoryError bekommst.

 

[Beni]

Ah, und die API hat natürlich auch noch was dazu zu sagen (java.util.Timer):

After the last live reference to a Timer object goes away and all outstanding tasks have completed execution, the timer's task execution thread terminates gracefully (and becomes subject to garbage collection). However, this can take arbitrarily long to occur. By default, the task execution thread does not run as a daemon thread, so it is capable of keeping an application from terminating. If a caller wants to terminate a timer's task execution thread rapidly, the caller should invoke the timer's cancel method.

-> es wäre eine gute Idee den Timer zu canceln, aber es ist nicht notwendig. Irgendwann wird er abgeräumt. Allenfalls lohnt es sich auch denselben Timer mehrfach zu verwenden.

 

[Petroy]

alles klar, vielen Dank. Auf die Idee, dass in den API-Docs etwas stehen könnte, bin ich noch gar nicht gekommen.

länger als fünf Minuten hab ich das Programm noch nicht laufen lassen, und in dieser Zeit ist noch kein OutOfMemoryError aufgetreten. Ich werd das Ganze erst mal ignorieren. Bin sowieso erst mal froh, dass die ganze Sache überhaupt funktioniert, da es Ewigkeiten gebraucht hat, bis ich diese SVG animiert bekommen hab.