[concurrency-interest] A thread pool for servers?
davidcholmes at aapt.net.au
Fri Sep 11 19:46:02 EDT 2015
All those requirements suggest direct use of a thread pool constructor not a “convenience” method. You get to set the size of the pool, the type and size of queue and the rejection policy.
From: concurrency-interest-bounces at cs.oswego.edu [mailto:concurrency-interest-bounces at cs.oswego.edu] On Behalf Of Martin Buchholz
Sent: Saturday, September 12, 2015 7:51 AM
To: concurrency-interest; Douglas Dickinson
Subject: [concurrency-interest] A thread pool for servers?
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...
More information about the Concurrency-interest