What are the advantages and disadvantages of having more than one threadpool in Java? I have seen code where there are multiple threadpools for different "types" of tasks, and I'm not sure whether its better design or just developers being lazy. One example is using a ScheduledThreadPoolExecutor for tasks that are executed periodically or have a timeout, and use another ThreadPoolExecutor for everything else.
Asked
Active
Viewed 1.0k times
2 Answers
31
The purpose of having separate dedicated threadpools is so that an activity doesn't get starved for threads because other activities took all the threads. If some service has its own threadpool then it is assured of having a certain number of threads at its disposal and it's not as sensitive to demands made by other services.
OS Threads are a limited resource. If you have an application that uses threads for different purposes, some of them might become busy and keep a lot of threads working for them, or some service might have a bug where in some circumstance a thread isn't returned to the pool. If that can happen to one thread, the same circumstance may be applicable to all of the threads, and a whole thread pool can be drained this way. (There is an example early on in the Release It! book describing a situation where a database was being switched over, and badly-written JDBC code caused a leak like this.)
With the multiple dedicated threadpools if a service needs too many threads then it has to wait for threads to be available, introducing back-pressure into the system so that it degrades gradually, and since other parts have their own thread pools they have a chance to catch their parts up. So the idea is that the system should have more stable characteristics as load changes. In the case you describe having a separate threadpool for scheduled tasks makes sure that those tasks get run regardless of how busy the rest of the system is.
The multiple threadpools would require tuning to make sure each pool had enough threads and not too many. With a single threadpool then that might reduce the number of idle threads and might make better use of more threads, but you would not have the predictability of knowing some important task would get the threads it needed to finish in a timely manner.
Nathan Hughes
- 94,330
- 19
- 181
- 276
-
so if i have 4 core processor and let's assume 12 fixed size threadpools of size 4, half of them handle very CPU intensive tasks, How will java going to manage these threadpools ?? Does JVM has any inbuilt function to prevent starvation or do we have implement our own, when using multiple threadpools ?? – DeepSidhu1313 Mar 11 '18 at 17:42
-
1@DeepSidhu1313: the jvm doesn't do anything to prevent starvation. – Nathan Hughes Mar 11 '18 at 20:11
-
@DeepSidhu1313 the VM can schedule far more threads than the available processors, but it very well may get tied up if your processes tie up too many resources. You may consider introducing small sleep() or yields to allow other threads to run. Alternatively using the new virtual threads feature could possibly improve performance a lot more. Generally threads get stopped for IO so it works well.. but if it's CPU intensive pay attention to how many cores you are allocating.. I wouldn't give it 100% – AminM Apr 11 '23 at 20:52
6
Having a single thread pool is NOT a good design because in case of 1 thread pool, if one part of the application becomes slower, threads will concentrate there. If proper timeouts are not implemented, threads will stay and consume resources. A lot of such threads and connections can cause our system to break as no threads will be left for new requests.
On the other hand, having multiple thread pools ensures that issue is contained and does not become a system-wide failure. We can have different thread pools for accepting connections, running batch jobs, talking to remote api's databases. It does reduce efficiency to some extent but makes our system robust and fault tolerant.
Ankit Arora
- 132
- 1
- 8
-
4I think that saying it's NOT a good design is too presumptive. It's a great design if your app only does essentially one thing. But even with a heterogenous workload, as you add more pools it becomes harder to understand and introspectively limit your resource consumption. So you'll probably just starve at the physical layer. Use separate thread pools for classes of workload that shouldn't starve each other. But if that's the case, you should probably split the whole service and insure they can't starve beneath the application layer. – kylejmcintyre Oct 06 '20 at 21:08