Menu
I am writing a fairly complex Java server application which has a significant background processing portion in addition to the usual request-response processing. Some of the background processing is done in a cron-like fashion using Quartz framework. Other tasks are more of on demand - if a new client connects it creates additional job for updating it once in a while. The cron tasks can also be varied - some do monitoring of external applications, some calculate statistics and so on.
I am using a number of thread pools to run all those jobs with the idea that similar jobs will share a thread pool but different jobs will not share one. For example monitor jobs will never run on statistics pool, and statistics jobs will never run on monitor pool.
On the other hand I know some people would prefer just to have a single thread pool and run everything on it without any separation.
I wonder what is considered the best practice in such a scenario.
What are the pros an cons of separating thread pools?
Does it even matter?
751
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.
By default, the MaxThreads of the ThreadPool is very high. Usually you'll never get there, your app will crash first. So when all threads are busy the new tasks are queued and slowly, at most 1 per 500 ms, the TP will allocate new threads.
We can create the following 5 types of thread pool executors with pre-built methods in java. util. concurrent.
If the server doesn't have enough threads, the server will wait until a thread becomes available before processing a request. In extreme cases, those requests that get queued may never get processed, if the wait time exceeds a server timeout value.
The answer depends on whether you need to segregate application resources between different types of activity or not.
For example, I am currently writing a server application consisting of a few high-throughput writers and potentially many readers. Readers will access the app sporadically but could potentially request a lot of data (i.e. long running requests). I need to ensure that writers are never starved so am going to use two thread pools in my design for reading / writing. If the reader thread pool is temporarily exhausted the writers will be unaffected; only read requests will be delayed.
An alternative would have been to use a PriorityQueue in conjunction with a ThreadPoolExecutor and assign a higher priority to write requests.
So in conclusion - My advice would be: Start off with one thread pool and only make your design more complex if there's a concrete reason for doing so.
127
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
