This article mainly introduces what problems the thread pool solves and corePoolSize (the number of core threads), queueCapacity (the length of the waiting queue), and maximumPoolSize (the maximum number of core threads) in the thread pool. This article will not introduce the various parameters of the thread pool, assuming that you have already understood the meaning of the various parameters of the thread pool.
1 Why is there a thread pool?
In current practical applications, we often encounter problems with a short processing time for a single request but a huge amount of requests. Simply put, the qps is high and the calming time is short. In these cases, if you use a task and create a new thread for processing, then what is the problem?
1. Create a new thread for each task. The higher the qps, the more CPU resources are consumed to create a new thread; the response is very short and the CPU continuously destroys the thread. It will consume a lot of cpu resources
2. The more threads created, the more frequent thread switching when the CPU processes tasks. As a result, the time that the CPU wasted on thread switching will become longer, which will increase the quiet time.
3. The creation of each thread consumes memory resources. OOM (unable to create new native Thread) is prone to occur in high qps situations
4. The operating system itself does not allow threads to grow infinitely
Based on the above 4 questions, the thread pool came into being.
The number of core threads in the thread pool can be reused, and there is no need to frequently create new threads to deal with high qps, thereby reducing the time consumption of switching between threads; the blocking queue can temporarily cache new tasks as a buffer pool for new threads.
2 Calculation of the core parameters of the thread pool
List the calculation formula first, and then explain with examples
2.1 Number of core threads
corePoolSize=20% * taskNum/(single thread/AR)=20% * number of tasks * flat sound
taskNum refers to the number of tasks/requests, etc., which can be simply understood as qps,
AR refers to the average processing time of each task,
20% is obtained according to the 8020 law . When a simple understanding is 80%, the core tasks account for about 20%
2.2 Work queue length
queueCapacity=（corePoolSize/AR）* MR
corePoolSize is the number of core threads calculated above,
AR refers to the average processing time of each task,
MR represents the maximum response time that the task can accept
2.3 Maximum number of core threads
maximumPoolSize=(taskNum-queueCapacity)/(single thread/AR)
taskNum refers to the number of tasks/requests, etc., which can be simply understood as qps,
queueCapacity is the length of the waiting queue,
AR refers to the average processing time of each task,
2.4 Examples
Assuming that the number of tasks is 100/s, the average response time is 0.1s, and the maximum acceptable response time is 0.5s.
corePoolSize=20% * taskNum/(single thread/AR)=20% * Number of tasks * Pitch=20% * 100 pcs/s * 0.1s=2 pcs
queueCapacity=(corePoolSize/AR)* MR=2pcs/0.1s *0.5s=10pcs
maximumPoolSize=(taskNum-queueCapacity)/(single thread/AR)=(100-10)/(1/0.1)=9
According to the above, the value of the core parameter can be roughly calculated, but there are premises and assumptions, that is, the resources are unlimited. What is calculated according to the formula is only a theoretical reference value. The actual online parameter configuration still needs to be fine-tuned based on this