[concurrency-interest] A thread pool for servers?

Martin Buchholz martinrb at google.com
Fri Sep 11 17:51:29 EDT 2015


Colleague Douglas Dickinson at Google pointed out that none of the
convenience executors in Executors is truly resource bounded.

I've never run a "production Java server", but trying to bound resource
usage so that your server doesn't die with OOME or gc thrashing seems
important.  So your thread pool needs to be bounded in the number of
threads *and* in the size of the queue, and be prepared to handle task
rejection sensibly.

So it makes sense to me to add another convenience method to Executors that
will act like newFixedThreadPool but will additionally have a bounded
queue.  It's not completely obvious whether ArrayBlockingQueue or
LinkedBlockingQueue is the better choice for the bounded queue, but I
suspect for "serious servers" it's the former, because:
- modern server environments tend to like pre-allocating all their
resources at startup
- there's little GC overhead to the "dead weight" of the
ArrayBlockingQueue's backing array (a single object!)
- LinkedBlockingQueue will allocate many more small objects, and servers
don't like that
- with today's economics, "memory is cheap"

(and of course, we can try to write an actual better bounded thread pool
not based on ThreadPoolExecutor, but that's actually hard)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20150911/0412ad83/attachment.html>


More information about the Concurrency-interest mailing list