First, the container simplifies the programmer's own multi-threaded programming.
Various web containers, such as Tomcat, Resion, Jetty, etc. have their own thread pools (which can be configured in the configuration file), so when the client makes a request call, the programmer does not need to create a new one for every request of the client thread. The container will automatically allocate threads in the thread pool to improve access speed.
2. Tomcat thread pool implementation:
1. Using APR's Pool technology, JNI is used.
Starting from 5.5.17, Tomcat uses Apache Portable Runtime (APR) as the bottom layer in order to improve the response speed and efficiency, and uses various technologies such as Socket and buffer pool in APR, and the performance is also improved. APR is also the bottom layer of Apache HTTPD.
2. Thread Pool implemented in Java.
ThreadPool creates 5 threads by default, which are stored in a 200-dimensional thread array. These threads are started when they are created. Of course, when there is no request, they all process the "waiting" state (in fact, it is a while loop, which keeps waiting notify). If there is a request, the idle thread will be woken up to execute the user's request.
The specific request process is as follows: When the service starts, a one-dimensional thread array (maxThread=200) is created, and idle threads (minSpareThreads=5) are created to wait for user requests at any time. When there is a user request, the threadpool.runIt(ThreadPoolRunnable) method is called, and an instance to be executed is passed to the ThreadPool. The instance that the user needs to execute must implement the ThreadPoolRunnable interface. ThreadPool first finds an idle thread, and if so, uses it to run the ThreadPoolRunnable to be executed;
If there are no idle threads and maxThreads is not exceeded, minSpareThreads idle threads are created at one time; if maxThreads has been exceeded, idle threads are waited. In short, to find an idle thread, in order to use it to execute the instance. Once found, remove the thread from the thread array. Then wake up the idle thread that has been found and use it to run the execution instance (ThreadPoolRunnable). After running the ThreadPoolRunnable, put the thread back into the thread array as an idle thread for subsequent use.
It can be seen that Tomcat's thread pool implementation is relatively simple, and ThreadPool.java has only 840 lines of code. Use a one-dimensional array to save idle threads, and create idle threads at a small step (5) each time and put them in the thread pool . When used, remove idle threads from the array, and "return" them to the thread pool when they are used up .
Summarize:
Tomcat 5.5.10 or later supports apr, supports JNI calls through the apache runtime module, and uses native code to speed up network processing.
Before using apr, Tomcat's servlet thread pool uses blocking IO mode. After using apr, the thread pool becomes NIO non-blocking mode, and this NIO still uses the native code of the operating system. See the tomcat documentation The above statement is that the web processing capability is greatly improved, and it is no longer necessary to put a dedicated web server to process static pages.
My own intuitive feeling is that before using apr, how many waiting threads you configure, tomcat will start how many threads to hang and wait. After using apr, no matter how much you configure, there are only a few threads scheduled by NIO. It can be known by kill -3 PID and then viewing the log.
Assuming that apr is not used, the thread scheduling capability of the port may be relatively poor. Therefore, port forwarding through iptables and allowing two ports to share the thread scheduling of one port may reduce the concurrency of thread scheduling, thereby improving processing capacity and reducing resource consumption. .
3. Configure the Tomcat thread pool to use high concurrent connections
1. Open the shared thread pool:
<Service name="Catalina">
<!--The connectors can use a shared executor, you can define one or more named thread pools-->
<Executor name="tomcatThreadPool" namePrefix="catalina-exec-"
maxThreads="1000" minSpareThreads="50" maxIdleTime="600000"/>
By default, it is commented out before and after <!-- -->, just remove it.
Important parameter description:
name : The name of the shared thread pool. This is the name that the Connector will refer to in order to share the thread pool. This name must be unique. Default: None;
namePrefix : On the JVM, each running thread can have a name string. This property sets a prefix for the name string of each thread in the thread pool, and Tomcat will append the thread number to this prefix. Default: tomcat-exec-;
maxThreads : The maximum number of threads this thread pool can hold. Default: 200;
maxIdleTime : How long (in milliseconds) an idle thread is allowed to last before Tomcat shuts down an idle thread . Idle threads will be closed only if the number of currently active threads is greater than the value of minSpareThread. Default: 60000 (one minute).
minSpareThreads : The minimum number of inactive threads that Tomcat should always have open. Default: 25.
threadPriority : The level of the thread. Default is Thread.NORM_PRIORITY
2. Specify the use of a shared thread pool in the Connector:
<Connector executor="tomcatThreadPool"
port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443"
minProcessors="5"
maxProcessors="75"
acceptCount="1000"/>
Important parameter description:
executor: Indicates the thread pool corresponding to the parameter value is used;
minProcessors: The number of threads created when the server starts to process requests;
maxProcessors：最大可以创建的处理请求的线程数；
acceptCount：指定当所有可以使用的处理请求的线程数都被使用时，可以放到处理队列中的请求数，超过这个数的请求将不予处理。
BTW：我测试了一下，由于每次请求不再需要重新分配线程，系统响应速度还是有很明显的改善的。