详解 Tomcat 的连接数与线程池

本贴最后更新于 582 天前,其中的信息可能已经时移世改

前言

在使用 Tomcat 时,经常会遇到连接数、线程数之类的配置问题,要真正理解这些概念,必须先了解 Tomcat 的连接器(Connector)。

在前面的文章 详解 Tomcat 配置文件 server.xml 中写到过:Connector 的主要功能,是接收连接请求,创建 Request 和 Response 对象用于和请求端交换数据;然后分配线程让 Engine(也就是 Servlet 容器)来处理这个请求,并把产生的 Request 和 Response 对象传给 Engine。当 Engine 处理完请求后,也会通过 Connector 将响应返回给客户端。

可以说,Servlet 容器处理请求,是需要 Connector 进行调度和控制的,Connector 是 Tomcat 处理请求的主干,因此 Connector 的配置和使用对 Tomcat 的性能有着重要的影响。这篇文章将从 Connector 入手,讨论一些与 Connector 有关的重要问题,包括 NIO/BIO 模式、线程池、连接数等。

根据协议的不同,Connector 可以分为 HTTP Connector、AJP Connector 等,本文只讨论 HTTP Connector。

一、Nio、Bio、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 等包。

2、如何指定 protocol

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

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

如果没有指定 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 自带的线程池,如果通过配置了其他线程池,原理与 Worker 类似。

在 NIO 实现的 Connector 中,处理请求的主要实体是 NIoEndpoint 对象。NIoEndpoint 中除了包含 Acceptor 和 Worker 外,还是用了 Poller,处理流程如下图所示(图片来源:http://gearever.iteye.com/blog/1844203)。

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 的主要属性包括:

四、查看当前状态

上面介绍了 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 表示大多数线程都处于空闲状态。

参考文献

Apache Tomcat 7 Configuration Reference (7.0.103) - The HTTP Connector

Apache Tomcat 8 Configuration Reference (8.0.53) - The HTTP Connector

Apache Tomcat 8 Configuration Reference (8.0.53) - The HTTP Connector

tomcat架构分析(connector BIO 实现) - Gearever - ITeye博客

tomcat架构分析 (connector NIO 实现) - Gearever - ITeye博客

  • B3log

    B3log 是一个开源组织,名字来源于“Bulletin Board Blog”缩写,目标是将独立博客与论坛结合,形成一种新的网络社区体验,详细请看 B3log 构思。目前 B3log 已经开源了多款产品:PipeSoloSymWide 等。

    1128 引用 • 3384 回帖 • 515 关注
  • Tomcat

    Tomcat 最早是由 Sun Microsystems 开发的一个 Servlet 容器,在 1999 年被捐献给 ASF(Apache Software Foundation),隶属于 Jakarta 项目,现在已经独立为一个顶级项目。Tomcat 主要实现了 JavaEE 中的 Servlet、JSP 规范,同时也提供 HTTP 服务,是市场上非常流行的 Java Web 容器。

    146 引用 • 524 回帖
  • Java

    Java 是一种可以撰写跨平台应用软件的面向对象的程序设计语言,是由 Sun Microsystems 公司于 1995 年 5 月推出的。Java 技术具有卓越的通用性、高效性、平台移植性和安全性。

    2709 引用 • 7988 回帖 • 777 关注

赞助商 我要投放

1 回帖
请输入回帖内容 ...