Servlet容器的功能
先不去关技术细节，对一个servlet容器，它首先要做以下事情：
1:实现Servlet api规范。这是最基础的一个实现，servlet api大部分都是接口规范。如request、response、session、cookie。为了我们应用端能正常使用，容器必须有一套完整实现。
2：启动Socket监听端口，等待http请求。
3：获取http请求，分发请求给不同的协议处理器，如http和https在处理上是不一样的。
4：封装请求，构造HttpServletRequest。把socket获取的用户请求字节流转换成java对象httprequest。构造httpResponse。
5：调用(若未创建，则先加载)servlet，调用init初始化，执行servlet.service()方法。
6：为httpResponse添加header等头部信息。
7：socket回写流，返回满足http协议格式的数据给浏览器。
8：实现JSP语法分析器，JSP标记解释器。JSP servlet实现和渲染引擎。
9：JNDI、JMX等服务实现。容器一般额外提供命名空间服务管理。
10：线程池管理，创建线程池，并为每个请求分配线程。
Eclipse等IDE为你提供了什么？
假设你需要纯手工搭建一个web工程，而没有eclipse这样的IDE，你需要做些什么？
首先了解一下下面几个概念，讲得不太准确：
1、JVM
JVM是class以及jar(实际上就是很多个class压缩在一起)的运行环境，特征就是java和javaw命令，通过这两个命令，你可以执行class和jar文件。你可以通过-classpath参数指定你需要加载的jar文件
2、JDK
JDK就是JAVA的命令行开发环境，内置了JVM，特征就是javac命令，这个命令允许你将.java源文件批量或者单个编译成.class文件，从而可以通过JVM的java命令执行。在编译时你可以通过-classpath参数指定你的源代码依赖的jar文件。
3、Tomcat等JEE中间件
JEE中间件主要是为了让JAVA程序能够提供http服务、向客户展现html及相关资源而准备的一个运行环境，通常已经包含了JDK（或者像tomcat一样需要配置JDK所在路径）.这个运行环境的特征是能够让你部署一个war包，运行环境能够自动加载WEB-INF/classes下的.class文件和WEB-INF/lib下jar文件。当用户通过浏览器访问中间件中你的war包所部署的路径时，中间件能够按照J2EE标准调用你的war包中的class和jsp页面，并将执行结果返回给浏览器。 在这种情况下你只需要将你的.java文件编译好放到WEB-INF/classes目录下。
纯文本开发JAVA WEB
然后说说纯文本JAVA WEB开发，有这么几种类型：
1、纯文本只有JSP
如果项目中只有jsp页面，就很稀松平常了，你只需要在tomcat的webapps下新建一个目录，然后在里面新建.jsp文件，就可以通过类似于http://localhost:8080/app/a.jsp的方式执行这个jsp文件了。早期的JAVA WEB项目都差不多是这么干的，那时候IDE的用处确实不大。别的技术像ASP和PHP之类十几年了一直是用这种纯文本的方式来编写代码，效率和有IDE没太大差别。
2、除了JSP还有辅助JAVA类
如果除了JSP以外，你还需要一些JAVA类来辅助JSP页面，这时候你必须手工新建.java文件，然后用通过文本编辑器（记事本/vi/UE等）打开他，往里面手工写代码。你将代码写完后，还需要将这个.java文件编译成.class，然后才能放到WEB-INF/classes下执行，
有两种方式完成编译动作：
方式一：JDK+构建工具（ANT或者MAVEN），通过配置ANT调用JDK中的javac命令将你的JAVA代码编译成class并放置到你的WEB-INF/classes目录下
方式二：ANT实际上也是将你的配置转换成javac命令中的各种参数，所以你也可以直接在命令行输出javac，然后javac就会提示你需要提供什么样的参数以及各种参数有什么用途，你可以根据提示自己调用javac编译.java文件成.class文件。
两种方式效率都有点低，所以你还需要有一个.bat（或者.sh）批处理文件来帮助你每隔几十秒就自动编译一下指定目录下的.java文件。
你可能需要写的辅助JAVA类有：
一、全局性的ServletFilter（例如用于用户权限检查）
二、复杂输出的Servlet(jsp不适合用来动态向浏览器提供图片等资源，这时候写Servlet)
三、在JSP中使用的Tag类，以减少JSP中大量的<%%>代码。
这种类不会很多，一般项目能有二三十个就差不多了，所以最初写辅助类的痛苦时期过去以后，开发效率就和使用IDE没什么区别了
3、除了JSP还有大量JAVA类
你的系统比较庞大了，需要一些框架性的东西来进行总体约束，然后在按照框架的要求来编写大量的JAVA类，通过这些JAVA类来完成浏览器端的请求。
这时候你的系统状态已经比较类型与SSH这种形态了，每个页面都会有对应的Action/Controller，以及FormBean/Model，或者还有专门的Service/BL类和DAO类。
这样你的系统中就会有大量的.java文件需要编译成.class，而且要引用的jar数量也显著增加，这时候你作为一个没有IDE的人，痛苦就要来了：
大量的时间花在等待编译上了，无论是使用构建工具的增量编译功能还是自己写一个更强大的批处理文件来扫描改动过的类，每次编译都需要一点时间，并且都不是非常可靠。特别是“减量编译”通常都支持不好，可能会有潜在的错误。
如果每次都使用全部重新编译以得到可靠的编译结果，那么最好的做法是让你每个JAVA类都一次写完一次编译成功，如果多出几个错误或者多修改几次，你会发现编译用的时间就显著大于你写代码的时间。
这种情况下纯文本和IDE的开发效率会有显著的区别。
如果我必须在这种痛苦的纯文本条件下工作，我会先写一个JAVA类，让这个JAVA类单独开一个进程运行，这个进程会自动扫描相应目录下的java文件增/改/删,
然后调用sun.tools.javac.Main类来进行编译，如果只是新增和修改则只单独编译几个类，如果有删除则全部重新编译。
那么Eclipse做了些什么？
1、Eclipse提供了WEB项目工程向导，帮助你快速创建项目
2、Eclipse将你的WEB-INF/lib下的jar文件管理起来，并对其中的class类进行了索引，以便于你快速查看相关类的位置、继承关系、引用关系。
3、Eclipse提供一个完善的增量编译器，所写即所得。Eclipse当年能够胜出的一个重要原因就在他的编译器，Eclipse的JDT实现了自己的编译器（因此Eclipse甚至都不需要JDK，只要有JVM就可以了）,能够快速、增量地将你对代码的修改反映到class文件上。这是当时的JBuilder望尘莫及的，当时每次改完类都得重新编译一下，那个痛苦呀，当时我在公司引进Eclipse的时候，两个月之内大家就全部抛弃JBuilder X了（当时花了钱买了正版）。
4、提供了完善的调试功能，基于IDE的调试效率会远高于命令行调试。
5、提供了语法加亮、语法提示、中间件管理等辅助工具。
说到这里想必您对手撸一个web框架感到有心无力，不要紧，我们现在就来看一下tomcat的实现机制与架构模式，为我们带来了哪些优势。
Tomcat系统结构与设计模式
Tomcat总体结构
从上图中可以看出，Tomcat的心脏是两个组件，Connector和Container。Connector的组件是可以被替换的，这样可以提供给服务器设计者更多的选择，因为这个组件是如此重要，不仅服务器的设计的本身，而且不同的场景也十分相关，所以一个Container可以选择对应多个Connector。多个Connector和一个Container就形成了一个Service，有了Service就可以对外提供服务了，但是Service还要一个生存环境，必须有人控制它的生命周期，所以这个时候Tomcat的作用就体现出来了。
Service
说白了，service其实就是在Connector和Container外面多包了一层，把它们组装在一起，向外面提供服务，一个service可以设置多个Connector，但是只能有一个Container容器。Connector主要负责对外交流，可以比作为Boy, Container主要处理Connector接收的请求，主要处理内部事务，可以比作为Girl。那么这个Service就是将它们连接在一起。这个Service接口的方法列表如下：
从 Service 接口中定义的方法中可以看出，它主要是为了关联 Connector 和 Container，同时会初始化它下面的其它组件，注意接口中它并没有规定一定要控制它下面的组件的生命周期。所有组件的生命周期在一个 Lifecycle 的接口中控制，这里用到了一个重要的设计模式，关于这个接口将在后面介绍。
Tomcat 中 Service 接口的标准实现类是 StandardService 它不仅实现了 Service 接口同时还实现了 Lifecycle 接口，这样它就可以控制它下面的组件的生命周期了。StandardService 类结构图如下：
从上图中可以看出除了 Service 接口的方法的实现以及控制组件生命周期的 Lifecycle 接口的实现，还有几个方法是用于在事件监听的方法的实现，不仅是这个 Service 组件，Tomcat 中其它组件也同样有这几个方法，这也是一个典型的设计模式，将在后面介绍。
下面看一下StandardService中主要的几个方法实现的代码，下面是setContainer和addConnector方法的源码。
StandardService.SetContainer
public void setContainer(Container container) {
Container oldContainer = this.container;
if ((oldContainer != null) && (oldContainer instanceof Engine))
((Engine) oldContainer).setService(null);
this.container = container;
if ((this.container != null) && (this.container instanceof Engine))
((Engine) this.container).setService(this);
if (started && (this.container != null) && (this.container instanceof Lifecycle)) {
try {
((Lifecycle) this.container).start();
} catch (LifecycleException e) {
;
}
}
synchronized (connectors) {
for (int i = 0; i < connectors.length; i++)
connectors[i].setContainer(this.container);
}
if (started && (oldContainer != null) && (oldContainer instanceof Lifecycle)) {
try {
((Lifecycle) oldContainer).stop();
} catch (LifecycleException e) {
;
}
}
support.firePropertyChange("container", oldContainer, this.container);
}这段代码很简单，其实就是先判断当前的这个 Service 有没有已经关联了 Container，如果已经关联了，那么去掉这个关联关系—— oldContainer.setService(null)。如果这个 oldContainer 已经被启动了，结束它的生命周期。然后再替换新的关联、再初始化并开始这个新的 Container 的生命周期。最后将这个过程通知感兴趣的事件监听程序。这里值得注意的地方就是，修改 Container 时要将新的 Container 关联到每个 Connector，还好 Container 和 Connector 没有双向关联，不然这个关联关系将会很难维护。
StandardService.addConnector
public void addConnector(Connector connector) {
synchronized (connectors) {
connector.setContainer(this.container);
connector.setService(this);
Connector results[] = new Connector[connectors.length + 1];
System.arraycopy(connectors, 0, results, 0, connectors.length);
results[connectors.length] = connector;
connectors = results;
if (initialized) {
try {
connector.initialize();
} catch (LifecycleException e) {
e.printStackTrace(System.err);
}
}
if (started && (connector instanceof Lifecycle)) {
try {
((Lifecycle) connector).start();
} catch (LifecycleException e) {
;
}
}
support.firePropertyChange("connector", null, connector);
}
}上面是 addConnector 方法，这个方法也很简单，首先是设置关联关系，然后是初始化工作，开始新的生命周期。这里值得一提的是，注意 Connector 用的是数组而不是 List 集合，这个从性能角度考虑可以理解，有趣的是这里用了数组但是并没有向我们平常那样，一开始就分配一个固定大小的数组，它这里的实现机制是：重新创建一个当前大小的数组对象，然后将原来的数组对象 copy 到新的数组中，这种方式实现了类似的动态数组的功能，这种实现方式，值得我们以后拿来借鉴。
其实这么想了一下，server完成的任务很简单，就是要能够提供一个接口让其它程序能够访问到这个Service集合，同时要维护它包含的所有Service的生命周期，包括如何初始化，如何结束服务，如何找到别人要访问的Service等等。
Server的类结构图
它的标准实现类 StandardServer 实现了上面这些方法，同时也实现了 Lifecycle、MbeanRegistration 两个接口的所有方法，下面主要看一下 StandardServer 重要的一个方法 addService 的实现
StandardServer.addService
public void addService(Service service) {
service.setServer(this);
synchronized (services) {
Service results[] = new Service[services.length + 1];
System.arraycopy(services, 0, results, 0, services.length);
results[services.length] = service;
services = results;
if (initialized) {
try {
service.initialize();
} catch (LifecycleException e) {
e.printStackTrace(System.err);
}
}
if (started && (service instanceof Lifecycle)) {
try {
((Lifecycle) service).start();
} catch (LifecycleException e) {
;
}
}
support.firePropertyChange("service", null, service);
}
}从上面第一句就知道了 Service 和 Server 是相互关联的，Server 也是和 Service 管理 Connector 一样管理它，也是将 Service 放在一个数组中，后面部分的代码也是管理这个新加进来的 Service 的生命周期。
Lifecycle类结构图
除了控制生命周期的 Start 和 Stop 方法外还有一个监听机制，在生命周期开始和结束的时候做一些额外的操作。这个机制在其它的框架中也被使用，如在 Spring 中。关于这个设计模式会在后面介绍。
Lifecycle 接口的方法的实现都在其它组件中，就像前面中说的，组件的生命周期由包含它的父组件控制，所以它的 Start 方法自然就是调用它下面的组件的 Start 方法，Stop 方法也是一样。如在 Server 中 Start 方法就会调用 Service 组件的 Start 方法，Server 的 Start 方法代码如下：
StandardServer.Start
public void start() throws LifecycleException {
if (started) {
log.debug(sm.getString("standardServer.start.started"));
return;
}
lifecycle.fireLifecycleEvent(BEFORE_START_EVENT, null);
lifecycle.fireLifecycleEvent(START_EVENT, null);
started = true;
synchronized (services) {
for (int i = 0; i < services.length; i++) {
if (services[i] instanceof Lifecycle)
((Lifecycle) services[i]).start();
}
}
lifecycle.fireLifecycleEvent(AFTER_START_EVENT, null);
}StandardServer.Stop
public void stop() throws LifecycleException {
if (!started)
return;
lifecycle.fireLifecycleEvent(BEFORE_STOP_EVENT, null);
lifecycle.fireLifecycleEvent(STOP_EVENT, null);
started = false;
for (int i = 0; i < services.length; i++) {
if (services[i] instanceof Lifecycle)
((Lifecycle) services[i]).stop();
}
lifecycle.fireLifecycleEvent(AFTER_STOP_EVENT, null);
}Connector组件
Connector 组件是 Tomcat 中两个核心组件之一，它的主要任务是负责接收浏览器的发过来的 tcp 连接请求，创建一个 Request 和 Response 对象分别用于和请求端交换数据，然后会产生一个线程来处理这个请求并把产生的 Request 和 Response 对象传给处理这个请求的线程，处理这个请求的线程就是 Container 组件要做的事了。
由于这个过程比较复杂，大体的流程可以用下面的顺序图来解释：
Connector 组件处理流程图
Connector主要类图
HttpConnector.Start
public void start() throws LifecycleException {
if (started)
throw new LifecycleException
(sm.getString("httpConnector.alreadyStarted"));
threadName = "HttpConnector[" + port + "]";
lifecycle.fireLifecycleEvent(START_EVENT, null);
started = true;
threadStart();
while (curProcessors < minProcessors) {
if ((maxProcessors > 0) && (curProcessors >= maxProcessors))
break;
HttpProcessor processor = newProcessor();
recycle(processor);
}
}threadStart() 执行就会进入等待请求的状态，直到一个新的请求到来才会激活它继续执行，这个激活是在 HttpProcessor 的 assign 方法中，这个方法是代码如下
HttpProcessor.assign
synchronized void assign(Socket socket) {
while (available) {
try {
wait();
} catch (InterruptedException e) {
}
}
this.socket = socket;
available = true;
notifyAll();
if ((debug >= 1) && (socket != null))
log(" An incoming request is being assigned");
}创建 HttpProcessor 对象是会把 available 设为 false，所以当请求到来时不会进入 while 循环，将请求的 socket 赋给当期处理的 socket，并将 available 设为 true，当 available 设为 true 是时HttpProcessor 的 run 方法将被激活，接下去将会处理这次请求.
HttpProcessor.Run
public void run() {
while (!stopped) {
Socket socket = await();
if (socket == null)
continue;
try {
process(socket);
} catch (Throwable t) {
log("process.invoke", t);
}
connector.recycle(this);
}
synchronized (threadSync) {
threadSync.notifyAll();
}
}解析 socket 的过程在 process 方法中，process 方法的代码片段如下：
HttpPcocessor.process
private void process(Socket socket) {
boolean ok = true;
boolean finishResponse = true;
SocketInputStream input = null;
OutputStream output = null;
try {
input = new SocketInputStream(socket.getInputStream(),connector.getBufferSize());
} catch (Exception e) {
log("process.create", e);
ok = false;
}
keepAlive = true;
while (!stopped && ok && keepAlive) {
finishResponse = true;
try {
request.setStream(input);
request.setResponse(response);
output = socket.getOutputStream();
response.setStream(output);
response.setRequest(request);
((HttpServletResponse) response.getResponse())
.setHeader("Server", SERVER_INFO);
} catch (Exception e) {
log("process.create", e);
ok = false;
}
try {
if (ok) {
parseConnection(socket);
parseRequest(input, output);
if (!request.getRequest().getProtocol().startsWith("HTTP/0"))
parseHeaders(input);
if (http11) {
ackRequest(output);
if (connector.isChunkingAllowed())
response.setAllowChunking(true);
}
}
。。。。。。
try {
((HttpServletResponse) response).setHeader
("Date", FastHttpDateFormat.getCurrentDate());
if (ok) {
connector.getContainer().invoke(request, response);
}
。。。。。。
}
try {
shutdownInput(input);
socket.close();
} catch (IOException e) {
;
} catch (Throwable e) {
log("process.invoke", e);
}
socket = null;
}Servlet容器Container
Container 是容器的父接口，所有子容器都必须实现这个接口，Container 容器的设计用的是典型的责任链的设计模式，它有四个子容器组件构成，分别是：Engine、Host、Context、Wrapper，这四个组件不是平行的，而是父子关系，Engine 包含 Host,Host 包含 Context，Context 包含 Wrapper。也就是下面这个顺序：
Engine——Host——Context——Wrapper
通常一个 Servlet class 对应一个 Wrapper，如果有多个 Servlet 就可以定义多个 Wrapper，如果有多个 Wrapper 就要定义一个更高的 Container 了。
容器的总体设计
Context 还可以定义在父容器 Host 中，Host 不是必须的，但是要运行 war 程序，就必须要 Host，因为 war 中必有 web.xml 文件，这个文件的解析就需要 Host 了，如果要有多个 Host 就要定义一个 top 容器 Engine 了。而 Engine 没有父容器了，一个 Engine 代表一个完整的 Servlet 引擎。
那么这些容器是如何协同工作的呢？先看一下它们之间的关系图：
四大子容器的继承关系图
当 Connector 接受到一个连接请求时，将请求交给 Container，Container 是如何处理这个请求的？这四个组件是怎么分工的，怎么把请求传给特定的子容器的呢？又是如何将最终的请求交给 Servlet 处理。下面是这个过程的时序图：
Container-Engine&Host处理请求时序图：
这里看到了 Valve 是不是很熟悉，没错 Valve 的设计在其他框架中也有用的，同样 Pipeline 的原理也基本是相似的，它是一个管道，Engine 和 Host 都会执行这个 Pipeline，您可以在这个管道上增加任意的 Valve，Tomcat 会挨个执行这些 Valve，而且四个组件都会有自己的一套 Valve 集合。您怎么才能定义自己的 Valve 呢？在 server.xml 文件中可以添加，如给 Engine 和 Host 增加一个 Valve 如下：
<Engine defaultHost="localhost" name="Catalina">
<Valve className="org.apache.catalina.valves.RequestDumperValve"/>
………
<Host appBase="webapps" autoDeploy="true" name="localhost" unpackWARs="true"
xmlNamespaceAware="false" xmlValidation="false">
<Valve className="org.apache.catalina.valves.FastCommonAccessLogValve"
directory="logs" prefix="localhost_access_log." suffix=".txt"
pattern="common" resolveHosts="false"/>
…………
</Host>
</Engine>StandardEngineValve 和 StandardHostValve 是 Engine 和 Host 的默认的 Valve，它们是最后一个 Valve ，负责将请求传给它们的子容器，以继续往下执行。
前面是 Engine 和 Host 容器的请求过程，下面看 Context 和 Wrapper 容器时如何处理请求的。下面是处理请求的时序图
Container——Context和Wrapper处理时序图
从 Tomcat5 开始，子容器的路由放在了 request 中，request 中保存了当前请求正在处理的 Host、Context 和 wrapper。
Engine容器
比较简单，只定义了一些基本的关联关系，它的标准实现是StandardEngine，这个类注意一点就是 Engine 没有父容器了，如果调用 setParent 方法时将会报错。添加子容器也只能是 Host 类型的，代码如下：
public void addChild(Container child) {
if (!(child instanceof Host))
throw new IllegalArgumentException
(sm.getString("standardEngine.notHost"));
super.addChild(child);
}
public void setParent(Container container) {
throw new IllegalArgumentException
(sm.getString("standardEngine.notParent"));
}它的初始化方法也就是初始化和它相关联的组件，以及一些事件的监听。它相当于公司董事长，负责划分定义重要的事情与认识关系。
Host 容器
Host 是 Engine 的子容器，一个 Host 在 Engine 中代表一个虚拟主机，这个虚拟主机的作用就是运行多个应用，它负责安装和展开这些应用，并且标识这个应用以便能够区分它们。它的子容器通常是 Context，它除了关联子容器外，还有一个功能就是保存一个主机应该有的信息。换句话说，它的职位相当于总经理，调度各种资源，负责处理多个应用，虽然忙，但是还处于指挥管理级别。
下面是和 Host 相关的类关联图：
Host类图
从上图中可以看出除了所有容器都继承的 ContainerBase 外，StandardHost 还实现了 Deployer 接口，上图清楚的列出了这个接口的主要方法，这些方法都是安装、展开、启动和结束每个 web application。
Deployer 接口的实现是 StandardHostDeployer，这个类实现了的最要的几个方法，Host 可以调用这些方法完成应用的部署等。
Context 容器
Context 代表 Servlet 的 Context，它具备了 Servlet 运行的基本环境，理论上只要有 Context 就能运行 Servlet 了。简单的 Tomcat 可以没有 Engine 和 Host。
Context 最重要的功能就是管理它里面的 Servlet 实例，Servlet 实例在 Context 中是以 Wrapper 出现的，还有一点就是 Context 如何才能找到正确的 Servlet 来执行它呢？ Tomcat5 以前是通过一个 Mapper 类来管理的，Tomcat5 以后这个功能被移到了 request 中，在前面的时序图中就可以发现获取子容器都是通过 request 来分配的。
Context的角色就相当于某个部门的头头，手下管理着N个Servlet，具备了一个团队的基本构成要素，可以接小项目了。
Context 准备 Servlet 的运行环境是在 Start 方法开始的，这个方法的代码片段如下：
StandardContext.start
public synchronized void start() throws LifecycleException {
………
if( !initialized ) {
try {
init();
} catch( Exception ex ) {
throw new LifecycleException("Error initializaing ", ex);
}
}
………
lifecycle.fireLifecycleEvent(BEFORE_START_EVENT, null);
setAvailable(false);
setConfigured(false);
boolean ok = true;
File configBase = getConfigBase();
if (configBase != null) {
if (getConfigFile() == null) {
File file = new File(configBase, getDefaultConfigFile());
setConfigFile(file.getPath());
try {
File appBaseFile = new File(getAppBase());
if (!appBaseFile.isAbsolute()) {
appBaseFile = new File(engineBase(), getAppBase());
}
String appBase = appBaseFile.getCanonicalPath();
String basePath =
(new File(getBasePath())).getCanonicalPath();
if (!basePath.startsWith(appBase)) {
Server server = ServerFactory.getServer();
((StandardServer) server).storeContext(this);
}
} catch (Exception e) {
log.warn("Error storing config file", e);
}
} else {
try {
String canConfigFile = (new File(getConfigFile())).getCanonicalPath();
if (!canConfigFile.startsWith (configBase.getCanonicalPath())) {
File file = new File(configBase, getDefaultConfigFile());
if (copy(new File(canConfigFile), file)) {
setConfigFile(file.getPath());
}
}
} catch (Exception e) {
log.warn("Error setting config file", e);
}
}
}
………
Container children[] = findChildren();
for (int i = 0; i < children.length; i++) {
if (children[i] instanceof Lifecycle)
((Lifecycle) children[i]).start();
}
if (pipeline instanceof Lifecycle)
((Lifecycle) pipeline).start();
………
}它主要是设置各种资源属性和管理组件，还有非常重要的就是启动子容器和 Pipeline。
我们知道 Context 的配置文件中有个 reloadable 属性，如下面配置:
<Context
path="/library"
docBase="D:\projects\library\deploy\target\library.war"
reloadable="true"
/>当这个 reloadable 设为 true 时，war 被修改后 Tomcat 会自动的重新加载这个应用。如何做到这点的呢 ? 这个功能是在 StandardContext 的 backgroundProcess 方法中实现的，这个方法的代码如下
public void backgroundProcess() {
if (!started) return;
count = (count + 1) % managerChecksFrequency;
if ((getManager() != null) && (count == 0)) {
try {
getManager().backgroundProcess();
} catch ( Exception x ) {
log.warn("Unable to perform background process on manager",x);
}
}
if (getLoader() != null) {
if (reloadable && (getLoader().modified())) {
try {
Thread.currentThread().setContextClassLoader
(StandardContext.class.getClassLoader());
reload();
} finally {
if (getLoader() != null) {
Thread.currentThread().setContextClassLoader
(getLoader().getClassLoader());
}
}
}
if (getLoader() instanceof WebappLoader) {
((WebappLoader) getLoader()).closeJARs(false);
}
}
}它会调用 reload 方法，而 reload 方法会先调用 stop 方法然后再调用 Start 方法，完成 Context 的一次重新加载。可以看出执行 reload 方法的条件是 reloadable 为 true 和应用被修改，那么这个 backgroundProcess 方法是怎么被调用的呢？
这个方法是在 ContainerBase 类中定义的内部类 ContainerBackgroundProcessor 被周期调用的，这个类是运行在一个后台线程中，它会周期的执行 run 方法，它的 run 方法会周期调用所有容器的 backgroundProcess 方法，因为所有容器都会继承 ContainerBase 类，所以所有容器都能够在 backgroundProcess 方法中定义周期执行的事件。
Wrapper 容器
Wrapper 代表一个 Servlet，它负责管理一个 Servlet，包括的 Servlet 的装载、初始化、执行以及资源回收。Wrapper 是最底层的容器，它没有子容器了，所以调用它的 addChild 将会报错。
也就是说，它相当于最底层的员工，所有的容器锁体现出的对servlet的各种基本操作都是由它实现的。
Wrapper 的实现类是 StandardWrapper，StandardWrapper 还实现了拥有一个 Servlet 初始化信息的 ServletConfig，由此看出 StandardWrapper 将直接和 Servlet 的各种信息打交道。
下面看一下非常重要的一个方法 loadServlet，代码片段如下：
public synchronized Servlet loadServlet() throws ServletException {
………
Servlet servlet;
try {
………
ClassLoader classLoader = loader.getClassLoader();
………
Class classClass = null;
………
servlet = (Servlet) classClass.newInstance();
if ((servlet instanceof ContainerServlet) &&
(isContainerProvidedServlet(actualClass) ||
((Context)getParent()).getPrivileged() )) {
((ContainerServlet) servlet).setWrapper(this);
}
classLoadTime=(int) (System.currentTimeMillis() -t1);
try {
instanceSupport.fireInstanceEvent(InstanceEvent.BEFORE_INIT_EVENT,servlet);
if( System.getSecurityManager() != null) {
Class[] classType = new Class[]{ServletConfig.class};
Object[] args = new Object[]{((ServletConfig)facade)};
SecurityUtil.doAsPrivilege("init",servlet,classType,args);
} else {
servlet.init(facade);
}
if ((loadOnStartup >= 0) && (jspFile != null)) {
………
if( System.getSecurityManager() != null) {
Class[] classType = new Class[]{ServletRequest.class,
ServletResponse.class};
Object[] args = new Object[]{req, res};
SecurityUtil.doAsPrivilege("service",servlet,classType,args);
} else {
servlet.service(req, res);
}
}
instanceSupport.fireInstanceEvent(InstanceEvent.AFTER_INIT_EVENT,servlet);
………
return servlet;
}
它基本上描述了对 Servlet 的操作，当装载了 Servlet 后就会调用 Servlet 的 init 方法，同时会传一个 StandardWrapperFacade 对象给 Servlet，这个对象包装了 StandardWrapper，ServletConfig 与它们的关系图如下：
Servlet 可以获得的信息都在 StandardWrapperFacade 封装，这些信息又是在 StandardWrapper 对象中拿到的。所以 Servlet 可以通过 ServletConfig 拿到有限的容器的信息。
当 Servlet 被初始化完成后，就等着 StandardWrapperValve 去调用它的 service 方法了，调用 service 方法之前要调用 Servlet 所有的 filter。
Tomcat 还有其它重要的组件，如安全组件 security、logger 日志组件、session、mbeans、naming 等其它组件。这些组件共同为 Connector 和 Container 提供必要的服务。
988
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
