Is an unbounded thread pool right for futures?

[Stuart Sierra]

Clojure's Agent send-off and Futures dispatch through a ThreadPoolExecutor using the default configuration:

• a MaximumPoolSize of Integer/MAX_VALUE
• a SynchronousQueue as the input queue.

According to JavaDoc this "admits the possibility of unbounded thread growth when commands continue to arrive on average faster than they can be processed."

For Agent send-off this is not a problem, because the Agent has its own queue and the number of Agents limits the maximum possible number of threads.

But what about Futures? Nothing prevents an application from spawning tens of thousands of Futures, causing the ThreadPoolExecutor to spawn tens of thousands of threads, quickly leading to OutOfMemoryError.

Should Futures use a different thread pool? Or should the soloExecutor be given a maximum pool size and an unbounded queue? There may not be a perfect answer for every application, but it seems like some protection from the unbounded thread growth case would be a good idea.

-S

[Timothy Baldridge]

You run the risk of deadlocks with this modification. If your thread pool contains n number of threads, and you queue up n+1 futures where each derefs the future ahead of it, the n+1 future will never start execution, and thus deadlock the entire thread pool. So you have to be careful about the order of allocation of futures. 

Something I've thought about in the past, is a sort of elastic ThreadPool. Here threads would only be allocated if no future as terminated in X amount of time. There would also need to be a watchdog thread that would occasionally query the backlog of futures every X amount of time and spin up threads for those items. 

Timothy