tomcat原理解析(二)：整体架构

标签：代码   而且   contex   tomat   iss   volatile   stopped   global   access   

一 整体结构

前面tomcat实现原理(一)里面描述了整个tomcat接受一个http请求的简单处理，这里面我们讲下整个tomcat的架构，以便对整体结构有宏观的了解。tomat里面由很多个容器结合在一起，主要有server,service,context,host,engine,wrapper,connector这7个容器来组装。当然了tomcat里面还有其它容器这里就不一一列举，因为我只看重点的。这7个容器存着父子关系，即可以通过当前容器找自己的父容器和自己的子容器。说到这我画了一个简单的结构图，让这种关系更加直观。如下：

根据图可以看出server是最外层的一个容器，它里面可以包含了Service容器，Service容器里面又包含了Connector和Engine，Engine容器里面又包含了Host，Host容器包含Context，Context容器包含Wrapper容器。就好比一个人有最外层的躯体，躯体里面有心脏，肺，胃，肾脏等等很多个个功能器件。

二 组件描述

       这里主要通过tomcat的源码来分析这7个容器是通过什么样的机制来组织在一起的，相互的包含的关系怎么处理。

      1.server组件

      server就像一个架子，很多其它子容器都装配在这个架子上。同时这个容器又暴露了一些入口对外提供服务。比如初始化服务，启动服务，停止服务等。源码中的server是一个接口，如下图:

查看Server接口类它还继承着Lifecycle接口，详情如下图：

Lifecycle接口控制着各个组件的生命周期，比如接口中的抽象方法init()初始化,start()启动,stop()停止,destory()销毁。 Server的标准实现类为StandardServer,细读StandardServer里面的接口addService,findServices的实现代码，可以看出这Service和 Server有着关联，Server可以有多个Service以数组的形式保存在其中。

1.将设置进来的Service 对象设置父组件为Server

2.重新构建了一个Service数组，然后将老的Service拷贝到新的数组中，同时追加新的Service组件

3.根据当前组件的生命状态，判断新加入的组件是否需要启动

    2.Service组件

        service接口它也继承Lifecycle接口。 前面说过了service组件的父组件是server组件，结构如下图：

它的标准实现是StandardService类，查看接口抽象方法addConnector的具体实现可以看出通过它可以给service容器添加connector容器，这里的connector就主要负责接收浏览器客户端发过来的http请求，仔细看里面的源码可以发现它接到请求时生成了一个socket对象，并将这个socket对象放入了一个线程中，同时线程会存入一个线程池来处理这次响应，并根据请求的详情信息来定位响应资源，响应的资源通过Engine容器给出。它就像浏览器和 Engine容器的桥梁，具体如何响应请求的会通过后面的章节来细说。先看是怎么将connector容器绑定到service中。 如下面代码：

1.给当前入去的Connector主键设置父容器service.
2.根据原有Connector集合的大小加上新加入的容器，从新构建了一个Connector数组。
3.将旧的数据拷贝到新的容器数组中，再添加新加的容器
4.然后根据当前容器的生命状态判断是否要启动新加入的容器
这里存放connector组件为什么用数组而不用List来存放不是太明白。感觉跟server管理service组件操作一样。看完所有的抽象接口是不是感觉有些奇怪，按照前面给的整体架构图怎么没看到给Service添加Engine组件的入口。查看Engine的标准实现类StandardEngine其实是实现了Container接口的，所以这里应该是通过setContainer接口设置进去的，其源码如下：

1.将原有的Container（Engine）对象 的父对象置为空
2.同时将旧的Container对象覆盖掉，变成新注入的Container对象
3.同时根据当前组件的生命周期来判断是否将新注入的容器启动

3.Engine组件
Engine接口类为该组件的抽象接口，它继承Container接口跟前面描述的两个组件似乎有些不一样，查看源码后发现Container接口也继承了Lifecycle接口。Engine结构如下图：

它的标准实现是StandardEngine类，查setService接口的具体实现，service组件设置进Engine组件中，让两者之间关联。怎么没有看到添加子组件的入口呢？我们查看StandardEngine实现类中，它继承了ContainerBase类，而这个类实现了Container接口。在StandardEngine类中看到了addChild方法的实现 如下代码：

通过这个方法来为Engine添加子组件

1.判断当前传入的组件是否是Host类型的，否则抛异常

2.调用服务类中的addChild方法，同时将child变量传递到父类中处理，我们继续看父类ContainerBase中的代码。

最终它调用了addChildInternal方法来处理。

child.setParent(this);
children.put(child.getName(), child);
1.这里传入host子组件的同时，给host子组件设置了父组件
2.将子组件保存在children变量中，这里的children其实就是个HashMap对象。
看到这里也就明白了，所有继承ContainerBase类的组件在添加子组件都是依赖父类中的MAP对象来保存的.

4.Host组件
Host类为该组件的接口定义，也继承了Container类，它的标准实现是StandardHost类，继承ContainerBase类。host结构如下图所示：

因为该标准实现类StandardHost也继承了ContainerBase类，所以该组件的子组件添加也依赖父类中的Map来保存，跟Engine组件管理子组件是一样的。每一个HOST相当于一个主机，并负责展开和运行多个部署进去的war包。每个主机下面有多个部署的应用，一个应用就对应着一个Context。通过context将多个应用分隔开。所以host的子组件就是context，在通过ContainerBase类的addChild方法来添加context子容器的同时也给它设置了父容器host对象。

5.Context容器

context接口继承了Container，StandardContext类为是Context的标准实现，它也继承了ContainerBase类，所以给改容器注入子容器也是通过containerBase类中的addaddChild来处理的。Context容器代表着一个servlet容器，它为servlet运行提供环境。context管理着里面servlet实例，servlet实例在context中以Wrapper形式存在。那么一个http请求是怎么找到对应的servlet实例的呢？后面章节再来详细描述

6.Wrapper容器

Wrapper接口类也继承Container类，它的标准实现类是StandardWrapper，也继承了ContainerBase类。因为Wrapper容器是最底层的容器了，所以它不存在子容器。Wrapper 代表一个Servlet，它负责管理一个 Servlet，包括的 Servlet的装载、初始化、执行以及资源回收。

三 组件相关类结构

      

四 总结

tomcat原理解析(二)：整体架构

标签：代码   而且   contex   tomat   iss   volatile   stopped   global   access   

原文地址：http://www.cnblogs.com/csguo/p/7499435.html