SpringBoot与TomCat、servlet、socket关系（TomCat启动流程）文章介绍了TomCat中的NIO模式的工作流程，主要分为Acceptor、Poller、processor。

本文中使用的TomCat版本为9.0.35

Acceptor监听网络连接，有连接进来后注册在Poller中，Poller通过轮询检测连接中的读写事件，有事件发生时调用processor进行请求处理。如下图：

这中间涉及到maxThreads、maxConnection、acceptCount三个参数，相信大家或多或少应该听说过一些。

maxThreads参数

最大线程池数量，也就是上图中executor的数量，默认最大线程是200，核心线程数10。

如果仅仅是一个线程池参数大家应该很熟悉了，没什么要讲的，但是大家回顾一下Java原生的线程池执行流程。先是核心线程工作，然后丢进任务队列，再创建非核心线程至最大线程数。这种情况下，对于网络服务器，需要应对大量的客户端请求，所有队列一般都是比较大的，在响应客户端时就有可能会放在队列中无法及时的去响应。针对此，TomCat自己实现了一套逻辑从而完成，先使用核心线程，达到核心线程数之后，再创建非核心线程工作直至最大线程数，最后放入队列的逻辑，保证了对客户端请求的及时响应。

org.apache.tomcat.util.threads.ThreadPoolExecutor便是TomCat的NIO模式下创建的线程池。

AbstractEndpoint类中
public void createExecutor() {
    this.internalExecutor = true;
    TaskQueue taskqueue = new TaskQueue();
    TaskThreadFactory tf = new TaskThreadFactory(this.getName() + "-exec-", this.daemon, this.getThreadPriority());
    this.executor = new org.apache.tomcat.util.threads.ThreadPoolExecutor(this.getMinSpareThreads(), this.getMaxThreads(), 60L, TimeUnit.SECONDS, taskqueue, tf);
    taskqueue.setParent((org.apache.tomcat.util.threads.ThreadPoolExecutor)this.executor);
}

可以看到在创建线程池的时候创建了一个TaskQueue（org.apache.tomcat.util.threads.TaskQueue）,目前看上去好像和Java原生线程池并无不同。处理逻辑的不同便在这个taskQueue中，让我们看下offer入队方法

org.apache.tomcat.util.threads.TaskQueue类中
public boolean offer(Runnable o) {
    if (this.parent == null) {
        return super.offer(o);
    } else if (this.parent.getPoolSize() == this.parent.getMaximumPoolSize()) {
        return super.offer(o);
    } else if (this.parent.getSubmittedCount() <= this.parent.getPoolSize()) {
        return super.offer(o);
    } else {
        return this.parent.getPoolSize() < this.parent.getMaximumPoolSize() ? false : super.offer(o);
    }
}

1. 如果parent为null，直接调用父类的offer方法，这种情况下工作模式和Java原生的相同

2. 如果线程数量等于最大线程池，这种情况下也直接放入调用父类的方法（可能入队列的时候刚好有线程释放，否则成功入队列）

3. 这种情况下，线程数量在核心线程数和最大线程数之间。当未执行的任务小于线程池的线程数量时，说明线程池中有空闲线程，这种情况也放入队列中去，调用父类的offer方法后，会立即安排空闲线程去执行。等于时也直接入列，这种情况下有一个线程执行完就会立即去执行当前任务，但是再进来任务时便会走到下面的分支去

4. 线程小于最大线程池数量，返回false，然后回去创建非核心线程去执行

5. 其他情况直接调用父类的offer方法。

从offer方法中可以看出区别主要是第四种情况，返回false的情况，回到线程池的代码中看下

org.apache.tomcat.util.threads.ThreadPoolExecutor中
public void execute(Runnable command, long timeout, TimeUnit unit) {
    this.submittedCount.incrementAndGet();
    try {
        super.execute(command);
    } catch (RejectedExecutionException var9) {
        // 任务拒绝处理省略
    }
}

可以看到其也是去调用父类Java原生的PoolExecutor，这里的代码因TomCat的版本不同而异，但是核心的处理都是交给父类去执行。继续看父类中的execute方法。

java.util.concurrent.ThreadPoolExecutor中

public void execute(Runnable command) {
    if (command == null)
        throw new NullPointerException();
    int c = ctl.get();
    if (workerCountOf(c) < corePoolSize) {   //  线程数量未达到核心线程数，创建核心线程工作addWorker方法的true表示核心线程
        if (addWorker(command, true))
            return;
        c = ctl.get();
    }
    if (isRunning(c) && workQueue.offer(command)) { 
        int recheck = ctl.get();
        if (! isRunning(recheck) && remove(command))
            reject(command);
        else if (workerCountOf(recheck) == 0)
            addWorker(null, false);
    }
    else if (!addWorker(command, false))  // 如果offer方法返回了false，则会走到这里，会去创建一个非核心线程，addWorker方法的false表示核心线程
        reject(command);
}

从源码中可以看到TomCat主要是通过实现了TaskQueue类，从而完成了优先响应用户请求的一个逻辑。

maxConnection、acceptCount参数

这两个参数要放在一起介绍，顾名思义就是最大连接数和最大可接收数，分别对应Poller和Acceptor。前面介绍了用户请求进来后会注册到Poller中去，Poller可以管理的最大请求数就是maxConnection，Acceptor就是等待被accept方法调用返回的但是系统已经建立的TCP连接数。

如果是Bio模式的话，maxConnection应当和maxThreads相一致，在TomCat的8.5版本之前，其中的JIOEndpoint是Bio模式的实现，看其源码可以知道在Acceptor接收到请求后直接丢进线程池中去执行，处理逻辑简单粗暴，这里不再赘述。在前面的文章中介绍了NIO模式的工作流程，这种模式下，accept的请求会被注册到Poller中去，监测有读写事件时才丢进线程池中去执行业务逻辑。

现在http请求很多都是长连接，请求的大部分时间都是没用读写事件的，Bio的模式下会造成线程的空转，浪费系统资源。所以在Tomcat8.5版本后移除了Bio模式的代码。

Poller能处理的保持的连接数就是maxConnection（Windows下默认为81912）。而对于acceptCount，如果accept方法执行的比较慢，短时间内大量的请求过来，并且系统已经建立了TCP连接等待被accept调用返回，已经建立的TCP请求便会放在一个和此参数相关的队列中去。如果accept太慢，或者Poller可以处理的请求达到了最大值，且没有及时的处理完而-1，accept队列也满了之后便会拒绝新的请求，并且没被及时处理的队列中的TCP连接会发出超时响应（connect timeout）。

org.apache.tomcat.util.net.NioEndpoint中
    protected void initServerSocket() throws Exception {
        if (!this.getUseInheritedChannel()) {
            this.serverSock = ServerSocketChannel.open();
            this.socketProperties.setProperties(this.serverSock.socket());
            InetSocketAddress addr = new InetSocketAddress(this.getAddress(), this.getPortWithOffset());
            this.serverSock.socket().bind(addr, this.getAcceptCount());
        } else {
            // ...省略
        }
        this.serverSock.configureBlocking(true);
    }

this.serverSock.socket().bind(addr, this.getAcceptCount())方法一层一层点进去便会发现acceptCount影响的是C++层的TCP连接的队列大小。

用如下的一个网图表示者三个参数的关系：

Acceptor是基于serverSocket的accept方法接收请求，没用及时accept但是有新请求进来与系统建立TCP连接，之后会放入到Acceptor的队列中，更准确的讲是放入serverSocket的连接队列中。

• SYN队列存储收到SYN包的连接，职责是回复SYN+ACK，并且ACK时重传，直到超时超时。发送完SYN+ACK后，等待客户端发送ACK，也就是三次握手的最后一包，收到ACK后会找到对应的SYN队列中的，在其中检测数据是否匹配，系统内核将连接相关数据从SYN队列中移除，并创建完整的TCP连接（对应内核代码的结构体：struct inet_sock），并将这个连接放入Aaccept全连接队列中。

• Accept队列中存放的是已建立好的连接，也即等待被上层应用程序取走的连接。当进程调用accept()，这个socket从队列中取出，传递给上层应用程序。