Fixed Thread pool has been used to limit the number of threads in java application by passing an integer variable to the executors method like below
Executors.newFixedThreadPool(10);
Suppose we are designing any application and we are using fixed thread pool then how can we take up a decision for an ideal fixed thread pool size or on what basis we should decide the fixed thread pool size ?
First of all,
1.) Are you creating a FixedThreadPool for the whole application or for specific task in your application?
2.) The server on which your application is deployed, supports how many CPU's, per CPU how many threads?
3.) There might be a case, where you are allocating fewer threads than the server has, or might allocate more, and your tasks doe not require that many. It is more or less a waste of resources.
Thread pool sizes should rarely be hard-coded; instead pool sizes should be provided by a configuration mechanism or computed dynamically by consulting Runtime.availableProcessors.
For more, Java Concurrency in Practice has a detailed chapter on thread pools.
If you are looking for a formula based methodology there is little - of course you can get the information on how many cores are supported but it's important to remember that if you are deploying your application in a container and your application is built using frameworks and libraries you might already have many thread pools created in your system providing multiple services. And on top of that the kind of work (CPU/IO intensive would also play important role). So your best bet would be to start with some number and then profile your application and get that sweet spot. A good guess to begin with ( if you are unsure of the environment of your application) can be made from here. You can easily see all the threads in your application by connecting with Jconsole and a summary can be seen in MBeans -->java.lang --> Threading -->Attributes.
In the end - the empirical evidence is the best in these cases.
