Shulou(Shulou.com)06/02 Report--

This article mainly explains "Tomcat how to expand thread pool", interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Let's let Xiaobian take you to learn "Tomcat how to expand thread pool"!

JDK thread pool

In general, we can divide the tasks performed into two categories:

CPU-intensive tasks

io-intensive tasks

Cpu intensive tasks, complex operations that require threads for a long time. This type of task requires fewer threads to be created. Too many threads will cause frequent switching above, reducing the task processing speed.

For io-intensive tasks, since threads are not always running, they may spend most of their time waiting for IO to read/write data. Increasing the number of threads can improve concurrency and process as many tasks as possible.

JDK native thread pool workflow is as follows:

Thread Pool Execution Flowchart

"For details, see the article on how to safely close the thread pool. The above figure assumes that LinkedBlockingQueue is used.

"Soul Torture: Is the above process wrong? For a long time, I thought the number of threads would reach the maximum number of threads before I put them in the queue.￣□￣||

In the above figure, we can find that as long as the thread pool thread number is greater than the core thread number, the task will be added to the task queue first, and only if the task queue fails to be added, a new thread will be created. That is, the native thread pool queue is not full, at most, only the core thread number threads.

This strategy is obviously good for cpu-intensive tasks, but it is not very friendly for io-intensive tasks such as database queries, rpc request calls, etc.

Because Tomcat/Jetty handles a large number of client requests, if native thread pools are used, once the number of accepted requests exceeds the number of core threads in the thread pool, these requests are placed in a queue waiting for the core thread to process. This obviously slows down the overall processing speed of these requests, so neither uses JDK native thread pools.

The solution above can be implemented like Jetty's own thread pool component, so that it can be more adapted to internal logic, but the development difficulty is relatively large, and the other is like Tomcat, extending the native JDK thread pool, which is relatively simple to implement.

The following is mainly to Tomcat extension thread pool, talk about its implementation principle.

Extended thread pool

First we start with the JDK thread pool source code and see how to extend this base.

You can see that the thread pool process is mainly divided into three steps. The second step determines whether a new thread is needed according to the result returned by the queue#offer method.

JDK native queue types LinkedBlockingQueue, SynchronousQueue, the two implementation logic is different.

LinkedBlockingQueue

The offer method internally determines whether the queue is full. Returns false if the queue is full, true if the queue is not full, adds the task to the queue.

SynchronousQueue

This queue is special and does not store any data internally. If a thread puts a task in it, it will block until another thread takes it out. Conversely, if no other thread places a task in it, the queue's fetch method will block until another thread places the task.

For the offer method, it returns true if another thread is blocked by the fetch method. Otherwise, the offer method will return false.

Therefore, if you want to implement a thread pool suitable for io-intensive tasks, that is, give priority to new thread processing tasks, the key lies in the queue#offer method. You can override the internal logic of this method, so long as the current thread pool number is less than the maximum number of threads, the method returns false, and the thread pool is processed by a new thread.

Of course, the above implementation logic is rough, below we will view its implementation logic from Tomcat source code.

Tomcat extended thread pool

Tomcat extension thread pool directly inherits JDK thread pool java.util.concurrent. ThreadPoolExecutive, rewriting some method logic. In addition, TaskQueue is implemented, directly inheriting LinkedBlockingQueue and rewriting the offer method.

First look at how the Tomcat thread pool is used.

You can see that the Tomcat thread pool usage is not much different from a normal thread pool.

Next, let's look at the logic of the Tomcat thread pool core method execute.

Execute method logic is relatively simple, the core of the task or to Java native thread pool processing. Here, we mainly add a retry policy. If the native thread pool executes the rejection policy, we throw a RejectedExecutionException exception. This will capture, and then try again to add the task to the TaskQueue, performing the task as best as possible.

Note the submittedCount variable here. This is an important parameter inside the Tomcat thread pool. It is an AtomicInteger variable that counts tasks that have been submitted to the thread pool but have not yet finished execution in real time. That is, submittedCount equals the number of tasks in the thread pool queue plus the number of tasks being executed by the thread pool worker thread. TaskQueue#offer will use this parameter to implement the appropriate logic.

Next we focus on the TaskQueue#offer method logic.

The core logic lies in the third step, where false is returned if submittedCount is less than the number of threads in the current thread pool. As mentioned above, if the offer method returns false, the thread pool will create the new thread directly.

EagerThreadPool is added to Dubbo 2.6.X version, and its implementation principle is similar to Tomcat thread pool. Interested partners can browse by themselves.

compromise

Although the above extension method does not seem difficult, it may be more expensive to implement it yourself. If you don't want to expand the thread pool to run io-intensive tasks, you can use this compromise.

new ThreadPoolExecutor(10, 10, 0L, TimeUnit.MILLISECONDS, new LinkedBlockingQueue(100));

However, using this method will invalidate keepAliveTime, and once the thread is created, it will always exist, which is a waste of system resources.

At this point, I believe everyone has a deeper understanding of "Tomcat how to expand the thread pool," so let's actually operate it! Here is the website, more related content can enter the relevant channels for inquiry, pay attention to us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.