Servlet 工作原理解析Word文档格式.docx

1、从上图可以看出Tomcat的容器分为四个等级，真正管理Servlet的容器是Context容器，一个Context对应一个Web工程，在Tomcat的配置文件中可以很容易发现这一点，如下:清单 1 Context 配置参数 下面详细介绍一下Tomcat解析Context容器的过程，包括如何构建Servlet的过程。Servlet容器的启动过程Tomcat7也开始支持嵌入式功能，增加了一个启动类org.apache.catalina.startup.Tomcat。创建一个实例对象并调用start方法就可以很容易启动Tomcat，我们还可以通过这个对象来增加和修改Tomcat的配置参数，如可以动态

2、增加Context、Servlet等。下面我们就利用这个Tomcat类来管理新增的一个Context容器，我们就选择Tomcat7自带的examples Web工程，并看看它是如何加到这个Context容器中的。清单2. 给Tomcat增加一个Web工程Tomcat tomcat = getTomcatInstance（）; File appDir = new File（getBuildDirectory（）, webapps/examples）; tomcat.addWebapp（null, /examples, appDir.getAbsolutePath（）; tomcat.start（

3、）; ByteChunk res = getUrl（http:/localhost: + getPort（） + /examples/servlets/servlet/HelloWorldExample assertTrue（res.toString（）.indexOf（h1Hello World!/h1） 0）;清单1的代码是创建一个Tomcat实例并新增一个Web应用，然后启动 Tomcat 并调用其中的一个 HelloWorldExample Servlet，看有没有正确返回预期的数据。Tomcat 的addWebapp方法的代码如下:清单3. Tomcat.addWebapppubli

4、c Context addWebapp（Host host, String url, String path） silence（url）; Context ctx = new StandardContext（）; ctx.setPath（ url ）; ctx.setDocBase（path）; if （defaultRealm = null） initSimpleAuth（）; ctx.setRealm（defaultRealm）; ctx.addLifecycleListener（new DefaultWebXmlListener（）; ContextConfig ctxCfg = new

5、 ContextConfig（）; ctx.addLifecycleListener（ctxCfg）; ctxCfg.setDefaultWebXml（org/apache/catalin/startup/NO_DEFAULT_XML if （host = null） getHost（）.addChild（ctx）; else host.addChild（ctx）; return ctx;前面已经介绍了一个Web应用对应一个Context容器，也就是Servlet运行时的Servlet容器，添加一个Web 应用时将会创建一个StandardContext容器，并且给这个Context容器设置必

6、要的参数，url和path分别代表这个应用在Tomcat中的访问路径和这个应用实际的物理路径，这个两个参数与清单1中的两个参数是一致的。其中最重要的一个配置是ContextConfig，这个类将会负责整个Web应用配置的解析工作，后面将会详细介绍。最后将这个Context容器加到父容器Host中。接下去将会调用Tomcat的start方法启动Tomcat，如果你清楚Tomcat的系统架构，你会容易理解Tomcat的启动逻辑，Tomcat的启动逻辑是基于观察者模式设计的，所有的容器都会继承Lifecycle接口，它管理者容器的整个生命周期，所有容器的的修改和状态的改变都会由它去通知已经注册的观察

7、者（Listener），关于这个设计模式可以参考Tomcat的系统架构与设计模式，第二部分:设计模式。Tomcat启动的时序图可以用图 2 表示。上图描述了Tomcat启动过程中，主要类之间的时序关系，下面我们将会重点关注添加examples应用所对应的StandardContext容器的启动过程。当Context容器初始化状态设为init时，添加在Contex容器的Listener将会被调用。ContextConfig继承了 LifecycleListener接口，它是在调用清单3时被加入到StandardContext容器中。ContextConfig类会负责整个 Web应用的配置文件的解

8、析工作。ContextConfig的init方法将会主要完成以下工作:1. 创建用于解析xml配置文件的contextDigester对象2. 读取默认context.xml配置文件，如果存在解析它3. 读取默认Host配置文件，如果存在解析它4. 读取默认Context自身的配置文件，如果存在解析它5. 设置Context的 DocBaseContextConfig的init方法完成后，Context容器的会执行startInternal方法，这个方法启动逻辑比较复杂，主要包括如下几个部分:1. 创建读取资源文件的对象2. 创建ClassLoader对象3. 设置应用的工作目录4. 启动相关

9、的辅助类如:logger、realm、resources 等5. 修改启动状态，通知感兴趣的观察者（Web 应用的配置）6. 子容器的初始化7. 获取ServletContext 并设置必要的参数8. 初始化“load on startup”的ServletWeb应用的初始化工作Web应用的初始化工作是在ContextConfig的configureStart方法中实现的，应用的初始化主要是要解析 web.xml文件，这个文件描述了一个Web应用的关键信息，也是一个Web应用的入口。Tomcat首先会找globalWebXml这个文件的搜索路径是在engine的工作目录下寻找以下两个文件中的任

10、一个org/apache/catalin/startup/NO_DEFAULT_XML或conf/web.xml。接着会找hostWebXml这个文件可能会在 System.getProperty（catalina.base）/conf/$EngineName/$HostName/web.xml.default，接着寻找应用的配置文件 examples/WEB-INF/web.xml。web.xml文件中的各个配置项将会被解析成相应的属性保存在WebXml对象中。如果当前应用支持Servlet3.0，解析还将完成额外9项工作，这个额外的9项工作主要是为Servlet3.0新增的特性，包括jar

11、包中的META-INF/web-fragment.xml的解析以及对annotations的支持。接下去将会将WebXml对象中的属性设置到Context容器中，这里包括创建Servlet对象、filter、listener等等。这段代码在WebXml的configureContext方法中。下面是解析Servlet的代码片段:清单4. 创建Wrapper实例for （ServletDef servlet : servlets.values（） Wrapper wrapper = context.createWrapper（）; String jspFile = servlet.getJspF

12、ile（）; if （jspFile != null） wrapper.setJspFile（jspFile）; if （servlet.getLoadOnStartup（） ! wrapper.setLoadOnStartup（servlet.getLoadOnStartup（）.intValue（）; if （servlet.getEnabled（） ! wrapper.setEnabled（servlet.getEnabled（）.booleanValue（）; wrapper.setName（servlet.getServletName（）; Map params = servlet.

13、getParameterMap（）; for （Entry entry : params.entrySet（） wrapper.addInitParameter（entry.getKey（）, entry.getValue（）; wrapper.setRunAs（servlet.getRunAs（）; Set roleRefs = servlet.getSecurityRoleRefs（）; for （SecurityRoleRef roleRef : roleRefs） wrapper.addSecurityReference（ roleRef.getName（）, roleRef.getL

14、ink（）; wrapper.setServletClass（servlet.getServletClass（）; MultipartDef multipartdef = servlet.getMultipartDef（）; if （multipartdef ! if （multipartdef.getMaxFileSize（） != null & multipartdef.getMaxRequestSize（）! multipartdef.getFileSizeThreshold（） ! wrapper.setMultipartConfigElement（new MultipartConfi

15、gElement（ multipartdef.getLocation（）, Long.parseLong（multipartdef.getMaxFileSize（）, Long.parseLong（multipartdef.getMaxRequestSize（）, Integer.parseInt（ multipartdef.getFileSizeThreshold（）; multipartdef.getLocation（）; if （servlet.getAsyncSupported（） ! wrapper.setAsyncSupported（ servlet.getAsyncSupport

16、ed（）.booleanValue（）; context.addChild（wrapper）;这段代码清楚的描述了如何将Servlet包装成Context容器中的StandardWrapper，这里有个疑问，为什么要将Servlet包装成StandardWrapper而不直接是Servlet对象。这里StandardWrapper是Tomcat容器中的一部分，它具有容器的特征，而Servlet为了一个独立的web开发标准，不应该强耦合在Tomcat中。除了将Servlet包装成StandardWrapper并作为子容器添加到Context中，其它的所有web.xml属性都被解析到Context

17、中，所以说Context容器才是真正运行Servlet的Servlet容器。一个Web应用对应一个Context容器，容器的配置属性由应用的web.xml指定，这样我们就能理解web.xml到底起到什么作用了。创建Servlet实例前面已经完成了Servlet的解析工作，并且被包装成StandardWrapper添加在Context容器中，但是它仍然不能为我们工作，它还没有被实例化。下面我们将介绍Servlet对象是如何创建的，以及如何被初始化的。创建Servlet对象如果Servlet的load-on-startup配置项大于0，那么在Context容器启动的时候就会被实例化，前面提到在解析

18、配置文件时会读取默认的globalWebXml，在conf下的web.xml文件中定义了一些默认的配置项，其定义了两个Servlet，分别是: org.apache.catalina.servlets.DefaultServlet和org.apache.jasper.servlet.JspServlet它们的load-on-startup分别是1和3，也就是当Tomcat启动时这两个Servlet就会被启动。创建Servlet实例的方法是从Wrapper.loadServlet开始的。loadServlet方法要完成的就是获取servletClass然后把它交给InstanceManager去

19、创建一个基于servletClass.class的对象。如果这个Servlet配置了jsp-file，那么这个servletClass就是conf/web.xml中定义的org.apache.jasper.servlet.JspServlet了。创建Servlet对象的相关类结构图如下:图3. 创建 Servlet 对象的相关类结构初始化Servlet初始化Servlet在StandardWrapper的initServlet方法中，这个方法很简单就是调用Servlet的init 的方法，同时把包装了StandardWrapper对象的StandardWrapperFacade作为Servle

20、tConfig传给Servlet。Tomcat容器为何要传StandardWrapperFacade给Servlet对象将在后面做详细解析。如果该Servlet关联的是一个jsp文件，那么前面初始化的就是JspServlet，接下去会模拟一次简单请求，请求调用这个jsp文件，以便编译这个jsp文件为class，并初始化这个class。这样Servlet对象就初始化完成了，事实上Servlet从被web.xml中解析到完成初始化，这个过程非常复杂，中间有很多过程，包括各种容器状态的转化引起的监听事件的触发、各种访问权限的控制和一些不可预料的错误发生的判断行为等等。我们这里只抓了一些关键环节进行阐

21、述，试图让大家有个总体脉络。下面是这个过程的一个完整的时序图，其中也省略了一些细节。图 4. 初始化 Servlet 的时序图Servlet体系结构我们知道Java Web应用是基于Servlet规范运转的，那么Servlet本身又是如何运转的呢？为何要设计这样的体系结构。图5. Servlet顶层类关联图从上图可以看出Servlet规范就是基于这几个类运转的，与Servlet主动关联的是三个类，分别是 ServletConfig、ServletRequest和ServletResponse。这三个类都是通过容器传递给Servlet的，其中 ServletConfig是在Servlet初始化时

22、就传给Servlet了，而后两个是在请求达到时调用Servlet时传递过来的。我们很清楚ServletRequest和ServletResponse在Servlet运行的意义，但是ServletConfig和ServletContext对Servlet有何价值？仔细查看ServletConfig接口中声明的方法发现，这些方法都是为了获取这个Servlet的一些配置属性，而这些配置属性可能在Servlet运行时被用到。而ServletContext又是干什么的呢？Servlet 的运行模式是一个典型的“握手型的交互式”运行模式。所谓“握手型的交互式”就是两个模块为了交换数据通常都会准备一个交易场

23、景，这个场景一直跟随个这个交易过程直到这个交易完成为止。这个交易场景的初始化是根据这次交易对象指定的参数来定制的，这些指定参数通常就会是一个配置类。所以对号入座，交易场景就由ServletContext 来描述，而定制的参数集合就由 ServletConfig 来描述。而 ServletRequest 和 ServletResponse 就是要交互的具体对象了，它们通常都是作为运输工具来传递交互结果。ServletConfig 是在 Servlet init 时由容器传过来的，那么 ServletConfig 到底是个什么对象呢？下图是 ServletConfig 和 ServletConte

24、xt 在 Tomcat 容器中的类关系图。图 6. ServletConfig 在容器中的类关联图上图可以看出StandardWrapper和StandardWrapperFacade都实现了ServletConfig接口，而 StandardWrapperFacade是 StandardWrapper门面类。所以传给Servlet的是StandardWrapperFacade对象，这个类能够保证从StandardWrapper中拿到ServletConfig所规定的数据，而又不把ServletConfig不关心的数据暴露给Servlet。同样ServletContext也与ServletCo

25、nfig有类似的结构，Servlet中能拿到的ServletContext的实际对象也是ApplicationContextFacade对象。ApplicationContextFacade同样保证ServletContex只能从容器中拿到它该拿的数据，它们都起到对数据的封装作用，它们使用的都是门面设计模式。通过ServletContext可以拿到Context 容器中一些必要信息，比如应用的工作路径，容器支持的 Servlet 最小版本等。Servlet中定义的两个ServletRequest和ServletResponse它们实际的对象又是什么呢？，我们在创建自己的 Servlet类时通常

26、使用的都是HttpServletRequest和HttpServletResponse，它们继承了ServletRequest 和 ServletResponse。为何Context容器传过来的ServletRequest、ServletResponse 可以被转化为 HttpServletRequest 和 HttpServletResponse呢？图7. Request相关类结构图上图是Tomcat创建的Request和Response的类结构图。Tomcat一接受到请求首先将会创建 org.apache.coyote.Request和org.apache.coyote.Response，

27、这两个类是Tomcat内部使用的描述一次请求和相应的信息类它们是一个轻量级的类，它们作用就是在服务器接收到请求后，经过简单解析将这个请求快速的分配给后续线程去处理，所以它们的对象很小，很容易被JVM回收。接下去当交给一个用户线程去处理这个请求时又创建org.apache.catalina.connector.Request和org.apache.catalina.connector.Response对象。这两个对象一直穿越整个Servlet容器直到要传给Servlet，传给Servlet的是Request和Response的门面类RequestFacade和RequestFacade，这里使用门面模式与前面一样都是基于同样的目的封装容器中的数据。一次请求对应的Request和Response的类转化如下图所示:图8. Request和Response的转变过程Servlet如何工作我们已经清楚了Servlet是如何被加载的、Servlet是如何被初始化的，以及Servlet的体系结构，现在的问题就是它是如何被调用的。当用户从浏览器向服务器发起一个请求，通常会包含如下信息:/hostname:port/contextpath/servletpath，host