Tomcat 第五篇：请求处理流程（下）

1. 请求处理流程 AprEndPoint

顺着上一篇接着聊，当一个请求发送到 Tomcat 以后，会由连接器 Connector 转送至 AprEndPoint ，在 AprEndPoint 中调用了 startInternal() 方法，这个方法总共做了做了四件事儿：

LimitLatch 限制连接次数。
创建了 poller 线程。
创建了 sendfile 线程。
创建了 acceptor 。

其中， poller 、 sendfile 、 acceptor 都是 AprEndPoint 的内部类，因为他们的父类都实现了 Runnable ，所以核心逻辑都在他们自己的 run() 方法中。

其中的涉及到的源代码太多了，我就是懒得往出列了，所以画了下面这个图给各位做个示意。

LimitLatch 是连接控制器，它负责控制最大连接数。
Acceptor 跑在一个单独的线程中，它在一个死循环里面通过调用 accept() 方法来接收新连接，会返回一个 long 类型的 socket ，然后将这个 socket 封装成 AprSocketWrapper 对象。
Poller 本身也跑在一个单独的线程中，它早内部维护了一个 SocketList 对象，这个对象中含有 socket 数组，它在一个死循环里不断检测 socket 的数据就绪状态，一旦有 socket 可读，就生成一个 SocketProcessor 任务对象扔给 Executor 去处理。
Executor 就是一个线程池，负责运行 SocketProcessor 任务类， SocketProcessor 的 run() 方法会调用 Http11Processor 来读取和解析请求数据。

肯能有的朋友看完了，都不知道 AprEndPoint 或者说 Apr 这种连接模式是什么。

稍微做下简介：

APR（Apache Portable Runtime Libraries）是 Apache 可移植运行时库，它是用 C 语言实现的，其目的是向上层应用程序提供一个跨平台的操作系统接口库。Tomcat 可以用它来处理包括文件和网络 I/O，从而提升性能。

在 Tomcat8.5.x 中，默认的 I/O 模式使用的是 NIO ，使用的链接器是 org.apache.coyote.http11.Http11NioProtocol ，当然，由于是默认的，无需显示配置，在 server.xml 中只需要这么写就可以了：

<Connector port="8080" protocol="HTTP/1.1"

            connectionTimeout="20000"

            redirectPort="8443" />

但是如果要换成 APR ，就需要这么写了：

<Connector port="8443" protocol="org.apache.coyote.http11.Http11AprProtocol"

            maxThreads="150" SSLEnabled="true" >

    <UpgradeProtocol className="org.apache.coyote.http2.Http2Protocol" />

    <SSLHostConfig>

        <Certificate certificateKeyFile="conf/localhost-rsa-key.pem"

                        certificateFile="conf/localhost-rsa-cert.pem"

                        certificateChainFile="conf/localhost-rsa-chain.pem"

                        type="RSA" />

    </SSLHostConfig>

</Connector>

接下来聊一个拷问灵魂的问题， APR 是如何提升性能的？

跟 NioEndpoint 一样， AprEndpoint 也实现了非阻塞 I/O，它们的区别是：NioEndpoint 通过调用 Java 的 NIO API 来实现非阻塞 I/O，而 AprEndpoint 是通过 JNI 调用 APR 本地库而实现非阻塞 I/O 的。

Tomcat 的 Endpoint 组件在接收网络数据时需要预先分配好一块 Buffer，所谓的 Buffer 就是字节数组 byte[] ，Java 通过 JNI 调用把这块 Buffer 的地址传给 C 代码，C 代码通过操作系统 API 读取 Socket 并把数据填充到这块 Buffer。

Java NIO API 提供了两种 Buffer 来接收数据： HeapByteBuffer 和 DirectByteBuffer 。

HeapByteBuffer 对象本身在 JVM 堆上分配，并且它持有的字节数组 byte[] 也是在 JVM 堆上分配。但是如果用 HeapByteBuffer 来接收网络数据，需要把数据从内核先拷贝到一个临时的本地内存，再从临时本地内存拷贝到 JVM 堆，而不是直接从内核拷贝到 JVM 堆上。

数据从内核拷贝到 JVM 堆的过程中，JVM 可能会发生 GC ， GC 过程中对象可能会被移动，也就是说 JVM 堆上的字节数组可能会被移动，这样的话 Buffer 地址就失效了。如果这中间经过本地内存中转，从本地内存到 JVM 堆的拷贝过程中 JVM 可以保证不做 GC。

Tomcat 的 AprEndpoint 通过操作系统层面的 sendfile 特性解决了这个问题，sendfile 系统调用方式非常简洁。

2. 请求处理流程 NioEndPoint

前面介绍了 AprEndpoint 的请求处理流程，我们在顺便看下 Tomcat 默认的 NioEndPoint 处理流程。

实际上这两个处理流程非常的相似，区别基本上是因为非阻塞 I/O 的实现方式。

在 Acceptor 中的 accept() 方法返回一个 Channel 对象，接着把 Channel 对象交给 Poller 去处理。
Poller 在内部维护一个 Channel 数组，它在一个死循环里不断检测 Channel 的数据就绪状态，一旦有 Channel 可读，就生成一个 SocketProcessor 任务对象扔给 Executor 去处理。每个 Poller 线程都有自己的 Queue 。每个 Poller 线程可能同时被多个 Acceptor 线程调用来注册 PollerEvent 。 Poller 不断的通过内部的 Selector 对象向内核查询 Channel 的状态，一旦可读就生成任务类 SocketProcessor 交给 Executor 去处理。 Poller 的另一个重要任务是循环遍历检查自己所管理的 SocketChannel 是否已经超时，如果有超时就关闭这个 SocketChannel 。
Executor 是线程池，负责运行 SocketProcessor 任务类， SocketProcessor 的 run() 方法会调用 Http11Processor 来读取和解析请求数据。 ServerSocketChannel 通过 accept() 接受新的连接， accept() 方法返回获得 SocketChannel 对象，然后将 SocketChannel 对象封装在一个 PollerEvent 对象中，并将 PollerEvent 对象压入 Poller 的 Queue 里，这是个典型的生产者 - 消费者模式， Acceptor 与 Poller 线程之间通过 Queue 通信。

参考

https://jonhuster.blog.csdn.net/article/details/93297251