According to Alibaba development Manual:

The thread pool is created using ThreadPoolExecutor.

There are seven parameters:

Now create it: core thread count 2, maximum number of concurrent threads 5, excess thread lifetime 1L, units of seconds, blocking queue 3, default thread factory, reject policy

Create a thread pool:

The first rejection policies: AbortPolicy: beyond the maximum number of threads, direct selling RejectedExecutionException exceptions to prevent normal operation of system.

Run five threads:

Run eight threads:

Run 9 threads:

It can be seen that the maximum number of threads is: the maximum number of threads executing at the same time + the number of task queues (blocking queues). When the maximum number of threads is exceeded, the rejection policy is directly run.

The second rejection strategy:

“Caller runs” is a mediation mechanism that does not discard tasks or throw exceptions, but instead rolls some tasks back to the caller, reducing traffic to new tasks. Who called you, when the maximum number of threads is reached, you go back to the person who called you, and then follow the arrangement of the person who called you.

DiscardOldestPolicy: Discards the longest waiting task in the queue and then adds the current task to the queue to try to submit the current task again

The fourth rejection policy: DiscardPolicy: Directly discards the task without any processing or exception thrown. This is the best solution if the task is allowed to be lost.

The thread pool is configured with a reasonable number of threads

Look at the number of cores in the machine

 

————————

CPU intensive: +1 CPU cores, which minimizes switching

IO intensive: number of CPU cores x 10 (0.9 in general blocking system)

Business scenarios:

1: for services with high concurrency and short task execution time, the number of threads in the thread pool can be set to the number of CPU cores +1 to reduce thread context switching

2: services with low concurrency and long task execution time need to be distinguished:

A) If the service time is long and the IO operation is concentrated, that is, the IO intensive task, because the IO operation does not occupy the CPU, so do not let all the CPU idle, can appropriately increase the number of threads in the thread pool, let the CPU handle more services

B) If the business hours are long and concentrated on computing operations, that is, computationally intensive tasks, this cannot be done. As in (1), the number of threads in the thread pool should be set to a smaller number to reduce thread context switching

(In fact, it can be seen from the first and second that whether the concurrency is high or not, it is necessary to determine whether the CPU intensive or I/O intensive in the business. The current premise is that you need to optimize performance.)

3: High concurrency and long business execution time. The key to solve this type of task is not the thread pool but the overall architecture design. It is the first step to see if some data in these businesses can be cached, and our project uses Redis as cache (such non-relational database is quite good). Adding servers is the second step (general government projects first, because there is no need to make major changes to the project technology, for a stable, but the premise is sufficient funds). As for the setting of thread pool, please refer to 2 for setting. Finally, the problem of long service execution time may need to be analyzed to see whether middleware can be used to split and decouple tasks (if the task time is too long, the split logic can be put into queues and other operations).