Java – why does ThreadPoolExecutor have BlockingQueue as a parameter?

I have tried to create and execute ThreadPoolExecutor

int poolSize = 2;
int maxPoolSize = 3;
ArrayBlockingQueue<Runnable> queue = new ArrayBlockingQueue<Runnable>(2);

If I keep trying seventh, eighth... Tasks

threadPool.execute(task);

When the queue reaches its maximum size, it starts throwing a "rejectedexecutionexception" It means I didn't join these tasks

So is the function of BlockingQueue lack of tasks? Means why not wait?

Definition from BlockingQueue

Why can't we link the list (normal queue implementation instead of blocking the queue)?

Solution

This problem occurs because your task queue is too small, which is indicated by the document of the execute method:

So the first problem is that you set your queue size very small:

int poolSize = 2;
int maxPoolSize = 3;
ArrayBlockingQueue<Runnable> queue = new ArrayBlockingQueue<Runnable>(2);

Then you declare that "if [i] try task 7, task 8... Then you will get a rejectedexecutionexception because you exceed the capacity of the queue There are two ways to solve your problem (I recommend using both methods):

>Increase the size of the queue, catch the exception and try adding the task again

You should have something like this:

public void ExecuteTask(MyRunnableTask task) {
    bool taskAdded = false;
    while(!taskAdded) {
        try {
            executor.execute(task);
            taskAdded = true;
        } catch (RejectedExecutionException ex) {
            taskAdded = false;
        }
    }   
}

Now, solve your other problems

BlockingQueue is used to complete producer / consumer mode. If it is large enough, you should not see the problems encountered As mentioned above, you need to increase the queue size, catch exceptions, and then retry the task

The linked list is neither thread safe nor blocked The producer / consumer model tends to make the best use of blocking queues

to update

Please do not be offended by the following statement. I intend to use more strict language to emphasize your first assumption that there should never be a problem with the library you use (unless you write the library yourself, you know there is a specific problem)!

So let's take a break: neither the ThreadPoolExecutor nor the Java library is a problem here It's all your misuse of the library that caused the problem Javmex has a great tutorial that explains exactly what you see

You may have several reasons why you fill the queue faster than you empty?

>Adding threads to execute tasks is to speed them up. > Task execution time is too long. > Your queue is too small > any combination of the above 3

There are other reasons, but I think the above will be the most common

I will give you a simple solution with an unbounded queue, but it will not solve your (misused) library So before we blame the Java library, let's look at a concise example to illustrate the exact problem you encounter

Update 2.0

Here are some other issues to solve specific problems:

> ThreadPoolExecutor Block When Queue Is Full? > How to make ThreadPoolExecutor’s submit() method block if it is saturated?