ThreadPoolExecutor's queuing behavior customizable to prefer new thread creation over queuing?

Question

ThreadPoolExecutor doc says

If corePoolSize or more threads are running, the Executor always prefers queuing a request rather than adding a new thread.

If there are more than corePoolSize but less than maximumPoolSize threads running, a new thread will be created only if the queue is full.

Is there a way to get the executor to prefer new thread creation until the max is reached even if there are there are more than core size threads, and then start queuing? Tasks would get rejected if the queue reached its maximum size. It would be nice if the timeout setting would kick in and remove threads down to core size after a busy burst has been handled. I see the reason behind preferring to queue so as to allow for throttling; however, this customization would additionally allow the queue to act mainly as a list of tasks yet to be run.

Answer 1

No way to get this exact behavior with a ThreadPoolExecutor.

But, here's a couple solutions:

1. Consider,

   • If less than corePoolSize threads are running, a new thread will be created for every item queued until coorPoolSize threads are running.

   • A new thread will only be created if the queue is full, and less than maximumPoolSize threads are running.

   So, wrap a ThreadPoolExecutor in a class which monitors how fast items are being queued. Then, change the core pool size to a higher value when many items are being submitted. This will cause a new thread to be created each time a new item is submitted.

   When the submission burst is done, core pool size needs to be manually reduced again so the threads can naturally time out. If you're worried the busy burst could end abruptly, causing the manual method to fail, be sure to use allowCoreThreadTimeout.

2. Create a fixed thread pool, and allowCoreThreadTimeout

   Unfortunately this uses more threads during low submission bursts, and stores no idle threads during zero traffic.

Use the 1st solution if you have the time, need, and inclination as it will handle a wider range of submission frequency and so is a better solution in terms of flexibility.

Otherwise use the 2nd solution.