Tomcat thread pool, more in line with the imagined extensible thread pool

Cause

Talking about the thread pool, everyone may be affected by the impression of the connection pool, naturally think that it should be the first core thread, not busy to expand to the max thread, when idle back to the core thread, if there is a higher peak, put in a buffer queue buffer.

Some students who only deal with SSH all day long may still think so.

The relentless reality is that the JDK has only two typical thread pools, Fixedpool and Cachedpool:

• Fixedpool the number of fixed threads, all of which are too busy to be placed in an infinitely long buffer queue.
• Cachedpool, not busy when the unlimited increase of temporary threads, idle back, no buffer queue.

In the correct open mode of Java ThreadPool, it is suggested how to set up, avoid the above two scary "infinity". However, no matter how to match, can not use the ready-made things, with the beginning of the story of the image.

But it has to be said, this picture is still relatively beautiful, especially for the occasional stutter, occasionally unpredictable peaks of the business thread pool.

Of course, some people say that the request backlog in the final buffer queue is not good control, see the specific business scenario, buffer queue also have different gameplay (detailed).

Principle

Our colleague Lao Wang, after studying a threadpool mechanism, proposed the way to implement the queue. It happened that Tomcat did exactly that, and the Tomcat-based thread pool was slightly more customized than Jetty's own thread pool.

The logic of the JDK thread pool is simple (more detailed or see How the Java ThreadPool is opened correctly)

-A previous core request to create a thread on a request.
-After that, insert the request into the buffer queue for all the threads to grab, or create a new thread if the insert fails.
-Throws a deny exception if the Max Bar thread is reached.

The seemingly controlled hubs are in the 2nd sentence there-the result of the queue insertion. The JDK also achieves its own control effect by using Linkedblockingqueue and special synchronousqueue.

Can I encapsulate a queue myself and add the following logic when inserting it?

• If there are currently idle threads waiting for pick-up, add the task to the queue for the children to rob.
• If there is no idle time, the number of bus threads does not reach Max, then return false and let executor to create the thread.
• If the number of bus threads has reached Max, continue to buffer the task into the queue.
• Throws a deny exception if the buffer queue is also full.

It's so simple, frankly.

The implementation of Tomcat

Tomcat's Taskqueue implementation:

public class Taskqueue extends Linkedblockingqueue {

@Override

Public boolean offer (Runnable o) {

if (parent. getpoolsize () = = parent. Getmaximumpoolsize ()) return super. Offer (o);

if (parent. Getsubmittedcount () < Parent.getpoolsize ()) return super. Offer (o);

if (parent. Getpoolsize () < parent. Getmaximumpoolsize ()) return false;

return Super.offer (o);

}

}

Very simple code, the only explanation is how to determine whether there are currently idle threads waiting for pick-up. The cachedpool of the JDK is implemented by a special 0-length synchronousqueue. Tomcat, by extension executor, adds a counter to the current number of requests, add 1 before the Execute () method, and then reload the AfterExecute () method minus 1, then determine whether the current number of threads is greater than the current total number of requests to know there are onlookers around the crowd.

Further

Because of the belief that Tomcat is a century-old shop, we do not write this pool ourselves, stripping out some unrelated needs in tomcat implementation.

But is tomcat perfect?

First of all, Taskqueue's offer (), called the Executor.getpoolsize (), this is a lock function, this is the most regrettable place, in everyone in the line constructor a queue locked too badly, The lock function is quite an eyesore when the design of a forkjoinpool or Netty is a thread-by-queue. And, most of all, Tomcat has been tuned three times (still in Tomcat9 M9). Repeatedly looked down, do not seek so accurate words seemingly once enough, there is a case of concurrent changes, executor also has a processing rejectexception, put the task back into the queue of insurance.

Finally, say two ways to play the buffer queue:

One is that the queue is relatively long, such as 4096, the main thread will drop the task into the immediate return, if the queue is full, directly reported the rejection exception.

One is the queue is relatively short, such as 512, if full, the main thread to Queue.force (command, timeout) and so on there, waiting for the queue to be empty, wait until the timeout to report the rejection exception.

The tomcat mechanism supports both types of gameplay and is well-set.

Articles may also be modified, reproduced please retain the original link, otherwise considered infringement:
Http://calvin1978.blogcn.com/articles/tomcat-threadpool.html

Tomcat thread pool, more in line with an imagined extensible thread pool