Introduction to implementation methods of several open-source Java Web Container thread pools (2)

Introduction to implementation methods of several open-source Java Web Container thread pools -- Tomcat (2)

ThreadPool only provides the implementation of the thread pool, and how to use the thread pool is also a great question. Let's see how Tomcat uses ThreadPool.

Tomcat has two types of Endpoints: AprEndpoint and PoolTcpEndpoint. The former implements a set of thread pools by itself (in fact, this is the same as the solution of the old version of Tomcat, so far Tomcat still retains the old version of the thread pool, PoolTcpEndpoint also has similar code, you can select different thread pool schemes through the "Policy ). We only focus on how PoolTcpEndpoint uses ThreadPool.

First, PoolTcpEndpoint creates a ThreadPoolRunnable instance -- LeaderFollowerWorkerThread. In fact, this instance receives (Accept) and processes (Process) User socket requests. Then, put the instance in the ThreadPool and run it. Then, you can receive user requests.

When there is a Socket request, LeaderFollowerWorkerThread first obtains the Socket instance. Note that LeaderFollowerWorkerThread does not urgently process the Socket at this time, but puts LeaderFollowerWorkerThread into the ThreadPool before responding to the Socket message, so that it (of course another thread) can continue to process Socket requests from other users; then, LeaderFollowerWorkerThread with Socket will process Socket requests from this user.

The entire process is different from the traditional process of processing user Socket requests, and is also different from the old Tomcat version. The traditional processing method is: there is a backend listening thread responsible for unified processing of received (note only "receive") Socket requests, when there is a new Socket request, assign it to a Worker thread (usually wake up this thread), and the latter processes Socket requests. The listening thread continues to wait for other Socket requests. Therefore, the entire process involves switching from Listener to Worker.

The new version of Tomcat uses another method very creatively. As described above, it is always the responsibility of a thread to receive and process a user's Socket request, does not switch to other threads for processing? Is switching between threads less efficient? I cannot confirm. However, this method of use is indeed different from the traditional mode and has a fresh feeling.

 

Introduction to implementation methods of several open-source Java Web Container thread pools -- Jetty (III)

In addition to Tomcat, Jetty is another important Java Web Container, known as the "smallest" Web container. It can be seen from the source code scale of Jetty that it is indeed relatively small. The implementation of its ThreadPool is also very simple. The entire code ThreadPool has only about 450 lines of code, which is very small.

ThreadPool code is located in the com. mortbty. thread package. The most important method is dispatch () and internal class PoolThread. As the name suggests, the dispatch method mainly sends the Runnable instance to the idle PoolThread in the thread pool, and the latter runs Runnable.

Let's take a look at the entire process. First, ThreadPool creates _ minThreads idle poolthreads and adds them to the idle thread queue. To run Runnable, first check whether there are idle poolthreads. If there are idle poolthreads, this will be handled by it. If no PoolThread exceeded _ maxThreads, create a new PoolThread and run Runnable by the newly created PoolThread. If PoolThread exceeds _ maxThreads, it waits until idle PoolThread appears. Before Running PoolThread, you must remove the PoolThread from the idle thread queue.

Let's take a look at the implementation of PoolThread. Like all Worker threads, a while (flag) {wait ();} loop is used to wait for the arrival of Runnable. When Runnable is ThreadPool. in dispatch (), the PoolThread runs Runnable. After the execution is complete, it "returns" to the idle thread queue.

How does Jetty use ThreadPool? Jetty only uses one ThreadPool instance. The specific entry is instantiated in org. mortbay. jetty. Server. The ThreadPool of the Server is also used by the Connector to process users' Socket requests. Connector is the entry for processing user Socket requests. A conne creates _ acceptors and acceptors. When an Acceptor processes user Socket requests, a Connection is created and put into the thread pool for processing when there is a Socket request, the Acceptor continues to process other Socket requests. This is a traditional Listener and Worker processing method.

 

Introduction to implementation methods of several open-source Java Web Container thread pools -- Resin (4)

Among these Java Web containers, Resin is very small, stable, and efficient. Among these Java Web containers, the efficiency is the highest. It can be found in many large websites. Resin started to take the "special" Open Source Path since version 3.0, which is similar to MySql-if it is used for commercial purposes, you need to buy its License. But for personal research, this is already good. On the website, you can download all the Code except the source code that involves License.

Specifically, Resin is mainly because of its outstanding performance, which can be used in many enterprise applications. The Resin database connection pool is very good and efficient. But here we will discuss its thread pool to see what's special.

The ThreadPool of Resin is located in com. caucho. util. ThreadPool. However, the class name is a bit odd. The more appropriate name is ThreadPoolItem, because it is indeed just a common Thread. Where can we manage thread scheduling? This class is also provided in the form of static functions, so this class plays two roles: thread pool scheduling and Worker thread. For this reason, there is only one thread pool in the Resin instance, unlike Tomcat and Jetty, which can run multiple thread pools at the same time, but for a system, one thread pool is sufficient.

Unlike other thread pools, Resin uses a linked list to store threads. If there is a request, the Head will be removed and the thread will be awakened; after the execution is complete, the thread will become idle and added to the Head part of the linked list. In addition, when each thread is running, it must determine whether the number of Idle threads exceeds _ minSpareThreads. If the number of Idle threads exceeds, the thread will exit (State to Dead) and be deleted from the linked list.

How does Resin use the ThreadPool? To use the thread pool, you only need to call ThreadPool. Schedule (Runnable. This method is a static function. As the name suggests, it is to add Runnable to ThreadPool for running.

Resin uses the traditional method: listening thread (com. caucho. server. port. port), the system can have multiple Port instances, the premise Port number is different, for example, there are 80 and 8080 ports; the other is the Worker thread, in fact, is actually the idle thread in the ThreadPool. The Port itself is a Thread. When it is started, it will run five threads in the ThreadPool -- TcpConnection simultaneously waiting for user requests. When there is a user request, one of them will be processed. Wait. After processing user requests, You can reuse these tcpconnections. This is different from Jetty's. Jetty creates a connection only when there is a user request, after the processing is completed, these connections will not be reused, and the efficiency will be slightly lower.

In addition, Resin has two backend running threads: ThreadLauncher and ScheduleThread. The former is responsible for creating a new thread when the idle thread is smaller than the minimum idle thread, and the latter is responsible for running the actual Runnable. I think there is no need to use a thread to create a new thread. However, ScheduleThread is required because it is a Worker thread.

June 23rd, 2006

Introduction to implementation methods of several open-source Java Web Container thread pools -- Conclusion (5)

After introducing the thread pools of tomcat, jetty, and resin Java Web containers, we should compare their advantages and disadvantages by convention. However, first summarize the features of the thread pool.

The thread pool is widely used as a solution to improve the program's data processing capability. A large number of servers use the thread pool technology more or less. Whether implemented in Java or C ++, the thread pool has the following features:

The thread pool generally has three important parameters:

1. Maximum number of threads. At any time when the program is running, the total number of threads will not exceed this number. If the maximum number of requests is exceeded, it will wait for other threads to finish processing.

2. the maximum number of shared threads, that is, the maximum number of Idle threads. If the number of Idle threads exceeds this value, the excess threads will be killed.

3. The minimum number of shared threads, that is, the minimum number of Idle threads. If the current number of Idle threads is smaller than this value, the number of Idle threads will be created at one time, so it is also a step of the Creation thread.

 

The thread pool has two concepts:

1. Worker thread. A worker thread runs the code in two states: idle and running. In idle state, waiting for a task is similar to "Sleep". when processing a running state, it indicates a running task (Runnable ).

2. Auxiliary threads. Monitors the status of the thread pool: whether the number of Idle threads exceeds the maximum number of Idle threads or is less than the minimum number of Idle threads. If the requirements are not met, adjust it.

 

If we examine these three containers according to the above standards, we will find that the thread pool implemented by Tomcat is the most complete, followed by Resin, and Jetty is the simplest. Jetty does not control the number of Idle threads. The number of Idle threads may reach the maximum number of threads and image performance. After all, even sleep threads consume CPU clock.

Talk about the Resin thread pool. The implementation of Resin is more complex than that of Tomcat. There are also the above three parameters and two concepts, which is equivalent to Tomcat. But considering how to use ThreadPool, Resin should be more complex.

Perhaps because the ThreadPool of Resin is in single-room mode, all threads that use ThreadPool are the same settings, such as the same maximum number of threads and the maximum number of Idle threads, which will be considered more when used. For example, when controlling the maximum number of Socket connections, com. caucho. server. port. Port must have its own "quantity" control mechanism, rather than the specific control mechanism of ThreadPool. Therefore, it is more complex to use than Tomcat.

Tomcat uses ThreadPool, but it is very simple. Because the ThreadPool of Tomcat can have different instances, it is easy to customize its own "quantity" control and directly use ThreadPool to control the number of Socket connections. So the code is refreshing.

If you want to use the thread pool, use the ThreadPool of Tomcat.