《omcat核心源码阅读笔记总结》由会员分享，可在线阅读，更多相关《omcat核心源码阅读笔记总结（19页珍藏版）》请在金锄头文库上搜索。
1、Tomcat6核心源码阅读笔记 2012-8-15 Calvin.chen 此次源码阅读基于tomcat6，官方svn地址：Tomcat6核心源码阅读笔记11、tomcat6整体结构22、tomcat6主要组件22.1 Server22.2 Servic22.3 Connector32.4 Container33、tomcat6核心类结构分析63.1核心类结构图63.2 tomcat启动过程主线图73.3请求处理类结构图83.4 Container类结构图93.5 Valve类结构图103.6 Pipeline和valve114、tomcat6如何实现多线程处理124.1多线程处理简图124.
2、2多线程处理详图134.3多线程处理过程中几个比较重要的方法144.4 多线程小结165、tomcat6处理一次请求的完整过程186、Tomcat6中的设计模式196.1 链式设计196.2 观察者模式191、 tomcat6整体结构2、tomcat6主要组件2.1 ServerTomcat server实例，需提供接口让其它程序能够访问到其中 Service 集合，同时要维护它所包含的所有 Service 的生命周期，包括如何初始化、如何结束服务、如何找到别人要访问的 Service。2.2 ServicService 只是在 Connector 和 Container 外面多包一层，把它们
3、组合在一起，向外面提供服务，同时通过lifecycle接口管理下属组件(Connector和Engine)的生命周期。一个 Service 可以设置多个 Connector，但是只能有一个 Container(可以是Engine、Host或者Context、Wrapper)。2.3 ConnectorConnector 组件是 Tomcat两个核心组件之一，它的主要任务是负责接收浏览器的发过来的 tcp 连接请求，创建一个 Request 和 Response 对象分别用于和请求端交换数据，然后会产生一个线程来处理这个请求并把产生的 Request 和 Response 对象传给处理这个请求的
4、线程，处理这个请求的线程就是 Container 组件要做的事了。2.4 ContainerContainer是容器的父接口，所有子容器都必须实现这个接口，Container还有一个抽象实现类ContainerBase，Engine、Host、Context、Wrapper的默认实现都继承了这个类。Container 容器的设计用的是典型的责任链的设计模式，它有四个子容器组件构成，分别是：Engine、Host、Context、Wrapper，这四个组件是父子关系，Engine 包含 Host,Host 包含 Context，Context 包含 Wrapper。通常一个 Servlet cl
5、ass 对应一个 Wrapper，如果有多个 Servlet 就可以定义多个 Wrapper，如果有多个 Wrapper 就要定义一个更高的 Container 了，如Context。Context 还可以定义在父容器 Host 中，Host 不是必须的，但是要运行 war 程序，就必须要 Host，因为 war 中必有 web.xml 文件，这个文件的解析就需要 Host 。如果要有多个 Host 就要定义一个 top 容器 Engine 。而 Engine 没有父容器了，一个 Engine 代表一个完整的 Servlet 引擎。总之保证一个Service只有一个top container(
6、这个top container里面可以有多个子container)。 Engine比较简单的一个容器，主要分负责管理子容器的周期。2.4.2 HostHost 是 Engine 的子容器，一个 Host 在 Engine 中代表一个虚拟主机，这个虚拟主机的作用就是运行多个应用，它负责安装和展开这些应用，并且标识这个应用以便能够区分它们。它的子容器通常是 Context，它除了关联子容器外，还有就是保存一个主机应该有的信息。关于Host中name属性和Engine中defaultHost的作用： 如果有个host的name = localhost，那么Tomcat会将此host设置为默认访问的H
7、ost。即：如果出现下图中的情况，则client最终会去访问name=localhost的host，而不是defaultHost值定义的host(即不会去访问192.168.0.102)Tomcat产生的server实例ServiceConnectorsHost_BNEngine defaultHostHost_ANClient访问2.4.3 ContextContext 代表 Servlet 的 Context，它具备了 Servlet 运行的基本环境，理论上只要有 Context 就能运行 Servlet 了。简单的 Tomcat 可以没有 Engine 和 Host。Context 最重
8、要的功能就是管理它里面的 Servlet 实例，Servlet 实例在 Context 中是以 Wrapper 出现的。Context 如何才能找到正确的 Servlet 并执行它：在请求处理过程中，会调用CoyoteAdapter.postParseRequest()方法封装request，其中就包含这样一行代码：connector.getMapper().map(serverName, decodedURI, request.getMappingData();这行代码会封装request中MappingDatas属性的值，而MappingDatas中就包含的host、context、wra
9、pper及其path的信息。(在connector的mapper对象中已经记录了该connector对应的engine中的所有host，在mapper.map()方法中会通过解析request的url字符串，逐步得到host、context、wrapper)。封装完MappingDatas之后，就会调用下面这行代码，绑定request和Wrapper对象：request.setWrapper(Wrapper) request.getMappingData().wrapper);最后在StandardWrappValve.invoke()方法中调用StandardWrappValve所属Cont
10、ainer(即：Wrapper)的allocate()，即调用Wrapper.allocate()得到对应的servlet对象。 WrapperWrapper 代表一个 Servlet，它负责管理一个 Servlet，包括的 Servlet 的装载、初始化、执行以及资源回收。Wrapper 是最底层的容器，它没有子容器了，所以调用它的 addChild 将会报错。Wrapper 的实现类是 StandardWrapper，StandardWrapper实现了拥有一个 Servlet 初始化信息的 ServletConfig，由此看出 StandardWrapper 将直接和 Servlet 的
11、各种信息打交道。StandardWrapperFacade：Wrapper的一个重要属性，对Wrapper做了一次封装，和 Wrapper一样实现了ServletConfig。Wrapper中的重要方法：loadServlet()，该方法包含对servlet的基本操作，包括调用init()和service()方法。3、tomcat6核心类结构分析3.1核心类结构图3.2 tomcat启动过程主线图Tomcat中，几乎所有组件都实现了Lifecycle接口，父组件并通过Lifecycle接口管理子组件的生周期。从下图可以看出，在Engine、Host、Context和Wrapper四个组件才是T
12、omcat中真正的容器(实现了Container接口)，而Server和Service只是在它们上做的一层封装而已。3.3请求处理类结构图3.4 Container类结构图3.5 Valve类结构图3.6 Pipeline和valve4、tomcat6如何实现多线程处理4.1多线程处理简图4.2多线程处理详图 tomcat6提供了两种方式来处理多线程：1、 tomcat6自己写代码维护多线程处理(上图分析采用的方式)2、 tomcat6也提供了通过executor处理多线程的方式从代码上看：第2种是完全将线程调度交给executor来做，会简单很多。从学习和可维护性来说：第1种给我展示一个很好
13、的处理多线程场景的学习案例，而且根据一些网上测试结果看，两种方式性能相差不大，默认情况下tomcat6也不使用executor。4.3多线程处理过程中几个比较重要的方法4.4 多线程小结对Tomcat多线程处理机制可以简单的概括为：两个线程池 + 线程切换调度 + 线程开关 + 线程回收。对于开发人员来说，可以通过配置文件(server.xml)来进行调优，使服务器效率达到最佳。但参数并不是越大越好，过大反而会导致线程阻塞，甚至内存溢出，因为每个请求对于服务器来说都一个单独的线程，大量的请求就导致线程并发，而线程并发对于服务器来说要靠CPU来进行大量线程切换调度或新增，而每次线程切换或新增JV
14、M要去保存当前线程内容、申请内存、初始化内存等非常消耗CPU、内存和时间操作，导致服务器效率降低，所以还是的根据服务器的实际硬件配置进行调优。我想这也是为什么tomcat会对线程进行回收的原因。（如果XmsJVM堆初始化大小设置的比较小时，大并发导致使用内存超过该值(但没有达到XmxJVM堆最大内存值)，这时JVM就需要频繁的向操作系统申请内存来扩大堆容量，而JVM向操作系统负申请内存空间将会非常耗CPU和内存，这也是为什么在大并发应用中会把Xms和Xmx设置成一样或相近，但如果堆内存达到Xmx值，那么JVM就会进行垃圾回收，来获得内存空间。另外需要注意的是，虚拟机的堆大小决定了虚拟机花费在收
15、集垃圾上的时间和频度，调整堆大小的目的是最小化垃圾收集的时间，以在特定的时间内最大化处理客户的请求。堆越大，垃圾回收扫描的内存空间就越大，cpu和内存消耗也就越大，如果系统花费很多的时间收集垃圾，可以减小堆大小。从网上一些资料来看：完全一次垃圾收集应该不超过 3-5 秒，一般说来使用物理内存的 80% 作为堆大小。当增加处理器时，记得增加内存，因为分配可以并行进行，而垃圾收集不是并行的。）有一种情况需要注意：当tomcat线程数增大，但没有超过最大线程数时，平均响应时间会增大，但这不意味着tomcat在线程增多时响应速度变慢可能是由于线程数增多，在请求时需要排队，导致一部分请求会一直排队，随着线程数的增多，排队等待的最大时间也会越来越大，而这些大数据才是导致平均响应时间变大的原因 下面是几个配置项的说明：Server.xml中的几个配置项说明.maxThreadsTomcat处理请求的最大线程数，也决定了tomcat的最大并发数，默认为200个。如果connector使用了executor执行处理线程，那么connect
