Menu
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.
399
A thread pool is a collection of threads which are assigned to perform uniformed tasks. The advantages of using thread pool pattern is that you can define how many threads is allowed to execute simultaneously.
Thread pools do not make sense when you need thread which perform entirely dissimilar and unrelated actions, which cannot be considered "jobs"; e.g., One thread for GUI event handling, another for backend processing. Thread pools also don't make sense when processing forms a pipeline.
Creating a thread pool is a relatively expensive operation which can take milli-seconds. You don't want to be doing this many times per second.
Ideally, there is no fixed number which is ideal to be used in deciding the number of threads pool. It all depends on the use-case of the java program. Therefore, there are two factors on which decision should be taken to decide the thread pool size.
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.
102
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.
38
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
