JDK ThreadPoolExecutor NOT.

08:16AM Jun 20, 2015 in category General by Zoltan Farkas

I have finally reached my patience with the JDK thread pools....

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:

http://stackoverflow.com/questions/15485840/threadpoolexecutor-with-unbounded-queue-not-creating-new-threads

http://stackoverflow.com/questions/19528304/how-to-get-the-threadpoolexecutor-to-increase-threads-to-max-before-queueing/19528305#19528305

To resolve 2) Using Lifo scheduling resolves the issue. This idea was presented by Ben Maurer at ACM applicative 2015 conference:
https://www.youtube.com/watch?v=dlixGkelP9U&feature=youtu.be&list=PLn0nrSd4xjjZoaFwsTnmS1UFj3ob7gf7s

So a new implementation was born:

https://github.com/zolyfarkas/spf4j/blob/master/spf4j-core/src/main/java/org/spf4j/concurrent/LifoThreadPoolExecutorSQP.java

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.

Enjoy!



Comments[0]

Comments:

Post a Comment:
Comments are closed for this entry.