Ideally from any Thread Pool Executor, the expectation would be the following
- An initial set of threads (core threads pool size) created up front, to handle the load.
- If the load increases, then more threads should be created to handle the load up to max threads (Max pool size)
- If the number of threads increases beyond Max Pool Size, then Queue up the tasks.
- If Bounded Queue is used, and the queue is full then bring in some rejection policy.
The following diagram depicts; only initial threads are created to handle tasks (When load is very low).
As more task come in, more threads are created to handle the load (Task queue is still empty), if total number threads created is less than max pool size.
Task Queue getting filled up if total number of tasks is more than total number of threads (initial + extended)
Unfortunately, Java Thread Pool Executor (TPE) is biased towards queuing rather than spawning new threads, i.e., after the initial core threads gets occupied, tasks gets added to queue, and after the queue reaches its limit (Which would happen only for bounded queue), extra threads would be spawned. If the queue is unbounded then extended threads won’t get spawned at all, as depicted in the following image.
1==> Initial Core threads were created to handle the load
2==> Once there are more tasks than number of core threads, queue starts getting filling up, to store the tasks
3==> Once the queue is filled, extended threads are created.
Here is the code in TPE, which has problem
We have got couple of work around:
Work Around #1
Set the corePoolSize and maximumPoolSize to same value and set allowCoreThreadTimeOut to true.
- No coding hack required
- There is no real caching of threads as threads are getting created and terminated quite often.
- There is no proper scalability.
Work Around #2
- Override the offer method of delegator TransferQueue, and try to provide the task to one of the free worker threads, return false if there is no waiting threads,
- Implement custom RejectedExecutionHandler to always add to Queue.
Refer this implementation for more detail
- TransferQueue ensures that threads are not unnecessarily created, and transfers the work directly to waiting thread.
- Customized rejection handler cannot be used, since it is used to insert the the tasks to queue.
Work Around #3
Use custom queue (TransferQueue) and override the offer method to do the following
- try to transfer the task directly to waiting thread (if any)
- If above fails, and max pool size is not reached then create extended thread by returning false from offer method
- otherwise insert into queue
Refer this implementation for more detail.
- TransferQueue ensures that threads are not unnecessarily created, and transfers the work directly to waiting thread on the queue.
- Custom Rejection Handler can be used.
- There is a cyclic dependency between Queue and Executor.
Work Around #4