By default, Tomcat creates a bound thread pool for each connector (maximum number of threads 200). In most cases you do not need to change this configuration (unless you increase the maximum number of threads to meet high load requirements). But Tomcat likes to cache some objects, such as PageContext and tag caches, in the thread-local context of each worker thread. That's why you expect Tomcat to be able to turn the thread off to clean up some memory. In addition, each connector maintains its own thread pool, which makes it more difficult to set a maximum number of threads depending on the server's affordability. The answer to these questions is to use a shared executor.
By allowing all connectors to use the same shared executor, you can configure the maximum number of concurrent requests that are expected to be hosted by the entire application. The actuator also gives the thread pool the ability to expand when it is busy shrinking. In theory, at least.
Org.apache.catalina.core.StandardThreadExecutor
The standard, built-in actuator that Tomcat uses by default is Standardthreadexecutor. Configure document Access: Http://tomcat.apache.org/tomcat-6.0-doc/config/executor.html. These configuration options have an improperly named parameter "MaxIdleTime", and here are some things you need to know about the shutdown of standard actuators and idle threads.
A java.util.concurrent.ThreadPoolExecutor is used internally by standard actuators. It works through a thread pool of worker threads with a variable size, and once those threads have completed a task, they will wait for a blocking queue until a new task comes in. or until it waits for a set time, it will "timeout" and the thread will be closed. The key point here is that the first line to complete a task routines is first assigned a new task, and the thread pool adheres to a first in, Out (FIFO) mode. We need to keep this in mind as we examine how it will affect the Tomcat actuator.
MaxIdleTime is actually minidletime .
Because of the FIFO behavior of Java threadpoolexecutor, each thread waits for a minimum of "maxidletime" time to accept a new task before it can be shut down. In addition, due to the behavior of the thread pool's FIFO, because the first threads that enter the idle state will be assigned a new task, it should at least wait for the maxidletime to have no request when it is closed. The effect of this is that the executor cannot actually set the size of the appropriate average load (concurrent request) for the thread pool, and it will request the speed of the entry to provision this size. This may seem like no difference, but for Web servers, the impact can be huge. For example, 40 requests came in at one time. The thread pool expands to 40 to accommodate the load. During the following period, only one request was entered at the same time. For example, each request execution end requires a few MS, which means that in the next period of time, it takes 20 seconds to execute the entire thread constructor (remember, FIFO). Unless you set your maxidletime to within 20 seconds, the thread pool will hold 40 threads, even if your concurrency never exceeds 1. However you do not want to set your maxidletime too small-this will cause you to face the risk that threads are being shut down too quickly.
Conclusion
In order to match the average load, rather than the rate of a request entry, to get an expected thread pool behavior, it is more appropriate that the executor should be based on a last-in, first-out (LIFO) pattern. If the thread pool is able to prioritize the incoming tasks with a minimum of idle threads, the server can better shut down the threads in a more predictable way during the lower load phase. In the simple example above, where the initial load is 40 and the load remains at 1, a LIFO thread pool is able to adjust the size reasonably to 1 after the maxidletime phase. Of course, you are not always required to use this strategy, but if your goal is to minimize the resources that Tomcat holds, it is unfortunate that the standard executor may not be what you expect.
Original link: https://papweb.wordpress.com/2010/10/30/understanding-tomcat-executor-thread-pooling/.
Understanding of Tomcat's thread pool
