[concurrency-interest] Whats up with the ThreadPoolExecutor?

Joshua Bloch jbloch at gmail.com
Tue Aug 23 01:37:28 EDT 2005

It was not an accident that you can't reuse a finished timer task.  It
was a conscious design decision, based the principal that one should
minimize mutability (keep the state space of a object as simple as
possible).  In fact, I use it as an example of good API design in my
API design talk.  I would be very, very surprised if you could come up
with a realistic example of a program whose performance is noticeably
improved by reusing timer tasks.


On 8/22/05, Gregg Wonderly <gergg at cox.net> wrote:
> Doug Lea wrote:
> > David Holmes wrote:
> >
> >>
> >> There is an easy fix that Dawid can hopefully get into the backport in
> >> the
> >> very near future:
> >
> >
> > And the fix for the java.util.concurrent version will with some luck be
> > in Mustang.
> >
> > While we never expected anyone to reuse Runnable tasks
> > in this way, (and in general, it is not a good idea)
> > the specs did not say you cannot, so it is indeed a bug.
> I've recently made changes to Timer to allow TimerTasks to be reused so that a TimerTask can reschedule the same object
> into the future without a lot of garbage being generated for fast cycling tasks with odd repeating intervals.  I think
> it makes a lot of sense to try and work towards reducing garbage generation by not requiring new objects.  There are, of
> course some interesting issues, such as this one...
> Gregg Wonderly
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu
> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest

More information about the Concurrency-interest mailing list