You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The timeout in TimerTask is not ensuring tasks are not allowed to continue
processing after the timeout has passed. This can lead to threads leaking since
TimerTask will try to run the provided task again before the previous execution
has completed. Yet TimerTask will not allow the task to run in parallel so more
and more worker threads will be queued up waiting to be scheduled for executing
the task.
To illustrate, imagine running a TimerTask with an execution interval of 1 and
a timeout interval of 1, with the task itself running for 4 seconds.
Time 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
Worker1 s> t - - < > t . . . . . - - - <
Worker2 s > t . - - - < > t . . . . .
Worker3 s > t . . . - - - < > t .
Worker4 s > t . . . . . . .
Worker5 s > t . . .
At t=1 worker 1 is spawned(s) and scheduled(>) and will start executing
the task. It will timeout(t) after 1 second and cause the spawning of worker 2.
Worker 2 will then wait 1 second to be scheduled and then another second to
timeout causing the spawn of worker 3 at t=4.
Worker 3 is then scheduled to start at t=5 and will timeout at t=6. At this
point worker 1 has completed it's previous task so the task queued by worker 3
will go to worker 1 to be scheduled for t=7. At t=8 worker 1 will timeout and
since worker 2 is currently executing(-) and worker 3 is current waiting(.) for
worker 2 to completed worker 4 will be spawned.
This patterns will continue to repeat with new workers/threads spawned every 4
seconds.
0 commit comments