Java Multi-threaded threadpoolexecutor strategy Pit

Whether using the thread pool of the JDK threadpoolexecutor or spring's thread pool threadpooltaskexecutor will use a blocking queue for the storage thread task.

When the thread is not sufficient, the subsequent task is staged into the blocking queue, waiting for the idle thread to proceed.

When the blocking queue is full, there are two situations.

If the number of threads running is less than maximumpoolsize, then create a thread to run the task;

If the number of threads running is greater than or equal to maximumpoolsize, the thread pool will process the subsequent tasks through a policy.

Four types of strategies

Threadpoolexecutor.abortpolicy () throws Java.util.concurrent.RejectedExecutionException exception
Threadpoolexecutor.callerrunspolicy () retries to add the current task, he will automatically repeatedly call the Execute () method
Threadpoolexecutor.discardoldestpolicy () Abandon the old task
Threadpoolexecutor.discardpolicy () Discard the current task

Others are easy to see and have recently stepped on a threadpoolexecutor.callerrunspolicy () pit.

The scenario is this: I need to create a long connection through the thread, when the 15 threads are open, the maximum thread pool is reached the number of maximumpoolsize, continue to increase the volume of requests, will be more than the reason

A long connection, due to load balancing, causes many requests not to be obtained from a long connection.

After a long period of testing, it was finally discovered that the Threadpoolexecutor.callerrunspolicy () strategy resulted.

This test is when you have the maximum number of threads, the blocking queue is full, then the task will be forced to execute first, but without the thread who will execute it, this policy will force the main thread to perform this task.

That is, when my volume, the thread pool is not enough, interrupted my main thread, the main thread does not have a long connection, the establishment of a new long connection, there is load balancing, but this side will not be in the main thread,

Causes many requests to be received.

Assuming that the queue size is 10,corepoolsize to 3,maximumpoolsize of 6, then when 20 tasks are added, the order of execution is as follows: Perform task 1, 2, 3 first, and then the task 4~13 into the queue. At this time the queue is full, tasks 14, 15, 16 will be executed immediately, the final order is: 1, 2, 3, 14, 15, 16, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13.

Step on the pit.

The final approach:

Switch to the Threadpoolexecutor.discardpolicy () policy, or to the request from an already established connection, and do not continue to create the connection.

Java Multi-threaded threadpoolexecutor strategy Pit