Tomcat是Apache基金组织下的开源项目&＃xff0c;性质是一个Web服务器。下面这种情况很普遍&＃xff1a;在eclipse床架一个web项目并部署到Tomcat中&＃xff0c;启动tomcat&＃xff0c;在浏览器中输入一个类似http://localhost:8080/webproject/anyname.jsp的url&＃xff0c;然后就可以看到我们写好的jsp页面的内容了。一切都是那么自然和顺理成章&＃xff0c;然而这一切都是源于tomcat带给我们的&＃xff0c;那么在tomcat背后&＃xff0c;这一切又是怎么样发生的呢&＃xff1f;带着对tomcat工作原理的好奇心&＃xff0c;我决定研究一下tomcat的源码&＃xff0c;然而部署源码环境的过程却让我心灰意冷&＃xff0c;本着搞不定我还真不信的热情&＃xff0c;折腾了一个晚上&＃43;一个早上&＃xff0c;终于把源码源码环境搭建好了。

为了让文章显得更有条理性&＃xff0c;我将从以下几个方面说明Tomcat的工作流程&＃xff1a;

• 搭建Tomcat源码环境指导
• Tomcat的系统架构
• Tomcat中的核心组件说明
• Servlet工作原理
• 一个例子

Tomcat的系统架构

首先我们从一个宏观的角度来看一下Tomcat的系统的架构&＃xff1a;

从这张图中可以看到&＃xff0c;Tomcat的核心组件就两个Connector和Container&＃xff08;后面还有详细说明&＃xff09;&＃xff0c;一个Connector&＃43;一个Container构成一个Service&＃xff0c;Service就是对外提供服务的组件&＃xff0c;有了Service组件Tomcat就可以对外提供服务了&＃xff0c;但是光有服务还不行&＃xff0c;还得有环境让你提供服务才行&＃xff0c;所以最外层的Server就为Service提供了生存的土壤。那么这些个组件到底是干嘛用的呢&＃xff1f;Connector是一个连接器&＃xff0c;主要负责接收请求并把请求交给Container&＃xff0c;Container就是一个容器&＃xff0c;主要装的是具体处理请求的组件。Service主要是为了关联Container与Connector&＃xff0c;一个单独的Container或者一个单独的Connector都不能完整处理一个请求&＃xff0c;只有两个结合在一起才能完成一个请求的处理。Server这是负责管理Service集合&＃xff0c;从图中我们看到一个Tomcat可以提供多种服务&＃xff0c;那么这些Serice就是由Server来管理的&＃xff0c;具体的工作包括&＃xff1a;对外提供一个接口访问Service&＃xff0c;对内维护Service集合&＃xff0c;维护Service集合又包括管理Service的生命周期、寻找一个请求的Service、结束一个Service等。以上就是对Tomcat的核心组件的简要说明&＃xff0c;下面我们详细看看每一个组件的执行流程&＃xff1a;

Server

上面说Server是管理Service接口的&＃xff0c;Server是Tomcat的顶级容器&＃xff0c;是一个接口&＃xff0c;Server接口的标准实现类是StandardServer类&＃xff0c;在Server接口中有许多方法&＃xff0c;我们重点关注两个方法&＃xff1a;addService()和findService(String)。我们先来看看Server接口的全貌&＃xff1a;

接着看看addService()和findService(String)的实现代码&＃xff1a;

代码清单1-1:

/*** Add a new Service to the set of defined Services.** &＃64;param service The Service to be added*/
&＃64;Override
public void addService(Service service) {service.setServer(this);synchronized (services) {Service results[] &＃61; new Service[services.length &＃43; 1];System.arraycopy(services, 0, results, 0, services.length);results[services.length] &＃61; service;services &＃61; results;if (getState().isAvailable()) {try {service.start();} catch (LifecycleException e) {// Ignore}}// Report this property change to interested listenerssupport.firePropertyChange("service", null, service);}}

可以看到&＃xff0c;Server使用一个数组来管理Service的&＃xff0c;每添加一个Service就把原来的Service拷贝到一个新的数组中&＃xff0c;再把新的Service放入Service数组中。所以Server与Service是关联在一起的&＃xff0c;那么后面的getState().isAvailable()是干嘛的呢&＃xff1f;判断状态是否无效&＃xff0c;从而决定是否执行service方法。这里说到了状态&＃xff0c;就不得不说Tomcat管理各组件生命周期的Lifecycle接口了&＃xff1a;

Lifecycle接口

Tomcat中的组件都交给这个接口管理&＃xff0c;但是具体组件的生命周期是由包含组件的父容器来管理的&＃xff0c;Tomcat中顶级容器管理着Service的生命周期&＃xff0c;Service容器又是Connector和Container的父容器&＃xff0c;所以这两个组件的生命周期是由Service管理的&＃xff0c;Container也有子容器&＃xff0c;所以管理着这些子容器的生命周期。这样&＃xff0c;只要所有组件都实现了Lifecycle接口&＃xff0c;从顶层容器Server开始&＃xff0c;就可以控制所有容器的生命周期了。Lifecycle接口中定义了很多状态&＃xff0c;在api中详细说明了调用不同方法后的状态转变&＃xff0c;同时定义了不同的方法&＃xff0c;这些方法在执行后状态会发生相应的改变&＃xff0c;在Lifecycle接口中定义了如下方法&＃xff1a;

在StandServer中实现了startInernal()方法&＃xff0c;就是循环启动StandServer管理的Service的过程&＃xff0c;Tomcat的Service都实现了Lifecycle接口&＃xff0c;所以被管理的Service都将被通知到&＃xff0c;从而执行start()方法&＃xff0c;startIntenal()方法是这样的&＃xff1a;

代码清单1-2&＃xff1a;

/*** Start nested components ({&＃64;link Service}s) and implement the requirements* of {&＃64;link org.apache.catalina.util.LifecycleBase#startInternal()}.** &＃64;exception LifecycleException if this component detects a fatal error* that prevents this component from being used*/
&＃64;Override
protected void startInternal() throws LifecycleException {fireLifecycleEvent(CONFIGURE_START_EVENT, null);setState(LifecycleState.STARTING);globalNamingResources.start();// Start our defined Servicessynchronized (services) {for (int i &＃61; 0; i }

现在所有的Service就会收到通知继而执行start方法。如果一个Service不允许被使用将会抛出一个LifecycleException异常。

stopIntenal()会通知所有Service执行stop方法&＃xff0c;具体处理流程与startIntenal()方法类似。这个执行过程涉及一个非常重要的设计模式&＃xff0c;就是观察者模式。

现在我们已经能够知道了容器通过Lifecycle接口管理容器的生命周期&＃xff0c;那么在父容器的状态改变具体是怎么样通知给子容器的呢&＃xff1f;回到代码清单1-2&＃xff0c;我们注意到有一个fireLifecycleEvent()方法&＃xff0c;fireLifecycleEvent()的执行流程如下&＃xff1a;

1. 调用LifecycleBase的fireLifecycleEvent(LifecycleListener listener)方法&＃xff0c;LifecycleBase是一个抽象类&＃xff0c;实现了Lifecycle接口
2. 继续调用LifecycleSupport&＃xff08;是一个辅助完成对已经注册监听器的事件通知类&＃xff0c;不可被继承&＃xff0c;使用final)的fireLifecycleEvent(String type, Object data)方法
3. 完成事件通知

fireLifecycleEvent(String type, Object data)的方法如下&＃xff1a;

代码清单1-3&＃xff1a;

/*** Notify all lifecycle event listeners that a particular event has* occurred for this Container. The default implementation performs* this notification synchronously using the calling thread.** &＃64;param type Event type* &＃64;param data Event data*/
public void fireLifecycleEvent(String type, Object data) {LifecycleEvent event &＃61; new LifecycleEvent(lifecycle, type, data);LifecycleListener interested[] &＃61; listeners;for (int i &＃61; 0; i

所以&＃xff0c;具体事件的通知是由LifecycleListener接口的lifecycleEvent方法完成的&＃xff0c;各实现类可以根据不同的情况实现不同的事件监听逻辑

Service

Service是具体提供服务的接口&＃xff0c;一个Service包装了Connector和一个Container&＃xff0c;在Tomcat中这点是如何实现的呢&＃xff1f;Service是一个接口&＃xff0c;其标准实现类是StandardService&＃xff0c;下面是这两个类的鸟瞰图&＃xff1a;

这里&＃xff0c;我们只关心与Connector和Container最紧密的方法&＃xff1a;setContainer()和addConnector()方法&＃xff0c;先看一下setContainer()方法的源码&＃xff1a;

代码清单2-1&＃xff1a;

/*** Set the Container that handles requests for all* Connectors associated with this Service.** &＃64;param container The new Container*/
&＃64;Override
public void setContainer(Container container) {Container oldContainer &＃61; this.container;if ((oldContainer !&＃61; null) && (oldContainer instanceof Engine))((Engine) oldContainer).setService(null);this.container &＃61; container;if ((this.container !&＃61; null) && (this.container instanceof Engine))((Engine) this.container).setService(this);if (getState().isAvailable() && (this.container !&＃61; null)) {try {this.container.start();} catch (LifecycleException e) {// Ignore}}if (getState().isAvailable() && (oldContainer !&＃61; null)) {try {oldContainer.stop();} catch (LifecycleException e) {// Ignore}}// Report this property change to interested listenerssupport.firePropertyChange("container", oldContainer, this.container);}

从代码中可以看到这个方法主要的任务是设置一个Container容器来处理一个或者多个Connector传送过来的请求。首先判断当前的Service是否已经关联了Container容器&＃xff0c;如果已经关联了就去除这个关联关系。如果原来的Container容器已经启动了就终止其生命周期&＃xff0c;结束运行并设置新的关联关系&＃xff0c;这个新的Container容器开始新的生命周期。最后把这个过程通知给感兴趣的事件监听程序。

下面看看addConnector的方法&＃xff1a;

代码清单2-2&＃xff1a;

/*** Add a new Connector to the set of defined Connectors, and associate it* with this Service&＃39;s Container.** &＃64;param connector The Connector to be added*/
&＃64;Override
public void addConnector(Connector connector) {synchronized (connectors) {connector.setService(this);Connector results[] &＃61; new Connector[connectors.length &＃43; 1];System.arraycopy(connectors, 0, results, 0, connectors.length);results[connectors.length] &＃61; connector;connectors &＃61; results;if (getState().isAvailable()) {try {connector.start();} catch (LifecycleException e) {log.error(sm.getString("standardService.connector.startFailed",connector), e);}}// Report this property change to interested listenerssupport.firePropertyChange("connector", null, connector);}}

执行过程也比较清楚&＃xff1a;用一个同步代码块包住connectors数组&＃xff0c;首先设置connector与container和service的关联关系&＃xff0c;然后让connector开始新的生命周期&＃xff0c;最后通知感兴趣的事件监听程序。注意到Connector的管理和Server管理Service一样都使用了数组拷贝并把新的数组赋给当前的数组&＃xff0c;从而间接实现了动态数组。之所以使用数组我想可能是出于性能的考虑吧。