Spring MVC源码分析—Tomcat分析
2018-01-06 15:17
351 查看
Tomcat分析
Tomcat的顶层结构
1)Tomcat中最顶层的容器是Server(一个Tomcat中只有一个Server),代表整个服务器。
2)Server中包含至少一个Service,用于具体提供服务。
3)Service主要包括两部分:Connector和Container。一个Service只有一个Container,但可以有多个Connector。
4)Connector用于处理连接相关的事情,并提供Socket与request、response的转换。
5)Container用于封装和管理Servlet,以及具体处理request请求。
6)Tomcat里的Server有org.apache.catalina.startup.Catalina来管理,Catalina是整个Tomcat的管理类,它里面的三个方法load、start、stop分别用来管理整个服务器的声明周期。
注:
1)Tomcat内部设计load、start、stop都会按容器的结构逐层调用相应的方法。(比如,Server的start方法会调用所有Service的start方法,Service中的start方法又会调用所有包含的Connector和Container的start方法,这样整个服务器就启动了,init和stop方法也一样。)
2)Tomcat启动,依次调用顺序为:Bootstrap ——> Catalina ——> Server ——> Service
Tomcat的声明周期
Key Point:
1) Tomcat通过org.apache.catalina.Lifecycle接口统一管理生命周期,所有生命周期的组件都要实现Lifecycle接口
2)Lifecycle的默认实现是org.apache.catalina.util.LifecycleBase,所有实现了生命周期的组件都直接或间接地继承自LifecycleBase
Container
3.1 Container结构图
3.2 Container简介
1)Container一共有4个子接口Engine、Host、Context、Wrapper和一个默认实现类ContainerBase。
2)每个子接口都是一个容器,这4个子容器都有一个对应的StandardXXX实现类,并且这些实现类都继承ContainerBase类。
3)Engine、Host、Context、Wrapper这4个子容器都符合Tomcat生命周期管理模式。
4)Engine是最顶层,每个Service最多只能有一个Engine,一个Engine可以有多个Host,每个Host下可以有多个Context,每个Context下可以有多个Wrapper,他们的装配关系如下所示:
4个容器的作用:
Engine:引擎,用来管理多个站点,一个Service最多只能有一个Engine
Host:代表一个站点,也可以叫虚拟主机,通过配置Host就可以添加站点
Context:代表一个应用程序,对应着平时开发的一套程序,或者一个WEB-INF目录以及下面的web.xml文件
Wrapper:每个Wrapper封装着一个Servlet
3.3 子容器配置方法
1)Engine和Host的配置都在conf/server.xml文件中,server.xml文件是Tomcat中最重要的配置文件,Tomcat的大部分功能都可以在这个文件中配置。
2)Context有三种配置方法:
3)Wrapper的配置就是我们在web.xml中配置的Servlet,一个Servlet对应一个Wrapper
注:
同一个Service下的所有站点由于是共享Connector,所以监听的端口都一样。
如果想要添加监听不同端口的站点,可以通过不同的Service来配置。
Pipeline-Value管道
Pipeline-Value处理模式:
Pipeline-Value的管道模式有些类似于责任链模式,但和普通的责任链模式稍有不同:
4个容器的BaseValue分别是:
StandardEngineBalue、StandardHostValue、StandardContextValue、StandardWrapperValue
Pipeline处理流程:
Connector
Connector用于接收请求并将请求封装成Request和Response来具体处理,最底层是使用Socket来进行连接的,Request和Response是按照HTTP协议来封装的,所以Connector同时实现了TCP/IP协议和HTTP协议,Request和Response封装完之后交给Container进行处理,Container就是Servlet的容器,Container处理完之后返回给Connector,最后Connector使用Socket将处理结果返回给客户端,这样整个请求就处理完了。
5.1 Connector结构关系图
1)Connector中具体是用ProtocolHandler来处理请求的。
2)ProtocolHandler有3个非常重要的组件:Endpoint、Processor和Adapter。
3)Endpoint的抽象实现AbstractEndpoint里面定义的Acceptor和AsyncTimeout两个内部类和一个Handler接口。
Tomcat分析到此结束,待以后有时间再详细展开!博主设计,仅供参考!
Tomcat的顶层结构
1)Tomcat中最顶层的容器是Server(一个Tomcat中只有一个Server),代表整个服务器。
2)Server中包含至少一个Service,用于具体提供服务。
3)Service主要包括两部分:Connector和Container。一个Service只有一个Container,但可以有多个Connector。
4)Connector用于处理连接相关的事情,并提供Socket与request、response的转换。
5)Container用于封装和管理Servlet,以及具体处理request请求。
6)Tomcat里的Server有org.apache.catalina.startup.Catalina来管理,Catalina是整个Tomcat的管理类,它里面的三个方法load、start、stop分别用来管理整个服务器的声明周期。
注:
1)Tomcat内部设计load、start、stop都会按容器的结构逐层调用相应的方法。(比如,Server的start方法会调用所有Service的start方法,Service中的start方法又会调用所有包含的Connector和Container的start方法,这样整个服务器就启动了,init和stop方法也一样。)
2)Tomcat启动,依次调用顺序为:Bootstrap ——> Catalina ——> Server ——> Service
Tomcat的声明周期
Key Point:
1) Tomcat通过org.apache.catalina.Lifecycle接口统一管理生命周期,所有生命周期的组件都要实现Lifecycle接口
2)Lifecycle的默认实现是org.apache.catalina.util.LifecycleBase,所有实现了生命周期的组件都直接或间接地继承自LifecycleBase
Container
3.1 Container结构图
3.2 Container简介
1)Container一共有4个子接口Engine、Host、Context、Wrapper和一个默认实现类ContainerBase。
2)每个子接口都是一个容器,这4个子容器都有一个对应的StandardXXX实现类,并且这些实现类都继承ContainerBase类。
3)Engine、Host、Context、Wrapper这4个子容器都符合Tomcat生命周期管理模式。
4)Engine是最顶层,每个Service最多只能有一个Engine,一个Engine可以有多个Host,每个Host下可以有多个Context,每个Context下可以有多个Wrapper,他们的装配关系如下所示:
4个容器的作用:
Engine:引擎,用来管理多个站点,一个Service最多只能有一个Engine
Host:代表一个站点,也可以叫虚拟主机,通过配置Host就可以添加站点
Context:代表一个应用程序,对应着平时开发的一套程序,或者一个WEB-INF目录以及下面的web.xml文件
Wrapper:每个Wrapper封装着一个Servlet
3.3 子容器配置方法
1)Engine和Host的配置都在conf/server.xml文件中,server.xml文件是Tomcat中最重要的配置文件,Tomcat的大部分功能都可以在这个文件中配置。
2)Context有三种配置方法:
a) 通过文件配置 b) 将war应用直接放到Host目录下,Tomcat会自动查找并添加到Host中 c) 将应用的文件夹放到Host目录下,Tomcat也会自动查找并添加到Host中
3)Wrapper的配置就是我们在web.xml中配置的Servlet,一个Servlet对应一个Wrapper
注:
同一个Service下的所有站点由于是共享Connector,所以监听的端口都一样。
如果想要添加监听不同端口的站点,可以通过不同的Service来配置。
Pipeline-Value管道
Pipeline-Value处理模式:
Pipeline-Value的管道模式有些类似于责任链模式,但和普通的责任链模式稍有不同:
a) 每个Pipeline都有特定的Value,而且是在管道的最后一个执行,这个Value叫BaseValue,是不可删除的。 b) 在上层容器的管道的BaseValue中会调用下层容器的管道。
4个容器的BaseValue分别是:
StandardEngineBalue、StandardHostValue、StandardContextValue、StandardWrapperValue
Pipeline处理流程:
Connector
Connector用于接收请求并将请求封装成Request和Response来具体处理,最底层是使用Socket来进行连接的,Request和Response是按照HTTP协议来封装的,所以Connector同时实现了TCP/IP协议和HTTP协议,Request和Response封装完之后交给Container进行处理,Container就是Servlet的容器,Container处理完之后返回给Connector,最后Connector使用Socket将处理结果返回给客户端,这样整个请求就处理完了。
5.1 Connector结构关系图
1)Connector中具体是用ProtocolHandler来处理请求的。
2)ProtocolHandler有3个非常重要的组件:Endpoint、Processor和Adapter。
Endpoint::用于处理底层Socket的网络连接(用来实现TCP/IP协议) Processor:用于将Endpoint接收到的Socket封装成Request(用来实现HTTP协议) Adapter:用于将封装好的Request交给Container进行具体处理(将请求适配到Servlet容器进行具体处理)
3)Endpoint的抽象实现AbstractEndpoint里面定义的Acceptor和AsyncTimeout两个内部类和一个Handler接口。
Acceptor用于监听请求 AsyncTimeout用于检查异步request的超时 Handler用于处理接收到的Socket,在内部调用了Processor进行处理
Tomcat分析到此结束,待以后有时间再详细展开!博主设计,仅供参考!
相关文章推荐
- Spring MVC源码分析—Tomcat分析
- tomcat8源码分析(一):导入eclipse
- [置顶] Spring Boot系列十二 通过redis实现Tomcat集群的Session同步及从源码分析其原理
- Tomcat源码分析 -- Tomcat整体架构
- Tomcat源码分析-JMX(下)
- [Tomcat] Coyote连接器框架源码分析
- 从Tomcat中得到更多-Tomcat的源码分析
- Tomcat7源码分析-Digester
- Tomcat源码分析(三)------ 可携带状态的线程池 .
- Tomcat 热部署实现方式源码分析总结
- Spring源码分析【5】-Spring MVC处理流程
- Tomcat源码分析(一)
- tomcat server组件监听shutdown命令关闭服务器之源码分析
- tomcat8.5 源码分析(一)导入eclipse
- Tomcat源码学习(五)-- Tomcat_7.0.70 类加载体系分析
- Tomcat8源码分析(四)
- spring mvc框架源码分析(二)-自定义注解以及通过反射获取注解
- tomcat的url-pattern的源码分析
- Tomcat源码分析(一)--服务启动
- 【Spring MVC】Spring MVC启动过程源码分析