lolski
lolski

Reputation: 17511

What happens when a single program has multiple `ThreadPoolExecutor`s?

A ThreadPoolExecutor instance manages threads: it is responsible for match-making tasks in its queue to a set number of threads.

Given that threads are common resources, intuitively they should be managed by "one manager" per application.

However, there exists "best practices" that tells you to create multiple executors for some scenario. For example, there are beliefs that you should create two separate executors, one for CPU bound tasks and another for blocking IO tasks.

Why is that so?

Intuitively, having multiple "managers" managing the same set of threads, without being aware of each other's existence sounds like an anti-pattern to me.

Is the JVM aware of the existence of multiple executors and perform additional management to ensure they never fight over the same thread?

Upvotes: 0

Views: 2247

Answers (1)

Alex Sveshnikov
Alex Sveshnikov

Reputation: 4339

I really recommend you to take a look on "Java concurrency in Practice" book.

Just some quotes from Chapter 8:

Thread pools work best when tasks are homogeneous and independent. Mixing long-running and short-running tasks risks "clogging" the pool unless it is very large; submitting tasks that depend on other tasks risks deadlocks unless the pool is unbounded.

...

Thread pools can have responsiveness problems if tasks can block for extended periods of time, even if deadlock is not a possibility. A thread pool can become clogged with long-running tasks, increasing the service time even for short tasks. If the pool size is too small relative to the expected steady-state number of longrunning tasks, eventually all the pool threads will be running long-running tasks and responsiveness will suffer.

By splitting long running IO tasks and fast CPU tasks into two different thread pools you can mitigate this problem. The thread pools will not be fighting over the same thread, because they don't share any threads.

Upvotes: 3

Related Questions