Tomcat6源代码分析-架构解析-CSDN博客

1. Tomcat的整体框架结构
Tomcat的基本框架，分为4个层次。
Top Level Elements:
Server
Service
Connector
HTTP
AJP
Container
Engine
Host
Context
Component
manager
logger
loader
pipeline
valve
...
站在框架的顶层的是Server和Service
Server: 其实就是BackGroud程序，在Tomcat里面的Server的用处是启动和监听服务端事件（诸如重启、关闭等命令。在tomcat的标准配置文件：server.xml里面，我们可以看到 “<server port="8005" shutdown="SHUTDOWN" debug="0">”这里的"SHUTDOWN"就是server在监听服务端事件的时候所使用的命令字） Service：在tomcat里面， service是指一类问题的解决方案。通常我们会默认使用tomcat提供的：Tomcat-Standalone 模式的service。在这种方式下的service既给我们提供解析jsp和servlet的服务，同时也提供给我们解析静态文本的服务。 Connector: Tomcat都是在容器里面处理问题的，而容器又到哪里去取得输入信息呢？ Connector就是专干这个的。他会把从socket传递过来的数据，封装成Request, 传递给容器来处理。 通常我们会用到两种Connector,一种叫http connectoer，用来传递http需求的。另一种叫AJP，在我们整合apache与 tomcat工作的时候， apache与tomcat之间就是通过这个协议来互动的。（说到apache与tomcat的整合工作，通常我们的目的是为了让apache 获取静态资源，而让tomcat来解析动态的jsp或者servlet。） Container: 当http connector把需求传递给顶级的container: Engin的时候，我们的视线就应该移动到Container这个层面来了。 在Container这个层，我们包含了3种容器： Engin, Host, Context. Engin: 收到service传递过来的需求，处理后，将结果返回给service( service 是通过 connector 这个媒介来和Engin互动的 ). Host: Engin收到service传递过来的需求后，不会自己处理，而是交给合适的Host来处理。 Host在这里就是虚拟主机的意思，通常我们都只会使用一个主机，既“localhost”本地机来处理。 Context: Host接到了从Host传过来的需求后，也不会自己处理，而是交给合适的Context来处理。 比如： http://127.0.0.1:8080/foo/index.jsp>; http://127.0.1:8080/bar/index.jsp>; 前者交给foo这个Context来处理，后者交给bar这个Context来处理。 很明显吧！ context的意思其实就是一个web app的意思。 我们通常都会在server.xml里面做这样的配置 <context path="/foo" docbase="D:/project/foo/web"></context> 这个context容器，就是用来干我们该干的事儿的地方的。 Compenent: 接下来，我们继续讲讲component是干什么用的。 我们得先理解一下容器和组件的关系。 需求被传递到了容器里面，在合适的时候，会传递给下一个容器处理。 而容器里面又盛装着各种各样的组件，我们可以理解为提供各种各样的增值服务。 manager: 当一个容器里面装了manager组件后，这个容器就支持session管理了，事实上在tomcat里面的session管理，就是靠的在context里面装的manager component. logger: 当一个容器里面装了logger组件后，这个容器里所发生的事情，就被该组件记录下来啦！我们通常会在logs/ 这个目录下看见 catalina_log.time.txt 以及 localhost.time.txt 和 localhost_examples_log.time.txt。这就是因为我们分别为：engin, host以及 context(examples)这三个容器安装了logger组件，这也是默认安装，又叫做标配：） loader: loader这个组件通常只会给我们的context容器使用， loader是用来启动context以及管理这个context的classloader用的。 pipline: pipeline 是这样一个东西，当一个容器决定了要把从上级传递过来的需求交给子容器的时候，他就把这个需求放进容器的管道(pipeline)里面去。而需求傻呼呼得在管道里面流动的时候，就会被管道里面的各个阀门拦截下来。比如管道里面放了两个阀门。第一个阀门叫做 “access_allow_vavle”，也就是说需求流过来的时候，它会看这个需求是哪个IP过来的，如果这个IP已经在黑名单里面了， sure, 杀！第二个阀门叫做“defaul_access_valve”它会做例行的检查，如果通过的话，OK，把需求传递给当前容器的子容器。就是通过这种方式，需求就在各个容器里面传递，流动，最后抵达目的地的了。 valve: 就是上面所说的阀门啦。 Tomcat里面大概就是这么些东西，我们可以简单地这么理解tomcat的框架，它是一种自上而下，容器里又包含子容器的这样一种结构。 2. Tomcat的启动流程 这篇文章是讲tomcat怎么启动的，既然我们大体上了解了TOMCAT的框架结构了，那么我们可以望文生意地就猜到tomcat的启动，会先启动父容器，然后逐个启动里面的子容器。启动每一个容器的时候，都会启动安插在他身上的组件。当所有的组件启动完毕，所有的容器启动完毕的时候， tomcat本身也就启动完毕了。 顺理成章地，我们同样可以猜到， tomcat的启动会分成两大部分，第一步是装配工作。第二步是启动工作。 装配工作就是为父容器装上子容器，为各个容器安插进组件的工作。这个地方我们会用到digester模式，至于digester模式什么，有什么用，怎么工作的. 请参考 http://software.ccidnet.com/pub/article/c322_a31671_p2.html>; 启动工作是在装配工作之后，一旦装配成功了，我们就只需要点燃最上面的一根导线，整个tomcat就会被激活起来。这就好比我们要开一辆已经装配好了的汽车的时候一样，我们只要把钥匙插进钥匙孔，一拧，汽车的引擎就会发动起来，空调就会开起来，安全装置就会生效，如此一来，汽车整个就发动起来了。（这个过程确实和TOMCAT的启动过程不谋而和，让我们不得不怀疑 TOMCAT的设计者是在GE做JAVA开发的）。 2.1 一些有意思的名称： Catalina Tomcat Bootstrap Engin Host Context 他们的意思很有意思： Catalina: 远程轰炸机 Tomcat: 熊猫轰炸机 -- 轰炸机的一种（这让我想起了让国人引以为豪的熊猫手机，是不是英文可以叫做tomcat??? ，又让我想起了另一则广告：波导-手机中的战斗机、波音-客机中的战斗机） Bootstap: 引导 Engin: 发动机 Host: 主机，领土 Context: 内容，目标，上下文 ... 在许多许多年后，现代人类已经灭绝。后现代生物发现了这些单词零落零落在一块。一个自以为聪明的家伙把这些东西翻译出来了： 在地勤人员的引导(bootstrap)下，一架轰炸架(catalina)腾空跃起，远看是熊猫轰炸机(tomcat)，近看还是熊猫轰炸机！凭借着优秀的发动机技术(engin)，这架熊猫轰炸机飞临了敌国的领土上空(host)，对准目标(context)投下了毁天灭地的核弹头，波~ 现代生物就这么隔屁了~ 综上所述，这又不得不让人联想到GE是不是也参与了军事设备的生产呢？ 反对美帝国主义！反对美霸权主义！和平万岁！自由万岁！ 2.2 历史就是那么惊人的相似！ tomcat的启动就是从org.apache.catalina.startup.Bootstrap这个类悍然启动的！ 在Bootstrap里做了两件事： 1. 指定了3种类型classloader: commonLoader: common/classes、common/lib、common/endorsed catalinaLoader: server/classes、server/lib、commonLoader sharedLoader： shared/classes、shared/lib、commonLoader 2. 引导Catalina的启动。 用Reflection技术调用org.apache.catalina.startup.Catalina的process方法，并传递参数过去。 2.3 Catalina.java Catalina完成了几个重要的任务： 1. 使用Digester技术装配tomcat各个容器与组件。 1.1 装配工作的主要内容是安装各个大件。比如server下有什么样的servcie。 Host会容纳多少个context。 Context都会使用到哪些组件等等。 1.2 同时呢，在装配工作这一步，还完成了mbeans的配置工作。在这里，我简单地但不十分精确地描述一下mbean是什么，干什么用的。 我们自己生成的对象，自己管理，天经地义！但是如果我们创建了对象了，想让别人来管，怎么办呢？我想至少得告诉别人我们都有什么，以及通过什么方法可以找到吧！ JMX技术给我们提供了一种手段。 JMX里面主要有3种东西。Mbean, agent, connector. Mbean：用来映射我们的对象。也许mbean就是我们创建的对象，也许不是，但有了它，就可以引用到我们的对象了。 Agent: 通过它，就可以找到mbean了。 Connector: 连接Agent的方式。可以是http的，也可以是rmi的，还可以直接通过socket。 发生在tomcat 装配过程中的事情: GlobalResourcesLifecycleListener 类的初始化会被触发： protected static Registry registry = MBeanUtils.createRegistry(); 会运行 MBeanUtils.createRegistry() 会依据/org/apache/catalina/mbeans/mbeans-descriptors.xml这个配置文件创建 mbeans. Ok, 外界就有了条途径访问tomcat中的各个组件了。（有点像后门儿） 2. 为top level 的server 做初始化工作。实际上就是做通常会配置给service的两条connector.(http, ajp) 3. 从server这个容器开始启动，点燃整个tomcat. 4. 为server做一个hook程序，检测当server shutdown的时候，关闭tomcat的各个容器用。 5. 监听8005端口，如果发送"SHUTDOWN"（默认培植下字符串）过来，关闭8005serverSocket。 2.4 启动各个容器 1. Server 触发Server容器启动前(before_start)，启动中(start)，启动后(after_start)3个事件，并运行相应的事件处理器。 启动Server的子容器：Servcie. 2. Service 启动Service的子容器：Engin 启动Connector 3. Engin 到了Engin这个层次，以及以下级别的容器， Tomcat就使用了比较一致的启动方式了。 首先，运行各个容器自己特有一些任务 随后，触发启动前事件 立即，设置标签，就表示该容器已经启动 接着，启动容器中的各个组件： loader, logger, manager等等 再接着，启动mapping组件。（注1） 紧跟着，启动子容器。 接下来，启动该容器的管道(pipline) 然后，触发启动中事件 最后，触发启动后事件。 Engin 大致会这么做， Host大致也会这么做， Context大致还是会这么做。那么很显然地，我们需要在这里使用到代码复用的技术。 tomcat在处理这个问题的时候，漂亮地使用了抽象类来处理。 ContainerBase. 最后使得这部分完成复杂功能的代码显得干净利落，干练爽快，实在是令人觉得叹为观止，细细品来，直觉如享佳珍，另人齿颊留香，留恋往返啊！ Engin的触发启动前事件里，会激活绑定在Engin上的唯一一个Listener：EnginConfig。 这个EnginConfig类基本上没有做什么事情，就是把EnginConfig的调试级别设置为和Engin相当。另外就是输出几行文本，表示Engin已经配置完毕，并没有做什么实质性的工作。 注1: mapping组件的用处是，当一个需求将要从父容器传递到子容器的时候，而父容器又有多个子容器的话，那么应该选择哪个子容器来处理需求呢？这个由mapping 组件来定夺。 4. Host 同Engin一样，也是调用ContainerBase里面的start()方法，不过之前做了些自个儿的任务,就是往Host这个容器的通道（pipline）里面，安装了一个叫做 “org.apache.catalina.valves.ErrorReportValve”的阀门。 这个阀门的用处是这样的：需求在被Engin传递给Host后，会继续传递给Context做具体的处理。这里需求其实就是作为参数传递的 Request, Response。所以在context把需求处理完后，通常会改动response。而这个 org.apache.catalina.valves.ErrorReportValve的作用就是检察response是否包含错误，如果有就做相应的处理。 5. Context 到了这里，就终于轮到了tomcat启动中真正的重头戏，启动Context了。 StandardContext.start() 这个启动Context容器的方法被StandardHost调用. 5.1 webappResources 该context所指向的具体目录 5.2 安装defaultContex, DefaultContext 就是默认Context。如果我们在一个Host下面安装了 DefaultContext，而且defaultContext里面又安装了一个数据库连接池资源的话。那么其他所有的在该Host下的 Context, 都可以直接使用这个数据库连接池，而不用格外做配置了。 5.3 指定Loader. 通常用默认的org.apache.catalina.loader.WebappLoader这个类。 Loader就是用来指定这个context会用到哪些类啊，哪些jar包啊这些什么的。 5.4 指定 Manager. 通常使用默认的org.apache.catalina.session. StandardManager 。 Manager是用来管理session的。 其实session的管理也很好实现。以一种简单的session管理为例。当需求传递过来的时候，在Request对象里面有一个 sessionId 属性。 OK，得到这个sessionId后，我们就可以把它作为map的key，而value我们可以放置一个 HashMap. HashMap里边儿，再放我们想放的东西。 5.5 postWorkDirectory (). Tomcat下面有一个work目录。我们把临时文件都扔在那儿去。这个步骤就是在那里创建一个目录。一般说来会在%CATALINA_HOME%/work /Standalone/localhost/ 这个地方生成一个目录。 5.6 Binding thread。到了这里，就应该发生 class Loader 互换了。之前是看得见tomcat下面所有的class和lib. 接下来需要看得见当前context下的 class。所以要设置contextClassLoader, 同时还要把旧的ClassLoader记录下来，因为以后还要用的。 5.7 启动 Loader. 指定这个Context具体要使用哪些classes，用到哪些jar文件。如果reloadable设置成了true, 就会启动一个线程来监视classes的变化，如果有变化就重新启动Context。 5.8 启动logger 5.9 触发安装在它身上的一个监听器。 lifecycle.fireLifecycleEvent(START_EVENT, null); 作为监听器之一，ContextConfig会被启动. ContextConfig就是用来配置web.xml的。比如这个Context有多少Servlet，又有多少Filter，就是在这里给Context装上去的。 5.9.1 defaultConfig. 每个context都得配置 tomcat/conf/web.xml 这个文件。 5.9.2 applicationConfig 配置自己的 WEB-INF/web.xml 文件 5.9.3 validateSecurityRoles 权限验证。通常我们在访问/admin 或者/manager的时候，需要用户要么是admin的要么是manager的，才能访问。而且我们还可以限制那些资源可以访问，而哪些不能。都是在这里实现的。 5.9.4 tldScan: 扫描一下，需要用到哪些标签(tag lab) 5.10 启动 manager 5.11 postWelcomeFiles() 我们通常会用到的3个启动文件的名称： index.html、index.htm、index.jsp 就被默认地绑在了这个context上 5.12 listenerStart 配置listener 5.13 filterStart 配置 filter 5.14 启动带有<load-on-startup>1</load-on-startup>的Servlet. 顺序是从小到大： 1,2,3… 最后是0 默认情况下，至少会启动如下3个的Servlet: org.apache.catalina.servlets.DefaultServlet 处理静态资源的Servlet. 什么图片啊， html啊， css啊， js啊都找他 org.apache.catalina.servlets.InvokerServlet 处理没有做Servlet Mapping的那些Servlet. org.apache.jasper.servlet.JspServlet 处理JSP文件的. 5.15 标识context已经启动完毕。 走了多少个步骤啊， Context总算是启动完毕喽。 OK! 走到了这里，每个容器以及组件都启动完毕。 Tomcat终于不辞辛劳地为人民服务了！ 3. 参考文献： http://jakarta.apache.org/tomcat/>; http://www.onjava.com/pub/a/onjava/2003/05/14/java_webserver.html>;</server>

Tomcat的架构总的来说是分层次的、可插拔的组件架构。分层次是指构成Tomcat的组件不是同一级别的，上层组件可以包含子组件，各个组件有其功能范围，当一个组件停止服务时，不会影响上层组件的服务。可插拔是指对于组件的添加和删除并不影响服务器的运行。那么为了达到可插拔的组件架构，分层次的组件架构必成为基础。

对于任何服务器，即使最简单的实现，从面向对象设计（OOD）的角度来说，我们都有必要将“服务器”这个概念抽象出来，为什么呢？因为只有有了这个概念，才能谈服务器的实例，服务器的功能等等其它概念，此之谓“皮之不存，毛将焉附”。赶巧（其实是我的想法恰好撞上人家的想法），Tomcat也将“服务器”抽象为java接口org.apache.catalina.Server，显然Server应该就是最最顶层的组件了。

有了Server这个抽象，很自然的，我们希望它能够提供对servlet和jsp支持的功能。但是我们发现这个概念太大了，我们还需再细化。所以别急，我们还有一些事情要解决。服务器要提供服务就必须能够启动，当然也应该能够停止吧，也就是说服务器应该是有生命的，在启动时初始化必要的资源，而在停止时将其其销毁掉。好吧，我们把这个也抽象出来，叫做生命周期接口，tomcat 实现为org.apache.catalina.Lifecycle.如上所述我们知道Lifecycle需要完成的工作了。

public void start() throws LifecycleException;

public void stop() throws LifecycleException;

接下来我们分析服务器如何来处理客户端的请求，一般的我们会在浏览器中输入如下格式的请求，http://192.168.8.221:8080/explorer/loginInit.do。对于服务器来说，要想处理这个请求，就必须监听指定的端口8080，当有TCP的请求包来时，建立Socket连接，分析并解析之，然后给客户端返回响应。在这个过程中，我们发现，其实包含了俩个功能点，即监听并接受请求和处理请求。那么我们能否将这俩个功能给抽象出来呢？Tomcat告诉我们，可以。是的，Tomcat将“监听并接收请求”抽象为org.apache.catalina.connector.Connector类，负责接受请求；将“处理请求”抽象为“容器” org.apache.catalina.Container，负责处理Connector传递过来的请求。

Ok,到此，我们分析构建的简单服务器模型出来了，Server由Connector组件和Container组件结合提供web服务。

图2

有了这个模型后，要实现一个简单的Server已经很简单了，但是在实现Container时，我们还是要做很多事情，如当来请求，我们怎么知道该请求对应得虚拟主机，以及请求的那个应用，应该交给那个servlet对象来处理？这样看来，Container还是太大了，需要细化。根据Servlet规范，我们知道，servlet属于某个应用，且有上下文环境，Container要根据应用上下文环境初始化servlet，然后根据servlet映射调用servlet的service方法。在这里“应用上下文环境”的概念很重要，Tomcat将其抽象为org.apache.catalina.Context，Context继承了Container接口。对于虚拟主机，Tomcat将其抽象为org.apache.catalina.Host，Host继承了Container接口。

好了，有了这些概念，我们再回顾一下请求的处理过程：浏览器发出请求，Connector接受请求，将请求交由Container处理，Container查找请求对应的Host并将请求传递给它，Host拿到请求后查找相应的应用上下文环境，准备servlet环境并调用service方法。

现在，我们的服务器模型变成了如图3所示了。

图3

但是在Tomcat的实现体系中还有一个Engine的接口，Engine也继承了Container接口，那么这个接口什么用呢？设计Engine的目的有俩个目的，一，当希望使用拦截器查看（过滤或预处理）每个请求时，Engine是个很好的拦截点。二，当希望多个虚拟Host共享一个Http的Connector时，Engine是个很好的门面。所以，Engine接口是作为顶级Container组件来设计的，其作用相当于一个Container的门面。有了Engine，请求的处理过程变为：浏览器发出请求，Connector接受请求，将请求交由Container（这里是Engine）处理，Container（Engine来担当）查找请求对应的Host并将请求传递给它，Host拿到请求后查找相应的应用上下文环境，准备servlet环境并调用service方法。再看看服务器的模型，如图4.

图4

到目前，我们碰到的组件类型有Connector和Container，其实，这也就是Tomcat的核心组件。如图4，一组Connector和一个Container有机的组合在一起构成Server，就可以提供服务了，对于Tomcat来说，主要是提供Servlet服务，那么也就是说Tomcat服务器也可以提供其它服务了？是的，Tomcat将“一组Connector和一个Container有机的组合”抽象为“服务”接口org.apache.catalina.Service，然而，这些服务实例彼此独立，仅仅共享JVM的基础设施，如系统类路径。

进一步的，我们得到了服务器的框架模型，如图5.

图5

由图5，我们知道，对于Tomcat服务器来说，除了Server代表它自己以外，其它组件都是功能组件，都有其职责范围。Service为最顶层的组件，可以添加Connector和Container组件。Engine是Container的最顶层组件，可以添加Host组件，但不能添加父组件。Host组件的父组件是Engine，Host下面包含有Context组件。

接下来看看标准的Tomcat体系结构，如图6.