I have a situation where I expect adding to the thread pool to be faster than processing. I don’t think an unbounded queue will be a good idea because there is enough data that the queue might grow to eat all memory if left unchecked. Given this I’m trying to determine the correct setup for a ThreadPoolExecutor.
My first thought is a fixed thread pool with direct handoff and caller runs failure policy. But I wonder if this will hurt throughput (because every time caller runs policy is invoked the thread pool tasks will likely complete and sit idle for some time).
Another idea is fixed thread pool with ArrayBlockingQueue, but I’m actually not sure of the behavior of that. I’m hoping it means that the Executor prefers creating threads if less than coreThread size, then queues, and if the queue is full it blocks waiting for the queue to get space. But in reading the docs here:
http://docs.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/ThreadPoolExecutor.html
It seems that it will prefer creating threads up to corePoolSize, then add to the queue, and if the queue is full it will try creating threads up to maxThreads (same as coreThreads in this case), and failing that it will run the failure policy.
Can someone clarify the behavior for the case above? And also suggest what the best setup might be for this particular case (one of my suggested ideas or some other one that might work better)?
I figure I make this another answer because its a different solution to the same problem.
You can use just a ThreadPoolExecutor and Semaphore. The semaphore would be created with the max number you want to allow in the queue and after each thread finishes execution, you would invoke release (beforeExecute, which is when the item is pulled off the queue)
So here all threads will suspend until there is a permit available (entry on the queue).