A detailed explanation of the principle and parameters of Tomcat thread pool

The Tomcat thread pool has the following parameters:

MaxThreads, maximum number of threads, Tomcat can create the maximum number of threads to process requests

Maxsparethreads, the maximum number of idle threads, active in the maximum idle time, but now idle, if the idle time is greater than the maximum idle time, then recovery, less than continue to survive, waiting to be dispatched.

Minsparethreads, minimum number of idle threads, minimum number of threads that will survive anyway

Acceptcount, the maximum number of wait queues, and the request concurrency is larger than the processing power of the Tomcat thread pool, is placed in the wait queue for processing.

MaxIdleTime, the maximum idle time, more than this idle time, and the number of threads greater than the minimum number of idle, will be recycled

1. A picture that understands the tomcat thread pool.

The tomcat principle is shown above. When the Tomcat thread pool is working, the actual situation is: Take the thread pool as an example, the first to create a minimum number of idle threads in the pool, 20, when the same time the number of requests is greater than the minimum idle number 20, for example, 50 concurrent requests, then the thread pool also needs to create 30 threads to process the request. At this time when the request has been processed, the request lasts less than 50 times, then when the time is over 60 seconds, the concurrency number is still not up to 50, then starting from the 50th thread, the thread pool will follow, the idle time reached 60s, began to recycle each, 49, 48, 47, so recycling. If the concurrent request is less than 20, then the thread pool is recycled to 20, stopping the recycle, which is the minimum number of idle numbers, and even if a request is not available, the thread pool is guaranteed to have 20 at any time. The so-called idle recovery means that a thread has been waiting for 60s of time. Then you can determine that the thread is idle. If the idle thread is above the minimum idle number, it will be recycled. When the request is more than 500 maximum idle, the thread pool will continue to create threads to meet the extra-large bursts of concurrency. When the number of concurrent requests is lowered and there is idle in the thread pool, the thread pools are reclaimed to 500 regardless of whether the threads are idle for up to 60s. 500 the thread of the class will also determine if the recycle is required based on whether the idle time is greater than 60s.

2. The following is a detailed description of how the Tomcat thread pool works in practice and how to handle concurrency.


With this in view, the highest thread, if it is busy, indicates that the tomcat thread is full.
In a short period of time, if the number of threads suddenly continues to rise, indicating that a sudden request has been made, and that more threads are being created to execute, when the thread is created, the request is waiting, the longer the last request is waiting. And over a period of time, the number of threads down to a lot of words, indicating that the sudden request has passed, the thread constructor threads idle time reached the maximum idle time, such as 60s, then will be recycled.

I personally feel that this phenomenon should be attributed to unhealthy state. Because the request is coming, the wait time is not too long if the waiting thread is only 10 or less. However, if the wait time reaches more than 10, the wait time will be geometrically rising, and the threading time will also increase in geometric multiples, because the same thread constructor between the threads to compete with each other CPU resources, such as now Tomcat running 1000 threads, If the time slice for each CPU is 0.01 seconds, then, when the 1000th thread executes, the thread actually has been waiting for 999 time slices *0.01=1 seconds, this is only a time slice execution, 0.01 seconds is equivalent to 10ms, and one of our requests normally time is: 30ms, That request to succeed will need to wait 3 times the CPU time slice to execute, if the Tomcat thread pool has been running 1000, that normally the execution time of a request should be: 0.03+999*0.01*3=3.03s, imagine, execute a request only need 30ms, But to wait for 3s, which is quite unreliable and unacceptable. Again, if the time slice is 20ms, then the execution time of a request from the wait to the completion of execution should be how much. 0.03+999*0.02* (0.03/0.02= takes greater than integer =2) +cpu switch time a*999 times =4.03s+999a, which is very exaggerated.

We can also ideal, join the line constructor only 500 active threads, then the above formula should be: When the CPU time slice is 0.01s, the last request needs processing success, when needed: 0.03+500*0.01*3= 1.53s, When the CPU time slice is 0.02s, the last request needs to be processed successfully, when needed: 0.03+500*0.02*2= 2.03s, when the CPU time slice is 0.03s, the last request needs to be processed successfully, when needed: 0.03+500*0.03*1= 1.53s.

But this is just CPU execution time, plus network transport, create thread time, CPU switch thread time required, and other time, total added up, is a very scary time. So, even though the Tomcat thread pool, it is best not to always exceed the minimum idle number, this is the best case, most of the time is the number of threads in the tomcat pool exceeds the maximum number of idle, the threads are always busy working, downtime is possible at any time.

The health status is: The thread pool keeps the minimum idle number is healthy, if your tomcat thread always exceeds the minimum number of idle, then your program is busy at any time, the chance of error has greatly increased. It's time to focus on it.

Above, only the personal point of view, the specific situation also has to be analyzed realistically. Also need to consider the number of CPU performance, network, operating system, the instance is mixed, whether the application type is CPU-intensive or IO-intensive, etc. will cause differentiation.