高并发下优化Tomcat性能详解

共计 5971 个字符，预计需要花费 15 分钟才能阅读完成。

高并发环境下，我知道优化配置 tomcat，对连接数和线程池作修改，最重要的是 connector 的协议 Http Connector 使用 NIO，而不是默认的 AJP Connector, 当时也没有仔细研究其原理。现在来为以上这些设置做一下剖析。

要了解这些，不能避开 tomcat 最重要的一个功能，就是 connector 连接器。

它的作用可是 tomcat 的核心，在 tomcat 的配置文件 server.xml 中写到过：Connector 的主要功能是接收连接请求，创建 request 和 response 对象用于和请求端交换数据；然后分配线程给 engine（servlet 容器）来处理请求，并把 request 和 response 对象传递给 engine 引擎，当 engine 处理完请求后，也会通过 Connector 将响应返回给客户端。

现在终于知道其原理了，而且也知道了 request 和 response 二大对象是由谁创建的。

可以说 servlet 容器处理请求，是需要 Connector 连接器进行调度和控制的，Connector 连接器是 tomcat 处理请求的主干，因此对 Connector 的配置和使用，对 tomcat 的性能有着决定性的作用，我们就聊一聊 Connector 连接器的配置选项，连接协议，连接数，线程池。

先谈谈连接协议，tomcat 的连接协议主要有二种：HTTP Connector 和 AJP Connector（默认），我们主要讨论 HTTP Connector

一、BIO、NIO、APR 

1、Connector 的 protocol

Connector 在处理 HTTP 请求时，会使用不同的 protocol。不同的 Tomcat 版本支持的 protocol 不同，其中最典型的 protocol 包括 BIO、NIO 和 APR（Tomcat7 中支持这 3 种，Tomcat8 增加了对 NIO2 的支持，而到了 Tomcat8.5 和 Tomcat9.0，则去掉了对 BIO 的支持）。

BIO 是 Blocking IO，顾名思义是阻塞的 IO；NIO 是 Non-blocking IO，则是非阻塞的 IO。而 APR 是 Apache Portable Runtime，是 Apache 可移植运行库，利用本地库可以实现高可扩展性、高性能；Apr 是在 Tomcat 上运行高并发应用的首选模式，但是需要安装 apr、apr-utils、tomcat-native 等包。(之前没有用过 APR，看来高并发下要使用此协议啊)

2、如何指定 protocol

Connector 使用哪种 protocol，可以通过 <connector> 元素中的 protocol 属性进行指定，也可以使用默认值。

指定的 protocol 取值及对应的协议如下：

HTTP/1.1：默认值，使用的协议与 Tomcat 版本有关

org.apache.coyote.http11.Http11Protocol：BIO

org.apache.coyote.http11.Http11NioProtocol：NIO

org.apache.coyote.http11.Http11Nio2Protocol：NIO2

org.apache.coyote.http11.Http11AprProtocol：APR

如果没有指定 protocol，则使用默认值 HTTP/1.1，其含义如下：在 Tomcat7 中，自动选取使用 BIO 或 APR（如果找到 APR 需要的本地库，则使用 APR，否则使用 BIO）；在 Tomcat8 中，自动选取使用 NIO 或 APR（如果找到 APR 需要的本地库，则使用 APR，否则使用 NIO）。

3、BIO/NIO 有何不同

无论是 BIO，还是 NIO，Connector 处理请求的大致流程是一样的：

在 accept 队列中接收连接（当客户端向服务器发送请求时，如果客户端与 OS 完成三次握手建立了连接，则 OS 将该连接放入 accept 队列）；在连接中获取请求的数据，生成 request；调用 servlet 容器处理请求；返回 response。为了便于后面的说明，首先明确一下连接与请求的关系：连接是 TCP 层面的（传输层），对应 socket；请求是 HTTP 层面的（应用层），必须依赖于 TCP 的连接实现；一个 TCP 连接中可能传输多个 HTTP 请求。

在 BIO 实现的 Connector 中，处理请求的主要实体是 JIoEndpoint 对象。JIoEndpoint 维护了 Acceptor 和 Worker：Acceptor 接收 socket，然后从 Worker 线程池中找出空闲的线程处理 socket，如果 worker 线程池没有空闲线程，则 Acceptor 将阻塞。其中 Worker 是 Tomcat 自带的线程池，如果通过 <Executor> 配置了其他线程池，原理与 Worker 类似。

在 NIO 实现的 Connector 中，处理请求的主要实体是 NIoEndpoint 对象。NIoEndpoint 中除了包含 Acceptor 和 Worker 外，还是用了 Poller，处理流程如下图所示。

Acceptor 接收 socket 后，不是直接使用 Worker 中的线程处理请求，而是先将请求发送给了 Poller，而 Poller 是实现 NIO 的关键。Acceptor 向 Poller 发送请求通过队列实现，使用了典型的生产者 - 消费者模式。在 Poller 中，维护了一个 Selector 对象；当 Poller 从队列中取出 socket 后，注册到该 Selector 中；然后通过遍历 Selector，找出其中可读的 socket，并使用 Worker 中的线程处理相应请求。与 BIO 类似，Worker 也可以被自定义的线程池代替。

通过上述过程可以看出，在 NIoEndpoint 处理请求的过程中，无论是 Acceptor 接收 socket，还是线程处理请求，使用的仍然是阻塞方式；但在“读取 socket 并交给 Worker 中的线程”的这个过程中，使用非阻塞的 NIO 实现，这是 NIO 模式与 BIO 模式的最主要区别（其他区别对性能影响较小，暂时略去不提）。而这个区别，在并发量较大的情形下可以带来 Tomcat 效率的显著提升：

目前大多数 HTTP 请求使用的是长连接（HTTP/1.1 默认 keep-alive 为 true），而长连接意味着，一个 TCP 的 socket 在当前请求结束后，如果没有新的请求到来，socket 不会立马释放，而是等 timeout 后再释放。如果使用 BIO，“读取 socket 并交给 Worker 中的线程”这个过程是阻塞的，也就意味着在 socket 等待下一个请求或等待释放的过程中，处理这个 socket 的工作线程会一直被占用，无法释放；因此 Tomcat 可以同时处理的 socket 数目不能超过最大线程数，性能受到了极大限制。而使用 NIO，“读取 socket 并交给 Worker 中的线程”这个过程是非阻塞的，当 socket 在等待下一个请求或等待释放时，并不会占用工作线程，因此 Tomcat 可以同时处理的 socket 数目远大于最大线程数，并发性能大大提高。

二、3 个参数：acceptCount、maxConnections、maxThreads

再回顾一下 Tomcat 处理请求的过程：在 accept 队列中接收连接（当客户端向服务器发送请求时，如果客户端与 OS 完成三次握手建立了连接，则 OS 将该连接放入 accept 队列）；在连接中获取请求的数据，生成 request；调用 servlet 容器处理请求；返回 response。

相对应的，Connector 中的几个参数功能如下：

1、acceptCount

accept 队列的长度；当 accept 队列中连接的个数达到 acceptCount 时，队列满，进来的请求一律被拒绝。默认值是 100。

2、maxConnections

Tomcat 在任意时刻接收和处理的最大连接数。当 Tomcat 接收的连接数达到 maxConnections 时，Acceptor 线程不会读取 accept 队列中的连接；这时 accept 队列中的线程会一直阻塞着，直到 Tomcat 接收的连接数小于 maxConnections。如果设置为 -1，则连接数不受限制。

默认值与连接器使用的协议有关：NIO 的默认值是 10000，APR/native 的默认值是 8192，而 BIO 的默认值为 maxThreads（如果配置了 Executor，则默认值是 Executor 的 maxThreads）。

在 windows 下，APR/native 的 maxConnections 值会自动调整为设置值以下最大的 1024 的整数倍；如设置为 2000，则最大值实际是 1024。

3、maxThreads

请求处理线程的最大数量。默认值是 200（Tomcat7 和 8 都是的）。如果该 Connector 绑定了 Executor，这个值会被忽略，因为该 Connector 将使用绑定的 Executor，而不是内置的线程池来执行任务。

maxThreads 规定的是最大的线程数目，并不是实际 running 的 CPU 数量；实际上，maxThreads 的大小比 CPU 核心数量要大得多。这是因为，处理请求的线程真正用于计算的时间可能很少，大多数时间可能在阻塞，如等待数据库返回数据、等待硬盘读写数据等。因此，在某一时刻，只有少数的线程真正的在使用物理 CPU，大多数线程都在等待；因此线程数远大于物理核心数才是合理的。

换句话说，Tomcat 通过使用比 CPU 核心数量多得多的线程数，可以使 CPU 忙碌起来，大大提高 CPU 的利用率。

4、参数设置

（1）maxThreads 的设置既与应用的特点有关，也与服务器的 CPU 核心数量有关。通过前面介绍可以知道，maxThreads 数量应该远大于 CPU 核心数量；而且 CPU 核心数越大，maxThreads 应该越大；应用中 CPU 越不密集（IO 越密集），maxThreads 应该越大，以便能够充分利用 CPU。当然，maxThreads 的值并不是越大越好，如果 maxThreads 过大，那么 CPU 会花费大量的时间用于线程的切换，整体效率会降低。

（2）maxConnections 的设置与 Tomcat 的运行模式有关。如果 tomcat 使用的是 BIO，那么 maxConnections 的值应该与 maxThreads 一致；如果 tomcat 使用的是 NIO，那么类似于 Tomcat 的默认值，maxConnections 值应该远大于 maxThreads。

（3）通过前面的介绍可以知道，虽然 tomcat 同时可以处理的连接数目是 maxConnections，但服务器中可以同时接收的连接数为 maxConnections+acceptCount。acceptCount 的设置，与应用在连接过高情况下希望做出什么反应有关系。如果设置过大，后面进入的请求等待时间会很长；如果设置过小，后面进入的请求立马返回 connection refused。

三、线程池 Executor

Executor 元素代表 Tomcat 中的线程池，可以由其他组件共享使用；要使用该线程池，组件需要通过 executor 属性指定该线程池。

Executor 是 Service 元素的内嵌元素。一般来说，使用线程池的是 Connector 组件；为了使 Connector 能使用线程池，Executor 元素应该放在 Connector 前面。Executor 与 Connector 的配置举例如下：

<Executor name=”tomcatThreadPool” namePrefix =”catalina-exec-” maxThreads=”150″ minSpareThreads=”4″ />

<Connector executor=”tomcatThreadPool” port=”8080″ protocol=”HTTP/1.1″ connectionTimeout=”20000″ redirectPort=”8443″ acceptCount=”1000″ />

Executor 的主要属性包括：

name：该线程池的标记

maxThreads：线程池中最大活跃线程数，默认值 200（Tomcat7 和 8 都是）

minSpareThreads：线程池中保持的最小线程数，最小值是 25

maxIdleTime：线程空闲的最大时间，当空闲超过该值时关闭线程（除非线程数小于 minSpareThreads），单位是 ms，默认值 60000（1 分钟）

daemon：是否后台线程，默认值 true

threadPriority：线程优先级，默认值 5

namePrefix：线程名字的前缀，线程池中线程名字为：namePrefix+ 线程编号

四、查看当前状态

上面介绍了 Tomcat 连接数、线程数的概念以及如何设置，下面说明如何查看服务器中的连接数和线程数。

查看服务器的状态，大致分为两种方案：（1）使用现成的工具，（2）直接使用 Linux 的命令查看。

现成的工具，如 JDK 自带的 jconsole 工具可以方便的查看线程信息（此外还可以查看 CPU、内存、类、JVM 基本信息等），Tomcat 自带的 manager，收费工具 New Relic 等。下图是 jconsole 查看线程信息的界面：

下面说一下如何通过 Linux 命令行，查看服务器中的连接数和线程数。

1、连接数

假设 Tomcat 接收 http 请求的端口是 8083，则可以使用如下语句查看连接情况：

netstat –nat | grep 8083

结果如下所示：

可以看出，有一个连接处于 listen 状态，监听请求；除此之外，还有 4 个已经建立的连接（ESTABLISHED）和 2 个等待关闭的连接（CLOSE_WAIT）。

2、线程

ps 命令可以查看进程状态，如执行如下命令：

ps –e | grep Java

结果如下图：

可以看到，只打印了一个进程的信息；27989 是线程 id，java 是指执行的 java 命令。这是因为启动一个 tomcat，内部所有的工作都在这一个进程里完成，包括主线程、垃圾回收线程、Acceptor 线程、请求处理线程等等。

通过如下命令，可以看到该进程内有多少个线程；其中，nlwp 含义是 number of light-weight process。

ps –o nlwp 27989

可以看到，该进程内部有 73 个线程；但是 73 并没有排除处于 idle 状态的线程。要想获得真正在 running 的线程数量，可以通过以下语句完成：

ps -eLo pid ,stat | grep 27989 | grep running | wc -l

其中 ps -eLo pid ,stat 可以找出所有线程，并打印其所在的进程号和线程当前的状态；两个 grep 命令分别筛选进程号和线程状态；wc 统计个数。其中，ps -eLo pid ,stat | grep 27989 输出的结果如下：

图中只截图了部分结果；Sl 表示大多数线程都处于空闲状态。

：