Fixed ExecutorService pool freezes on one task

Question

My code has a thread pool implemented using the ExecutorService fixed thread pool. Most tasks performed by the pool are very short, but sometimes there is one task that will work for a long time, about 20-30 seconds. When this task is completed, new tasks are not performed and will be resumed only after the completion of a task that has been performed for a long time.

The pool is set to 20, so the problem is not that I can recreate it with only two threads, at first it is long, and the second is stuck.

I waved my head why it was stuck, and then switched from newFixedThreadPool() to newCachedThreadPool() , and a bottleneck was released. This is the only change I have made.

Does this behavior make sense? It seems that the code is working fine, so I think I will save the changes, and as far as I understand, it is better to use the cache thread pool if you perform many short tasks, but I was wondering why the fixed pool freezes and is there a way to fix it?

Also, what could be a side effect, if any, for switching from fixed to cache?

Thanks.

Answer 1

Possible result: more threads will be launched at the same time, because newCachedThreadPool () allows you to start Integer.MAX_VALUE threads.

It’s impossible to guess how to influence you without looking at your code.

But, as I think, if the problem is solved by increasing the number of threads, there is a high probability that you have locks.

For example, you have 4 resources A, B, C, D. And 4 tasks:

1) short TaskA requires resource A
2) short TaskB requires resource B
3) short TaskC requires resource C
4) long TaskD requires resources A and D

So, at one point in time, we will have the following situation:

 Thread1: TaskA await for resource A Thread2: TaskD has A and D and running TaskB wait in Queue TaskC wait in Queue 

When you change pull to pull with an unlimited number of threads, or a fixed thread pool with many allowed threads:

 Thread1: TaskA await for resource A Thread2: TaskD has A and D and running Thread3: TaskB has resource B Thread4: TaskC has resource C 

So, one of the threads is blocked by the other, but you cannot see it, because all other tasks are performed without locks.