[concurrency-interest] ThreadPool with maximum idle thread size?

Joe Bowbeer joe.bowbeer at gmail.com
Mon Dec 18 17:00:56 EST 2006


Executors.newCachedThreadPool does not maintain a core pool of threads
and sheds idle threads after 60 seconds.

Can you compare the desired behavior to that of a cached thread pool?

Can tuning the keepAlive time achieve the desired result?  (Or it the
case that you want to avoid futzing around and just want a drop-in
replacement?)

Also note that ThreadPoolExecutor.allowCoreThreadTimeOut was added in Java 6.


On 12/18/06, Sam Berlin <sberlin at gmail.com> wrote:
> Hi Folks,
>
> I'm looking into converting some of our custom thread pools to use
> Java 5's concurrent package.  This will eliminate some of the bugs
> with our packages, and let the code be a bit more interoperable with
> other libraries.  One thing I'm looking for in the concurrent pools is
> the ability to limit the number of idle threads.  I see settings for
> the 'core size' (the number that will always remain alive, once
> started), the 'maximum size' (the number to allow at most), and the
> length of time that threads over the core size will remain alive, but
> I don't see anything that can limit the number of idle threads.  The
> goal behind this is to allow the threads to be created during peak
> times (and thus the maximum size can't be used), but to not allow them
> to linger for so long.  An alternative to a maximum idle size could be
> a variable linger time, depending on how many idle threads there are
> (for instance, > 0 idle == 5 seconds linger, > 5 == 2 seconds linger,
> > 15 == no linger).
>
> I've looked into the source to see if it's possible to do this by
> subclassing ThreadPool and inserting hooks, but there doesn't seem to
> be any easy way.
>
> Any suggestions, or reasons why this functionality may not be a good idea?
>
> Thanks,
>  Sam
>


More information about the Concurrency-interest mailing list