TimerTask destruction

[Jeff]

For a one time Timer, after the TimerTask's run method is executed, is the
TimerTask available to be garbage collected? I'm having a hard time proving
it, but I think the TimerTask persists after run() is executed. I could fix
it by explicitly calling .cancel() from the TimerTask, but I suspect the
language designers had a better solution in mind.

In this example, is FireJeffAlarm eligable for garbage collection after it's
run() is done?

Thanks

class JeffTimer extends java.util.Timer {

JeffTimer() {
schedule( new FireJeffAlarm() , 2000 );
System.out.println( " scheduled alarm" );
}

class FireJeffAlarm extends TimerTask {
public void run() {
System.out.println( "firing Jeff Alarm " );
} // run

} // FireJeffAlarm

public static void main( String args[] ) {
JeffTimer timer = new JeffTimer();
}

}

 

[Paul Lutus]

For a one time Timer, after the TimerTask's run method is executed, is the
TimerTask available to be garbage collected? I'm having a hard time
proving
it, but I think the TimerTask persists after run() is executed. I could
fix it by explicitly calling .cancel() from the TimerTask, but I suspect
the language designers had a better solution in mind.

In this example, is FireJeffAlarm eligable for garbage collection after
it's run() is done?

"eligable" -> eligible

There's a way to find out:

1. Create and run the timer. Let it run to completion, however you define
that.

2. In a separate repeating Timer thread (or a GUI with comand buttons),
monitor the status of the object (you will have to assign the TimerTask
object in a way that you are not doing now).

3. Call System.gc(), then, later, test for the presence or absence of a
valid TimerTask object.

 

[Gordon Beaton]

For a one time Timer, after the TimerTask's run method is executed,
is the TimerTask available to be garbage collected? I'm having a
hard time proving it, but I think the TimerTask persists after run()
is executed. I could fix it by explicitly calling .cancel() from the
TimerTask, but I suspect the language designers had a better
solution in mind. In this example, is FireJeffAlarm eligable for
garbage collection after it's run() is done?

Have a look at the implementation of Timer, or more speicfically, the
implementation of the TaskQueue inner class. The source comes with the
JDK.

The TimerTask is removed from the queue when it fires, and the queue
position it occupied is set to null.

You can't predict when gc will occur, so don't expect the object to be
collected immediately after it runs (or even soon after if there is
lots of memory available).

/gordon

 

[Jeff]

Thanks for the pointer to TaskQueue. That's very helpful. I'll look at
that code.

 

[Liz]

For a one time Timer, after the TimerTask's run method is executed, is the
TimerTask available to be garbage collected? I'm having a hard time proving
it, but I think the TimerTask persists after run() is executed. I could fix
it by explicitly calling .cancel() from the TimerTask, but I suspect the
language designers had a better solution in mind.

In this example, is FireJeffAlarm eligable for garbage collection after it's
run() is done?

After it is done you can get the list of threads and see if it is still
there.

Thanks

class JeffTimer extends java.util.Timer {

JeffTimer() {
schedule( new FireJeffAlarm() , 2000 );
System.out.println( " scheduled alarm" );
}

class FireJeffAlarm extends TimerTask {
public void run() {
System.out.println( "firing Jeff Alarm " );
} // run

} // FireJeffAlarm

public static void main( String args[] ) {
JeffTimer timer = new JeffTimer();
}

}



--
Jeffrey Drew
President and Founder
Trading Metrics, Inc.
917-453-0302