[concurrency-interest] ThreadPoolExecutor corePoolSize incompatibility between backport and j.u.c.

Ben Manes ben_manes at yahoo.com
Sat Aug 16 14:59:17 EDT 2008

It is in the JavaDoc.  Setting the core size to 1 only fixed the problem by making one thread available, but it will never grow.  If you really want this behavior, there are tricks to do it.


Core and maximum pool sizes
A ThreadPoolExecutor will automatically adjust the pool size (see getPoolSize()) according to the bounds set by corePoolSize (see getCorePoolSize()) and maximumPoolSize (see getMaximumPoolSize()). When a new task is submitted in method execute(java.lang.Runnable), and fewer than corePoolSize threads are running, a new thread is created to handle the request, even if other worker threads are idle. If there are more than corePoolSize but less than maximumPoolSize threads running, a new thread will be created only if the queue is full. By setting corePoolSize and maximumPoolSize the same, you create a fixed-size thread pool. By setting maximumPoolSize to an essentially unbounded value such as Integer.MAX_VALUE, you allow the pool to accommodate an arbitrary number of concurrent tasks. Most typically, core and maximum pool sizes are set only upon construction, but they may also be changed dynamically using setCorePoolSize(int) and setMaximumPoolSize(int).

Unbounded queues. Using an unbounded queue (for example a LinkedBlockingQueue without a predefined capacity) will cause new tasks to be queued in cases where all corePoolSize threads are busy. Thus, no more than corePoolSize threads will ever be created. (And the value of the maximumPoolSize therefore doesn't have any effect.) This may be appropriate when each task is completely independent of others, so tasks cannot affect each others execution; for example, in a web page server. While this style of queuing can be useful in smoothing out transient bursts of requests, it admits the possibility of unbounded work queue growth when commands continue to arrive on average faster than they can be processed.

----- Original Message ----
From: Greg Luck <gluck at gregluck.com>
To: concurrency-interest at cs.oswego.edu
Sent: Saturday, August 16, 2008 4:54:53 AM
Subject: [concurrency-interest] ThreadPoolExecutor corePoolSize incompatibility between backport and j.u.c.

I am looking at moving the new version of ehcache to j.u.c, from backport, as part of dropping support for Java 1.4.

It turns out that all my tests which test code that uses backport's ThreadPoolExecutor never complete. The code which supplies the executor is shown below:

     * @return Gets the executor service. This is not publically accessible.
    ThreadPoolExecutor getExecutorService() {
        if (executorService == null) {
            synchronized (this) {
                //0, 10, 60000, ?, Integer.MAXVALUE
                executorService = new ThreadPoolExecutor(0,10,
                       60000, TimeUnit.MILLISECONDS, new LinkedBlockingQueue());
        return executorService;

Without understanding exactly why, I tried changing the corePoolSize to 1. This fixed the problem. My question is why? There is nothing in the JavaDoc I can see which says you must use a minimum of 1. 

And I am now worried that j.u.c. is flaky in Java 5.  Any comments from the list would be much appreciated.


Greg Luck

web: http://gregluck.com
skype: gregrluck
yahoo: gregrluckmobile: +61 408 061 622

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20080816/19fc853e/attachment.html>

More information about the Concurrency-interest mailing list