[concurrency-interest] Unbounded thread pool and memory overhead

Rohit Reja rreja2000 at yahoo.com
Mon Aug 25 01:25:50 EDT 2014


We are using Executors#newCachedThreadPool() at various places in our product. We recently faced an issue that the threads consumed lots of virtual memory in a machine ( and eventually the system has no memory left) due to lots of threads being created. ( We haven't set the Xss param though).

I have 2 questions here:-

1. Why have this API choose not to have bounded threads ? What would be the best practices while using unbounded thread pools.
2. How can I build a thread pool with a minimum threads that grows to a max bound and then the task submission blocks?


On Thursday, August 14, 2014 6:03 PM, Victor Grazi <vgrazi at gmail.com> wrote:

There's a nice article by Dr. Heinz Kabutz on InfoQ http://www.infoq.com/articles/Hunting-Concurrency-Bugs-1
Heinz always amazes me!

Twitter: @vgrazi
LinkedIn: www.linkedin.com/in/victorgrazi/
Java Concurrent Animated: http://sourceforge.net/projects/javaconcurrenta/
Skype: vgrazi2

Google Plus
Concurrency-interest mailing list
Concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20140824/2125ff9c/attachment.html>

More information about the Concurrency-interest mailing list