[concurrency-interest] Unexpected bevahiour in ThreadPoolExecutor

Andrew Certain andrew_certain_concurrency at thecertains.com
Thu Jan 4 17:14:26 EST 2007

I've been using a ThreadPoolExecutor with corePoolSize == maxPoolSize,
expecting that I'd always have a fixed number of threads to operate on
tasks in the queue.  However, if a thread throws an exception and
terminates unexpectedly, no thread is spawned to replace it unless it's
the last thread in the pool, even if the task queue is full.  Looking at
the code, it seems that new threads are only spawned when execute is
called.  However, this behavior is at best unexpected (and I would
consider it a bug), especially in the following scenario:

You create a ThreadPoolExecutor (TPE) with corePoolSize = maxPoolSize = n.  
You then submit N >> n long-running tasks to the TPE at the start and 
never submit another task.  If one of those long-running tasks throws an 
exception and terminates, a new thread is not respawned, leaving you with 
n-1 threads to service the large number of tasks left in the queue.  If 
this happens frequently enough, you're left with only one thread in the 
pool (since workerDone will spawn a new thread if there is something in 
the queue and there are no more threads).

Am I doing something wrong with my usage of the TPE?  Surely the behavior 
I'm expecting (submit a bunch of tasks to a thread pool with a fixed 
number of threads at startup time and wait until they terminate) isn't 
unique.  Are there any good solutions?  Why wouldn't workerDone spawn
new threads if there are less than corePoolSize threads running and there 
is work in the queue?



Please include this line when replying.
Clunk enough people on the head and we'll have a nation of lunkheads.
		-- Foghorn Leghorn

More information about the Concurrency-interest mailing list