微信公众号【Java技术江湖】
一位阿里 Java 工程师的技术小站。作者黄小斜,专注 Java 相关技术:SSM、SpringBoot、MySQL、分布式、中间件、集群、Linux、网络、多线程,偶尔讲点Docker、ELK,同时也分享技术干货和学习经验,致力于Java全栈开发!(关注公众号后回复”Java“即可领取 Java基础、进阶、项目和架构师等免费学习资料,更有数据库、分布式、微服务等热门技术学习视频,内容丰富,兼顾原理和实践,另外也将赠送作者原创的Java学习指南、Java程序员面试指南等干货资源)
谈谈 Tomcat 请求处理流程
转自:https://github.com/c-rainstorm/blog/blob/tomcat-request-process/reading-notes
《谈谈 Tomcat 架构及启动过程[含部署]》已重新修订!(与本文在 GitHub 同一目录下)包括架构和 Tomcat Start 过程中的 MapperListener
相关描述。Connector
启动相关的内容与请求处理关系比较紧密,所以就独立出来放在本文中了。
建议结合《谈谈 Tomcat 架构及启动过程[含部署]》一起看!
很多东西在时序图中体现的已经非常清楚了,没有必要再一步一步的作介绍,所以本文以图为主,然后对部分内容加以简单解释。
- 绘制图形使用的工具是 PlantUML + Visual Studio Code + PlantUML Extension
本文对 Tomcat 的介绍以 Tomcat-9.0.0.M22
为标准。
Tomcat-9.0.0.M22
是 Tomcat 目前最新的版本,但尚未发布,它实现了 Servlet4.0
及 JSP2.3
并提供了很多新特性,需要 1.8 及以上的 JDK 支持等等,详情请查阅 Tomcat-9.0-doc
Overview
- Connector 启动以后会启动一组线程用于不同阶段的请求处理过程。
Acceptor
线程组。用于接受新连接,并将新连接封装一下,选择一个Poller
将新连接添加到Poller
的事件队列中。Poller
线程组。用于监听 Socket 事件,当 Socket 可读或可写等等时,将 Socket 封装一下添加到worker
线程池的任务队列中。worker
线程组。用于对请求进行处理,包括分析请求报文并创建 Request 对象,调用容器的 pipeline 进行处理。
Acceptor
、Poller
、worker
所在的ThreadPoolExecutor
都维护在NioEndpoint
中。
Connector Init and Start
initServerSocket()
,通过ServerSocketChannel.open()
打开一个 ServerSocket,默认绑定到 8080 端口,默认的连接等待队列长度是 100, 当超过 100 个时会拒绝服务。我们可以通过配置conf/server.xml
中Connector
的acceptCount
属性对其进行定制。createExecutor()
用于创建Worker
线程池。默认会启动 10 个Worker
线程,Tomcat 处理请求过程中,Woker 最多不超过 200 个。我们可以通过配置conf/server.xml
中Connector
的minSpareThreads
和maxThreads
对这两个属性进行定制。Pollor
用于检测已就绪的 Socket。 默认最多不超过 2 个,Math.min(2,Runtime.getRuntime().availableProcessors());
。我们可以通过配置pollerThreadCount
来定制。Acceptor
用于接受新连接。默认是 1 个。我们可以通过配置acceptorThreadCount
对其进行定制。
Requtst Process
Acceptor
Acceptor
在启动后会阻塞在ServerSocketChannel.accept();
方法处,当有新连接到达时,该方法返回一个SocketChannel
。- 配置完 Socket 以后将 Socket 封装到
NioChannel
中,并注册到Poller
,值的一提的是,我们一开始就启动了多个Poller
线程,注册的时候,连接是公平的分配到每个Poller
的。NioEndpoint
维护了一个Poller
数组,当一个连接分配给pollers[index]
时,下一个连接就会分配给pollers[(index+1)%pollers.length]
. addEvent()
方法会将 Socket 添加到该Poller
的PollerEvent
队列中。到此Acceptor
的任务就完成了。
Poller
selector.select(1000)
。当Poller
启动后因为 selector 中并没有已注册的Channel
,所以当执行到该方法时只能阻塞。所有的Poller
共用一个 Selector,其实现类是sun.nio.ch.EPollSelectorImpl
events()
方法会将通过addEvent()
方法添加到事件队列中的 Socket 注册到EPollSelectorImpl
,当 Socket 可读时,Poller
才对其进行处理createSocketProcessor()
方法将 Socket 封装到SocketProcessor
中,SocketProcessor
实现了Runnable
接口。worker
线程通过调用其run()
方法来对 Socket 进行处理。execute(SocketProcessor)
方法将SocketProcessor
提交到线程池,放入线程池的workQueue
中。workQueue
是BlockingQueue
的实例。到此Poller
的任务就完成了。
Worker
worker
线程被创建以后就执行ThreadPoolExecutor
的runWorker()
方法,试图从workQueue
中取待处理任务,但是一开始workQueue
是空的,所以worker
线程会阻塞在workQueue.take()
方法。- 当新任务添加到
workQueue
后,workQueue.take()
方法会返回一个Runnable
,通常是SocketProcessor
,然后worker
线程调用SocketProcessor
的run()
方法对 Socket 进行处理。 createProcessor()
会创建一个Http11Processor
, 它用来解析 Socket,将 Socket 中的内容封装到Request
中。注意这个Request
是临时使用的一个类,它的全类名是org.apache.coyote.Request
,postParseRequest()
方法封装一下 Request,并处理一下映射关系(从 URL 映射到相应的Host
、Context
、Wrapper
)。CoyoteAdapter
将 Rquest 提交给Container
处理之前,并将org.apache.coyote.Request
封装到org.apache.catalina.connector.Request
,传递给Container
处理的 Request 是org.apache.catalina.connector.Request
。connector.getService().getMapper().map()
,用来在Mapper
中查询 URL 的映射关系。映射关系会保留到org.apache.catalina.connector.Request
中,Container
处理阶段request.getHost()
是使用的就是这个阶段查询到的映射主机,以此类推request.getContext()
、request.getWrapper()
都是。
connector.getService().getContainer().getPipeline().getFirst().invoke()
会将请求传递到Container
处理,当然了Container
处理也是在Worker
线程中执行的,但是这是一个相对独立的模块,所以单独分出来一节。
Container
- 需要注意的是,基本上每一个容器的
StandardPipeline
上都会有多个已注册的Valve
,我们只关注每个容器的 Basic Valve。其他 Valve 都是在 Basic Valve 前执行。 request.getHost().getPipeline().getFirst().invoke()
先获取对应的StandardHost
,并执行其 pipeline。request.getContext().getPipeline().getFirst().invoke()
先获取对应的StandardContext
,并执行其 pipeline。request.getWrapper().getPipeline().getFirst().invoke()
先获取对应的StandardWrapper
,并执行其 pipeline。- 最值得说的就是
StandardWrapper
的 Basic Valve,StandardWrapperValve
allocate()
用来加载并初始化Servlet
,值的一提的是 Servlet 并不都是单例的,当 Servlet 实现了SingleThreadModel
接口后,StandardWrapper
会维护一组 Servlet 实例,这是享元模式。当然了SingleThreadModel
在 Servlet 2.4 以后就弃用了。createFilterChain()
方法会从StandardContext
中获取到所有的过滤器,然后将匹配 Request URL 的所有过滤器挑选出来添加到filterChain
中。doFilter()
执行过滤链,当所有的过滤器都执行完毕后调用 Servlet 的service()
方法。
谈谈 Tomcat 架构及启动过程[含部署]
这个题目命的其实是很大的,写的时候还是很忐忑的,但我尽可能把这个过程描述清楚。因为这是读过源码以后写的总结,在写的过程中可能会忽略一些前提条件,如果有哪些比较突兀就出现,或不好理解的地方可以给我提 Issue,我会尽快补充修订相关内容。
很多东西在时序图中体现的已经非常清楚了,没有必要再一步一步的作介绍,所以本文以图为主,然后对部分内容加以简单解释。
- 绘制图形使用的工具是 PlantUML + Visual Studio Code + PlantUML Extension
- 图形
PlantUML
源文件:
本文对 Tomcat 的介绍以 Tomcat-9.0.0.M22
为标准。
Tomcat-9.0.0.M22
是 Tomcat 目前最新的版本,但尚未发布,它实现了 Servlet4.0
及 JSP2.3
并提供了很多新特性,需要 1.8 及以上的 JDK 支持等等,详情请查阅 Tomcat-9.0-doc
- Overview
- Tomcat init
- Tomcat Start[Deployment]
- Background process
- How to read excellent open source projects
- At last
- Reference
Overview
Bootstrap
作为 Tomcat 对外界的启动类,在$CATALINA_BASE/bin
目录下,它通过反射创建Catalina
的实例并对其进行初始化及启动。Catalina
解析$CATALINA_BASE/conf/server.xml
文件并创建StandardServer
、StandardService
、StandardEngine
、StandardHost
等StandardServer
代表的是整个 Servlet 容器,他包含一个或多个StandardService
StandardService
包含一个或多个Connector
,和一个Engine
,Connector
和Engine
都是在解析conf/server.xml
文件时创建的,Engine
在 Tomcat 的标准实现是StandardEngine
MapperListener
实现了LifecycleListener
和ContainerListener
接口用于监听容器事件和生命周期事件。该监听器实例监听所有的容器,包括StandardEngine
、StandardHost
、StandardContext
、StandardWrapper
,当容器有变动时,注册容器到Mapper
。Mapper
维护了 URL 到容器的映射关系。当请求到来时会根据Mapper
中的映射信息决定将请求映射到哪一个Host
、Context
、Wrapper
。Http11NioProtocol
用于处理 HTTP/1.1 的请求NioEndpoint
是连接的端点,在请求处理流程中该类是核心类,会重点介绍。CoyoteAdapter
用于将请求从 Connctor 交给 Container 处理。使 Connctor 和 Container 解耦。StandardEngine
代表的是 Servlet 引擎,用于处理Connector
接受的 Request。包含一个或多个Host
(虚拟主机),Host
的标准实现是StandardHost
。StandardHost
代表的是虚拟主机,用于部署该虚拟主机上的应用程序。通常包含多个Context
(Context 在 Tomcat 中代表应用程序)。Context
在 Tomcat 中的标准实现是StandardContext
。StandardContext
代表一个独立的应用程序,通常包含多个Wrapper
,一个Wrapper
容器封装了一个 Servlet,Wrapper
的标准实现是StandardWrapper
。StandardPipeline
组件代表一个流水线,与Valve
(阀)结合,用于处理请求。StandardPipeline
中含有多个Valve
, 当需要处理请求时,会逐一调用Valve
的invoke
方法对 Request 和 Response 进行处理。特别的,其中有一个特殊的Valve
叫basicValve
,每一个标准容器都有一个指定的BasicValve
,他们做的是最核心的工作。StandardEngine
的是StandardEngineValve
,他用来将 Request 映射到指定的Host
;StandardHost
的是StandardHostValve
, 他用来将 Request 映射到指定的Context
;StandardContext
的是StandardContextValve
,它用来将 Request 映射到指定的Wrapper
;StandardWrapper
的是StandardWrapperValve
,他用来加载 Rquest 所指定的 Servlet,并调用 Servlet 的Service
方法。
Tomcat init
- 当通过
./startup.sh
脚本或直接通过java
命令来启动Bootstrap
时,Tomcat 的启动过程就正式开始了,启动的入口点就是Bootstrap
类的main
方法。 - 启动的过程分为两步,分别是
init
和start
,本节主要介绍init
;
- 初始化类加载器。[关于 Tomcat 类加载机制,可以参考我之前写的一片文章:谈谈Java类加载机制]
- 通过从
CatalinaProperties
类中获取common.loader
等属性,获得类加载器的扫描仓库。CatalinaProperties
类在的静态块中调用了loadProperties()
方法,从conf/catalina.properties
文件中加载了属性.(即在类创建的时候属性就已经加载好了)。 - 通过
ClassLoaderFactory
创建URLClassLoader
的实例
- 通过从
- 通过反射创建
Catalina
的实例并设置parentClassLoader
setAwait(true)
。设置Catalina
的await
属性为true
。在 Start 阶段尾部,若该属性为true
,Tomcat 会在 main 线程中监听SHUTDOWN
命令,默认端口是 8005.当收到该命令后执行Catalina
的stop()
方法关闭 Tomcat 服务器。createStartDigester()
。Catalina
的该方法用于创建一个 Digester 实例,并添加解析conf/server.xml
的RuleSet
。Digester 原本是 Apache 的一个开源项目,专门解析 XML 文件的,但我看 Tomcat-9.0.0.M22 中直接将这些类整合到 Tomcat 内部了,而不是引入 jar 文件。Digester 工具的原理不在本文的介绍范围,有兴趣的话可以参考 The Digester Component - Apache 或 《How Tomcat works》- Digester [推荐] 一章parse()
方法就是 Digester 处理conf/server.xml
创建各个组件的过程。值的一提的是这些组件都是使用反射的方式来创建的。特别的,在创建 Digester 的时候,添加了一些特别的rule Set
,用于创建一些十分核心的组件,这些组件在conf/server.xml
中没有但是其作用都比较大,这里做下简单介绍,当 Start 时用到了再详细说明:EngineConfig
。LifecycleListener
的实现类,触发 Engine 的生命周期事件后调用,这个监听器没有特别大的作用,就是打印一下日志HostConfig
。LifecycleListener
的实现类,触发 Host 的生命周期事件后调用。这个监听器的作用就是部署应用程序,这包括conf/<Engine>/<Host>/
目录下所有的 Context xml 文件 和webapps
目录下的应用程序,不管是 war 文件还是已解压的目录。 另外后台进程对应用程序的热部署也是由该监听器负责的。ContextConfig
。LifecycleListener
的实现类,触发 Context 的生命周期事件时调用。这个监听器的作用是配置应用程序,它会读取并合并conf/web.xml
和 应用程序的web.xml
,分析/WEB-INF/classes/
和/WEB-INF/lib/*.jar
中的 Class 文件的注解,将其中所有的 Servlet、ServletMapping、Filter、FilterMapping、Listener 都配置到StandardContext
中,以备后期使用。当然了web.xml
中还有一些其他的应用程序参数,最后都会一并配置到StandardContext
中。
reconfigureStartStopExecutor()
用于重新配置启动和停止子容器的Executor
。默认是 1 个线程。我们可以配置conf/server.xml
中Engine
的startStopThreads
,来指定用于启动和停止子容器的线程数量,如果配置 0 的话会使用Runtime.getRuntime().availableProcessors()
作为线程数,若配置为负数的话会使用Runtime.getRuntime().availableProcessors() + 配置值
,若和小与 1 的话,使用 1 作为线程数。当线程数是 1 时,使用InlineExecutorService
它直接使用当前线程来执行启动停止操作,否则使用ThreadPoolExecutor
来执行,其最大线程数为我们配置的值。- 需要注意的是 Host 的
init
操作是在 Start 阶段来做的,StardardHost
创建好后其state
属性的默认值是LifecycleState.NEW
,所以在其调用startInternal()
之前会进行一次初始化。
Tomcat Start[Deployment]
- 图中从
StandardHost
StartStandardContext
的这步其实在真正的执行流程中会直接跳过,因为conf/server.xml
文件中并没有配置任何的Context
,所以在findChildren()
查找子容器时会返回空数组,所以之后遍历子容器来启动子容器的for
循环就直接跳过了。 - 触发 Host 的
BEFORE_START_EVENT
生命周期事件,HostConfig
调用其beforeStart()
方法创建$CATALINA_BASE/webapps
&$CATALINA_BASE/conf/<Engine>/<Host>/
目录。 - 触发 Host 的
START_EVENT
生命周期事件,HostConfig
调用其start()
方法开始部署已在$CATALINA_BASE/webapps
&$CATALINA_BASE/conf/<Engine>/<Host>/
目录下的应用程序。- 解析
$CATALINA_BASE/conf/<Engine>/<Host>/
目录下所有定义Context
的 XML 文件,并添加到StandardHost
。这些 XML 文件称为应用程序描述符。正因为如此,我们可以配置一个虚拟路径来保存应用程序中用到的图片,详细的配置过程请参考 开发环境配置指南 - 6.3. 配置图片存放目录 - 部署
$CATALINA_BASE/webapps
下所有的 WAR 文件,并添加到StandardHost
。 - 部署
$CATALINA_BASE/webapps
下所有已解压的目录,并添加到StandardHost
。
- 特别的,添加到
StandardHost
时,会直接调用StandardContext
的start()
方法来启动应用程序。启动应用程序步骤请看 Context Start 一节。
- 解析
- 在
StandardEngine
和StandardContext
启动时都会调用各自的threadStart()
方法,该方法会创建一个新的后台线程来处理该该容器和子容器及容器内各组件的后台事件。StandardEngine
会直接创建一个后台线程,StandardContext
默认是不创建的,和StandardEngine
共用同一个。后台线程处理机制是周期调用组件的backgroundProcess()
方法。详情请看 Background process 一节。 MapperListener
addListeners(engine)
方法会将该监听器添加到StandardEngine
和它的所有子容器中registerHost()
会注册所有的Host
和他们的子容器到Mapper
中,方便后期请求处理时使用。- 当有新的应用(
StandardContext
)添加进来后,会触发 Host 的容器事件,然后通过MapperListener
将新应用的映射注册到Mapper
中。
- Start 工作都做完以后
Catalina
会创建一个CatalinaShutdownHook
并注册到 JVM。CatalinaShutdownHook
继承了Thread
,是Catalina
的内部类。其run
方法中直接调用了Catalina
的stop()
方法来关闭整个服务器。注册该 Thread 到 JVM 的原因是防止用户非正常终止 Tomcat,比如直接关闭命令窗口之类的。当直接关闭命令窗口时,操作系统会向 JVM 发送一个终止信号,然后 JVM 在退出前会逐一启动已注册的 ShutdownHook 来关闭相应资源。
Context Start
StandRoot
类实现了WebResourceRoot
接口,它容纳了一个应用程序的所有资源,通俗的来说就是部署到webapps
目录下对应Context
的目录里的所有资源。因为我对 Tomcat 的资源管理部分暂时不是很感兴趣,所以资源管理相关类只是做了简单了解,并没有深入研究源代码。resourceStart()
方法会对StandardRoot
进行初始配置postWorkDirectory()
用于创建对应的工作目录$CATALINA_BASE/work/<Engine>/<Host>/<Context>
, 该目录用于存放临时文件。StardardContext
只是一个容器,而ApplicationContext
则是一个应用程序真正的运行环境,相关类及操作会在请求处理流程看完以后进行补充。StardardContext
触发CONFIGURE_START_EVENT
生命周期事件,ContextConfig
开始调用configureStart()
对应用程序进行配置。- 这个过程会解析并合并
conf/web.xml
&conf/<Engine>/<Host>/web.xml.default
&webapps/<Context>/WEB-INF/web.xml
中的配置。 - 配置配置文件中的参数到
StandardContext
, 其中主要的包括 Servlet、Filter、Listener。 - 因为从 Servlet3.0 以后是直接支持注解的,所以服务器必须能够处理加了注解的类。Tomcat 通过分析
WEB-INF/classes/
中的 Class 文件和WEB-INF/lib/
下的 jar 包将扫描到的 Servlet、Filter、Listerner 注册到StandardContext
。 setConfigured(true)
,是非常关键的一个操作,它标识了 Context 的成功配置,若未设置该值为 true 的话,Context 会启动失败。
- 这个过程会解析并合并
Background process
- 后台进程的作用就是处理一下 Servlet 引擎中的周期性事件,处理周期默认是 10s。
- 特别的
StandardHost
的backgroundProcess()
方法会触发 Host 的PERIODIC_EVENT
生命周期事件。然后HostConfig
会调用其check()
方法对已加载并进行过重新部署的应用程序进行reload
或对新部署的应用程序进行热部署。热部署跟之前介绍的部署步骤一致,reload()
过程只是简单的顺序调用setPause(true)、stop()、start()、setPause(false)
,其中setPause(true)
的作用是暂时停止接受请求。