窥探Tomcat整体架构,server.xml常用配置解析
Posted 徐同学呀
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了窥探Tomcat整体架构,server.xml常用配置解析相关的知识,希望对你有一定的参考价值。
首发CSDN:徐同学呀,原创不易,转载请注明源链接。我是徐同学,用心输出高质量文章,希望对你有所帮助。
一、前言
server.xml
配置,是 Tomcat
启动配置,从配置结构可以看出 Tomcat
的整体架构。如果能够了解其常用配置项,对 Tomcat
有一个高屋建瓴的把握,然后再庖丁解牛,一步步深入源码中分析每一个核心功能的实现细节,这样会有事半功倍的效果。
server.xml配置示例
- 如上图
server.xml
配置,最外层是一个Server
,代表Tomcat
的运行实例。Server
里有一些监听器Listener
,一个不知道干啥的GlobalNamingResources
,还有一个Service
,通过阅读源码,发现一个Server
里可以有多个Service
。 Service
可以理解为是对部署在Tomcat
里的服务的抽象,一个Tomcat
可以部署多个服务,但是我更喜欢把一个Service
理解成一个服务集合或者集群。Service
里有一个Executor
、Connector
和Engine
。Executor
是一个线程池,可以供Contector
使用;Connector
定义了协议连接(HTTP/AJP),外界就是通过Connector
访问Service
里的服务的;Engine
是容器引擎,可以理解它为Servlet
容器,真正的业务处理在Engine
里。通过阅读源码,一个Service
可以有多个Executor
,多个Connector
,一个Engine
。如果把Service
比作一个房子,Connector
比作门,一个房子可以有多个门就好理解了。Engine
内部较复杂,它内部就像俄罗斯套娃,有多个子容器,子容器下又可以有多个子容器。正如Engine
的英文含义,引擎,驱动和管理内部子容器。因为是最顶端的管理者,会包含一些组件辅助管理子容器。Engine
可以有多个Host
容器,可以理解为虚拟主机(URL地址中主机部分抽象);Host
容器里有多个Context
容器,Context
就是一个个Web应用;Context
容器里有多个Wrapper
容器,server.xml
中一般不用配置,Wrapper
是对Servlet的包装,就是一个个业务功能了。- 如果对应上
Service
房子的比喻,Engine
可以比作房子里所有房间的总和,或者是通向每个房间的走道,Host
就是一个个房间,房间里有一些家具家电(Context
),每一个家具家电有很多功能(Wrapper
)。
二、Tomcat运行实例Server
Server
是Tomcat
运行实例的抽象,管理着内部多个服务。在Tomcat源码中Server的默认标准实现是org.apache.catalina.core.StandardServer
:
- 默认有6个生命周期监听器,监听Server不同运行阶段的事件并作出响应。
- GlobalNamingResources全局命名资源,通过JNDI提供统一的命名对象访问接口。
- Server监听了一个端口,默认8005,如果这个端口传来SHUTDOWN指令,则关闭Tomcat。
- Server还有两个定时任务,监听触发一些在Tomcat整个生命周期里周期性事件,暂时只有自动部署。
1、生命周期监听器
(1)VersionLoggerListener
org.apache.catalina.startup.VersionLoggerListener
监听初始化阶段,输出一些运行日志,如操作系统、JDK
、Tomcat
版本信息以及catalina.base
、catalina.home
的定义等。
(2)AprLifecycleListener
Tomcat可以使用APR本地库从操作系统级别解决异步IO问题,通过JNI方式调用APR本地库大幅提高对静态资源的处理性能。org.apache.catalina.core.AprLifecycleListener
对初始化前的事件和销毁后的事件感兴趣:
- 在Tomcat初始化前,
AprLifecycleListener
尝试初始化APR库,如果初始化成功,则使用APR接收并处理客户端的请求。 - 在Tomcat销毁后,
AprLifecycleListener
会对APR做一些销毁终止操作。
(3)JreMemoryLeakPreventionListener
org.apache.catalina.core.JreMemoryLeakPreventionListener
监听器会在Tomcat
初始化时使用系统类加载器预先加载一些JRE的类和设置URLConnection
缓存禁用属性,以避免线程上下文类加载器是Tomcat
自定义的Webappclassloader
时,加载JRE导致的内存泄漏和URLConnection
缓存导致的锁文件问题。
(4)GlobalResourcesLifecycleListener
org.apache.catalina.mbeans.GlobalResourcesLifecycleListener
会在Tomcat
启动时为JNDI
创建MBean
,停止时销毁MBean
。
(5)ThreadLocalLeakPreventionListener
org.apache.catalina.core.ThreadLocalLeakPreventionListener
监听器监听Context
停止后,销毁连接器Connector
中Executor
的所有核心工作线程,并重新创建,以避免使用ThreadLocal
带来的内存泄漏。
(6)NamingContextListener
org.apache.catalina.core.NamingContextListener
监听器在Tomcat启动时创建并绑定全局命名资源,在Tomcat停止前做一些解绑全局命名资源、反注册销毁等操作。
2、GlobalNamingResources
GlobalNamingResources
全局命名资源,通过JNDI提供统一的命名对象访问接口。而JNDI(Java Naming and Directory Interface
)是一个比较老旧的技术,在历史遗留的企业级应用中可能还在用,诸如获取一个数据库连接资源、自定义配置等,这种强耦合在启动配置文件里的方式已经不适用现在轻量级的应用和分布式服务了。(后续可以单独研究下,这里了解即可。)
3、监听SHUTDOWN命令
Tomcat
启动时,主线程做完所有启动工作后,会进入循环等待SHUTDOWN
的状态。如果接收到SHUTDOWN
,结束循环调用Tomcat
停止销毁接口。
实现方式很简单,单独给主线程建立一个socket
连接,时刻监听某个端口(默认8005),是否发来SHUTDOWN
命令。
4、定时触发自动部署周期性事件
Server
启动时,会开启两个定时任务,一个是每10秒触发一次自动部署事件,而这个定时任务可能会因为自动部署的检查和部署过程中出现异常导致该定时任务停止,所以就有了另一个定时任务每1分钟检查一次自动部署定时任务是否有在正常运行,没有就重新设置。(自动部署是Host
的工作,在Host的生命周期监听器HostConfig
中监听执行)
三、服务抽象Service
Service
默认标准实现是org.apache.catalina.core.StandardService
,如果在Server
中配置了多个Service
,name
必须唯一,不可重复。
Service
包含的组件有Executor
、Connector
、Engine
,还有一个Mapper
组件没有在配置中体现,一般也不需要配置。
1、共享线程池Executor
Service
中可以定义一些线程池,供Connector
和其他组件使用。Tomcat
没有另起炉灶实现自己的线程池,而是在JUC的ThreadPoolExecutor
基础上做了定制化改造,默认标准实现是org.apache.catalina.core.StandardThreadExecutor
。
Executor
可配置项如下:
配置项 | 备注 | 默认值 |
---|---|---|
name | 线程池名称,必须唯一,供其他组件直接引用 | |
className | Executor的实现类名称 | org.apache.catalina.core.StandardThreadExecutor |
namePrefix | 指定线程池中线程的名称前缀。 | tomcat-exec- |
maxThreads | 最大线程数 | 200 |
minSpareThreads | 核心线程数 | 25 |
threadPriority | 工作线程优先级别 | NORM_PRIORITY(5) |
daemon | 工作线程是否为守护线程 | true |
maxIdleTime | 非核心工作线程空闲时存活时间 | 60000ms |
prestartminSpareThreads | 是否在启动Executor时创建核心工作线程 | false |
maxQueueSize | 任务队列最大容量 | Integer.MAX_VALUE |
threadRenewalDelay | Context停止时,会销毁重建工作线程,为避免同一时间重建所有线程,该参数指定任意两个线程之间的创建延迟时间 | 1000ms |
注意:
如果指定Executor
的实现是StandardThreadExecutor
,那么prestartminSpareThreads
无论是true还是false,都会预先创建minSpareThreads
个核心工作线程。
2、连接器Connector
Connector
是Service
的门户,一个Service
可以有多个Connector
。Connector
定义了多种连接协议,配置较为复杂,现仅提供常见配置说明:
配置项 | 备注 | 默认 |
---|---|---|
executor | 引用Executor的名称,如果为空,则会自己新建一个私有的线程池使用。 | |
port | 服务端socket监听的端口号,用于等待请求连接,如果设置为0,则会随机分配一个可用端口。 | |
protocol | 协议,可以填HTTP/1.1或AJP/1.3,也可以填具体的协议实现类如org.apache.coyote.http11.Http11NioProtocol或org.apache.coyote.ajp.AjpNioProtocol等 | HTTP/1.1 |
connectionTimeout | 接收连接等待超时时间,-1表示不超时。 | 60000ms |
acceptCount | 当所有请求处理线程都被占用时,socket等待请求队列的最大长度。 | 100 |
redirectPort | 非SSL请求重定向到指定SSL端口。 | 443 |
URIEncoding | URI解析编码 | UTF-8 |
maxPostSize | post请求的最大字节数,0或者负数则没有限制 | 2 * 1024 * 1024(2MB) |
maxHttpHeaderSize | HTTP消息头的最大字节数 | 8 * 1024 |
maxConnections | 服务端接收处理的最大连接数,是设置给LimitLatch限流器的,如果超过该值,则会阻塞等待,此时依然会接收连接,但是不能超过acceptCount,否则拒绝连接。 | 8*1024 |
注意:
Tomcat10.0.6
中NioEndpoint
已经不能配置Poller
线程和acceptor
线程的个数,默认都是一个,同时AprEndpoint
也标注为不建议使用,所以关于APR
的配置也可以不用深入了解。后面会详细研究Connector的内部实现,到时讲解其他与源码相关的配置项。
3、容器引擎Engine
Engine
是Servlet
容器最顶端的管理者,负责处理对应Service中所有请求,包含多个Host和其他组件。默认标准实现是org.apache.catalina.core.StandardEngine
。Engine
以及其子容器都继承自ContainerBase
,都有些相似的组件,如AccessLog
、Pipeline
、Cluster
、Realm
、Log
、LifecycleListener
、ContainerListener
等。
Engine
、Host
、Context
都有一个同名前缀的LifecycleListener
,如Engine
的是EngineConfig
,Host
的是HostConfig
,Context
是ContextConfig
,分别监听自己感兴趣的生命周期事件,如EngineConfig
就是在Engine
启动停止时输出一些日志。
对于Engine节点可选配置有如下几个:
配置项 | 备注 | 默认 |
---|---|---|
name | engine的名称,用于日志输出,必须唯一。 | |
defaultHost | 默认Host名称,当请求找不到Host时,就用该默认Host | |
backgroundProcessorDelay | 后台线程处理延迟时间。 | 10s |
startStopThreads | 用于启动和停止子容器的线程数 | 1 |
注意:
- Engine即其子容器
Host
、Context
、Wrapper
都可以设置backgroundProcessorDelay
这个参数,都可以有自己的后台线程来延迟backgroundProcessorDelay
时长周期性处理一些事情。如果backgroundProcessorDelay<=0
则不会创建私有的后台线程,默认Engine中这个参数是10,其他子容器是-1,所以一般情况子容器需要后台处理的事情,都交由Engine启动的后台线程周期性延迟处理。 - 上层容器启动停止下层容器时,会用一个线程池来做异步处理。
4、URI映射器Mapper
Service
中Mapper
组件主要提供给Connector
和Context
使用,Connector
中处理完连接后需要将请求信息交给对应的Host
处理,可以通过Mapper
的解析找到Host
;Context
通过Mapper
找到对应的Servlet
(Wrapper
)处理业务。
Mapper
还有一个对应的生命周期监听器MapperListener
,其主要监听容器启动后,将容器注册到Mapper的关系中,建立一个树状结构。容器停止后做一些销毁、反注册操作。
(详细的Mapper
原理后面会单独出文章讲解)
四、虚拟主机Host
Host
是Engine
的子容器,默认标准实现是org.apache.catalina.core.StandardHost
。它的主要职责就是管理和部署子容器Context
,比如,Host启动前,预先创建好部署web应用的目录;Host
启动时,部署web应用;Host
运行过程中,周期性检查web应用是否需要自动部署,这些监听工作都是在HostConfig
中做的。
如下是Host的一些常用配置:
配置项 | 备注 | 默认 |
---|---|---|
name | Host名称,必须要有一个Host名称与Engine的defaultHost对应。 | |
appBase | web应用基础目录,可以是绝对路径,也可以是相对路径(相对于CATALINA_BASE) | webapps |
unpackWARs | Context启动时是否将appBase目录下的war包解压。 | true |
autoDeploy | 开启热部署,即在Tomcat运行阶段,定期检查和自动部署appBase和xmlBase目录下有无新增或者更新的web应用。 | true |
createDirs | 若设置为true,Host在启动时预先创建好appBase和xmlBase目录。 | true |
backgroundProcessorDelay | 后台线程处理延迟时间。一般不需要配置,直接用Engine的后台线程。 | -1 |
workDir | Host下web应用的临时目录。每个web应用都有自己的临时目录,如果Context中设置了workDir,则Host中的配置会被覆盖。web应用中的Servlet将通过ServletContext的jakarta.servlet.context.tempdir属性访问workDir。 | %CATALINA_BASE%/work/[EngineName]/[HostName]/ContextName |
deployOnStartup | 若设置为true,Host在启动时自动部署web应用。 | true |
xmlBase | XML基础目录,即context描述文件方式部署的路径,可以是绝对路径,也可以是相对路径(相对于CATALINA_BASE)。 | %CATALINA_BASE%/conf/[EngineName]/[HostName]/ |
Host部署web应用
Host部署web应用(Context)的三种方式:
Context
描述文件部署,默认是%CATALINA_BASE%/conf/[EngineName]/[HostName]/
目录下,可以有多个Context
配置,后缀必须为.xml
。可以通过xmlBase
指定Context配置文件存放目录。- WAR包部署,即将web应用打包成一个
.war
部署,默认放在%CATALINA_BASE%/webapps
目录下,可以通过appBase
指定一个绝对路径。 - 目录部署,默认也是放在
%CATALINA_HOME%/webapps
目录下。
三种部署的过程都是解析实例化Context
,而后两者web应用可能有自己的META-INF/context.xml
,则通过解析它来组装生成Context
,否则就解析全局的%CATALINA_BASE%/conf/context.xml
。
五、Web应用Context
Context
是对Web应用的抽象,相对其他容器有很多组件,且结构上复杂很多。默认标准实现是org.apache.catalina.core.StandardContext
,其主要的职责有:
Wrapper
管理,Context
下有很多Wrapper
,Wrapper
是对Servlet
的包装抽象,是最小的容器。- 错误页面
ErrorPage
管理,在web.xml
里可以配置请求处理过程中发生异常重定向的页面路由。 - 会话
Session
管理。 - Jar包扫描和加载,一个Context有一个自定义类加载,扫描和加载
/WEB-INF/lib
下的jar包。 - 热加载,定期检查
/WEB-INF/lib
和/WEB-INF/classes
目录下的.jar
和.class
文件是否更新,更新了就重新加载。热加载过程较消耗资源,仅适用于开发环境,不可用于生产环境。 ServletContainerInitializer
的初始化。- 除了生命周期监听器外,还有很多其他监听器。
- 实例管理。
- 静态资源缓存管理。
Context常用配置如下
配置项 | 备注 | 默认 |
---|---|---|
path | web应用路径,同一个Host下必须唯一。如果path为空字符串,意味着为当前Host指定了默认web应用,该应用会处理根路径下的所有请求。这个属性只有在server.xml里配置Context有用,单独的Context配置文件里不会生效,会通过context文件名或docBase生成path。 | |
reloadable | 若设置为true,则开启热加载,即后台线程会定期检查/WEB-INF/lib和/WEB-INF/classes目录下的.jar和.class文件是否更新,如果更新,则重加载。 | false |
docBase | web应用目录或者war包部署路径。可以是绝对路径,也可以是相对路径(相对于Host的appBase)。 | |
workDir | web应用的临时目录,如果配置了,会覆盖Host中配置的workDir。 | |
backgroundProcessorDelay | 后台线程处理延迟时间。一般不需要配置,直接用Engine的后台线程。 | -1 |
Resources配置
Resources是对静态资源的抽象,可以设置缓存以提高响应性能。默认标准实现是org.apache.catalina.webresources.StandardRoot
。
配置项 | 备注 | 默认 |
---|---|---|
cacheMaxSize | 静态资源缓存最大值 | 10MB |
cacheObjectMaxSize | 单体静态资源最大值 | 512KB |
cacheTtl | 缓存失效时间 | 5000ms |
cachingAllowed | 是否使用缓存 | true |
StandardRoot
中有五种WebResourceSet
:preResources、mainResources、classResources、jarResources、postResources,支持的配置如下:
配置项 | 备注 | 默认 |
---|---|---|
base | 资源的位置,用于指定文件、目录或者jar包的绝对路径。 | |
webAppMount | 当前资源挂载的web应用内部路径,如果添加一个jar包目录,可以将其挂载在/WEB-INF/lib下,必须“/”开头。 | / |
className | 资源实现类。可选实现类有:org.apache.catalina.webresources.DirResourceSet,org.apache.catalina.webresources.JarResourceSet,org.apache.catalina.webresources.FileResourceSet | |
internalPath | 资源的内部路径,通常用于jar内文件的加载。必须“/”开头。 | / |
readOnly | 资源是否可读,如果设置为true,资源将不会删除、创建、修改。 | false |
六、Servlet包装器Wrapper
Wrapper
相对于Engine
、Host
、Context
是最小的容器,其父容器必须是Context
,没有其他子容器。默认标准实现是org.apache.catalina.core.StandardWrapper
。一般情况一个Servlet
对应一个Wrapper
,这就是为什么Servlet
不是线程安全的了,Servlet
以单例的实现存在,多个线程访问肯定不是线程安全的,虽然有Servlet
对象池的选择,但是Tomcat10.0.6
已经不建议这样做。
七、要点总结
本篇只对server.xml
常用的配置进行解释,并通过配置文件节点关系,大概梳理了Tomcat
整体架构。
Tomcat是一个非常优秀的开源项目,值得揉碎了仔细研究的细节实在太多,比如:
- 线程池定制化改造;
- 连接
Connector
的设计以及如何连接到容器Engine
的; Mapper
组件如何解析映射URI;- 一个请求的处理和响应过程;
- 生命周期框架的设计;
- 自定义类加载器加载机制,如何做到隔离和共享,如何打破双亲委派;
- 热部署,热加载的实现细节;
- 如何解析
server.xml
配置; - 部署web应用的细节;
- 容器之间如何做到有序连接,
Pipeline
和Valve
的实现细节; Servlet
如何实现双向过滤;- 各种监听器
- 等等
后续会一个个详细解读,敬请期待。
非常感谢以下两本书:
- 《Tomcat内核设计剖析》汪建著
- 《Tomcat架构解析》刘光瑞著
- 参考源码Tomcat10.0.6和Tomcat8.5.9
Tomcat源码详细注释链接(非推广,持续更新):https://gitee.com/stefanpy/tomcat-source-code-learning
如若文章有错误理解,欢迎批评指正,同时非常期待你的评论、点赞和收藏。
以上是关于窥探Tomcat整体架构,server.xml常用配置解析的主要内容,如果未能解决你的问题,请参考以下文章