1) JDK thread pools are biased towards queuing. So instead of spawning a new thread, they will queue the task. Only if the queue reaches its limit will the thread pool spawn a new thread.
2) Thread retirement does not happen when load lightens. For example if we have a burst of jobs hitting the pool that causes the pool to go to max, followed by light load of max 2 tasks at a time, the pool will use all threads to service the light load preventing thread retirement. (only 2 threads would be needed…)
Unhappy with the behavior above, I went ahead and implemented a pool to overcome the deficiencies above.
To resolve 1) there are several “hacks” using the existing JDK pools:
To resolve 2) Using Lifo scheduling resolves the issue. This idea was presented by Ben Maurer at ACM applicative 2015 conference:
So a new implementation was born:
So far this implementation improves async execution perfomance for ZEL (http://zolyfarkas.github.io/spf4j/spf4j-zel/index.html).
The implementation is spin capable to reduce context switch overhead, yielding superior performance for certain use cases.