ThreadPoolExecutor and Pool Sizes Quirk
ThreadPoolExecutor and Pool Sizes Quirk is brought to you in partnership with:

Vitalii has posted 2 posts at DZone. View Full User Profile

ThreadPoolExecutor and Pool Sizes Quirk

11.01.2010
| 7649 views |
  • submit to reddit

We Recommend These Resources

I recently ran into a problem while using ThreadPoolExecutor. As you probably know, ThreadPoolExecutor takes (among the others), two parameters - corePoolSize and maximumPoolSize. Also by default (and in Java5 you can't change the default) it never stops threads from the "core" pool.

So I've tried to set corePoolSize quite low and raise maximumPoolSize. After some checks I could see that my pool does not behave as expected - I've got very long queue and only core pool threads started. After going deeper into the documentation I've found this:

If there are more than corePoolSize but less than maximumPoolSize threads running, a new thread will be created only if the queue is full.
And I've used unbounded queue. So, basically, with unbounded queue one should never make maximumPoolSize larger then corePoolSize (at least this won't make any impact - no more then core pool threads will be created).
0
Your rating: None
Published at DZone with permission of its author, Vitalii Tymchyshyn.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Liam Knox replied on Mon, 2010/11/01 - 6:32am

I think the JavaDoc clears that up but I can accept your frustration.  Tome this is classic example where you should beable to assume a default behave as that stated, but inject your own growth policy if you wish.

Jess Holle replied on Mon, 2010/11/01 - 10:20am

Yes, the documented behavior is rather frustrating and should be just an option (and not the default one...)

I griped about this on another forum and got the following response:

Take a look at the custom ThreadPoolExecutor subclass in the
SwingWorker source code (Java 6 only). I believe it is the behaviour
that you want.

 

Oleksandr Alesinskyy replied on Wed, 2010/11/03 - 5:44pm

There is another quirk in the ThreadPoolExecutor - there is no easy way to make execute() to wait if the queue is full.

Liam Knox replied on Wed, 2010/11/03 - 6:19pm in response to: Jess Holle

If you do accept the current behaviour as the default though you can atleast adapt the existing API with a non breaking compatability change to support more flexible characteristics.

Vitalii Tymchyshyn replied on Fri, 2010/11/05 - 8:12am in response to: Oleksandr Alesinskyy

Yes, and using unbounded queue can give you all the problems of working without flow control.
Here is workaround I use:
new RejectedExecutionHandler() {
				public void rejectedExecution(Runnable r, ThreadPoolExecutor executor) {
					try {
						executor.getQueue().put(r);
					} catch (InterruptedException e) {
						throw new RuntimeException(e);
					}
				}
			}
Pass this to ThreadPoolExecutor executor constructor and you will get flow control.
P.S. Of course you will need a bounded queue for RejectedExecutionHandler to be used

County Line Nissan replied on Mon, 2011/08/01 - 10:35am

The difference is that the users want to start increasing the pool size earlier and want the queue to be smaller, where as the Sun method want to keep the pool size small and only increase it once the load becomes to much. -County Line Nissan

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
"Starting from scratch" is seductive but disease ridden
-Pithy Advice for Programmers