servlet的基本原理_简述arp的工作原理

大家好，又见面了，我是你们的朋友全栈君。如果您正在找激活码,请点击查看最新教程,关注关注公众号 “全栈程序员社区” 获取激活教程,可能之前旧版本教程已经失效.最新Idea2022.1教程亲测有效,一键激活。

Jetbrains全系列IDE稳定放心使用

Web技术成为当今主流的互联网 Web 应用技术之一，而 Servlet 是 Java Web 技术的核心基础。因而掌握 Servlet的工作原理是成为一名合格的 Java Web 技术开发人员的基本要求。本文将带你认识 Java Web 技术是如何基于 Servlet工作，以 Tomcat 为例了解 Servlet 容器是如何工作的？一个 Web 工程在 Servlet 容器中是如何启动的？Servlet 容器如何解析你在 web.xml 中定义的 Servlet ？用户的请求是如何被分配给指定的 Servlet 的？Servlet 容器如何管理 Servlet 生命周期？Servlet 的 API 的类层次结构，以及 Servlet中一些难点问题的分析。

从 Servlet 容器说起

要介绍 Servlet 必须要先把 Servlet 容器说清楚，Servlet 与 Servlet容器的关系有点像枪和子弹的关系，枪是为子弹而生，而子弹又让枪有了杀伤力。虽然它们是彼此依存的，但是又相互独立发展，这一切都是为了适应工业化生产的结果。从技术角度来说是为了解耦，通过标准化接口来相互协作。既然接口是连接Servlet 与 Servlet 容器的关键，那我们就从它们的接口说起。

前面说了 Servlet容器作为一个独立发展的标准化产品，目前它的种类很多，但是它们都有自己的市场定位，很难说谁优谁劣，各有特点。例如现在比较流行的Jetty，在定制化和移动领域有不错的发展，我们这里还是以大家最为熟悉 Tomcat 为例来介绍 Servlet 容器如何管理Servlet。Tomcat 本身也很复杂，我们只从 Servlet 与 Servlet 容器的接口部分开始介绍，关于 Tomcat的详细介绍可以参考我的另外一篇文章《 Tomcat 系统架构与模式设计分析》。

Tomcat 的容器等级中，Context 容器是直接管理 Servlet 在容器中的包装类 Wrapper，所以 Context容器如何运行将直接影响 Servlet 的工作方式。

图 1 . Tomcat 容器模型

servlet的基本原理_简述arp的工作原理从上图可以看出Tomcat 的容器分为四个等级，真正管理 Servlet 的容器是 Context 容器，一个 Context 对应一个 Web工程，在 Tomcat 的配置文件中可以很容易发现这一点，如下：

清单 1Context 配置参数

Context path=”/projectOne “docBase=”D:\projects\projectOne”
reloadable=”true”

下面详细介绍一下Tomcat 解析 Context 容器的过程，包括如何构建 Servlet 的过程。

Servlet容器的启动过程

Tomcat7也开始支持嵌入式功能，增加了一个启动类 org.apache.catalina.startup.Tomcat。创建一个实例对象并调用start 方法就可以很容易启动 Tomcat，我们还可以通过这个对象来增加和修改 Tomcat 的配置参数，如可以动态增加Context、Servlet 等。下面我们就利用这个 Tomcat 类来管理新增的一个 Context 容器，我们就选择Tomcat7 自带的 examples Web 工程，并看看它是如何加到这个 Context容器中的。

清单 2 . 给Tomcat 增加一个 Web 工程

Tomcattomcat = getTomcatInstance();
File appDir = newFile(getBuildDirectory(), “webapps/examples”);
tomcat.addWebapp(null, “/examples”,appDir.getAbsolutePath());
tomcat.start();
ByteChunk res = getUrl(“http://localhost:” + getPort()+ “/examples/servlets/servlet/HelloWorldExample”);
assertTrue(res.toString().indexOf(“HelloWorld!“) > 0);

清单2的代码是创建一个 Tomcat 实例并新增一个 Web 应用，然后启动 Tomcat 并调用其中的一个HelloWorldExample Servlet，看有没有正确返回预期的数据。

Tomcat 的addWebapp 方法的代码如下：

清单 3.Tomcat.addWebapp

public 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 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 容器设置必要的参数，url 和 path分别代表这个应用在 Tomcat 中的访问路径和这个应用实际的物理路径，这个两个参数与清单 1中的两个参数是一致的。其中最重要的一个配置是 ContextConfig，这个类将会负责整个 Web应用配置的解析工作，后面将会详细介绍。最后将这个 Context 容器加到父容器 Host 中。

接下去将会调用Tomcat 的 start 方法启动 Tomcat，如果你清楚 Tomcat 的系统架构，你会容易理解 Tomcat的启动逻辑，Tomcat 的启动逻辑是基于观察者模式设计的，所有的容器都会继承 Lifecycle接口，它管理者容器的整个生命周期，所有容器的的修改和状态的改变都会由它去通知已经注册的观察者（Listener），关于这个设计模式可以参考《Tomcat 的系统架构与设计模式，第二部分：设计模式》。Tomcat 启动的时序图可以用图 2表示。

图 2.Tomcat 主要类的启动时序图

servlet的基本原理_简述arp的工作原理上图描述了Tomcat 启动过程中，主要类之间的时序关系，下面我们将会重点关注添加 examples 应用所对应的StandardContext 容器的启动过程。

当Context 容器初始化状态设为 init 时，添加在 Contex 容器的 Listener将会被调用。ContextConfig 继承了 LifecycleListener 接口，它是在调用清单 3 时被加入到StandardContext 容器中。ContextConfig 类会负责整个 Web应用的配置文件的解析工作。

ContextConfig的 init 方法将会主要完成以下工作：

创建用于解析xml 配置文件的 contextDigester 对象

读取默认context.xml 配置文件，如果存在解析它

读取默认Host 配置文件，如果存在解析它

读取默认Context 自身的配置文件，如果存在解析它

设置Context 的 DocBase

ContextConfig的 init 方法完成后，Context 容器的会执行 startInternal方法，这个方法启动逻辑比较复杂，主要包括如下几个部分：

创建读取资源文件的对象

创建ClassLoader 对象

设置应用的工作目录

启动相关的辅助类如：logger、realm、resources等

修改启动状态，通知感兴趣的观察者（Web应用的配置）

子容器的初始化

获取ServletContext 并设置必要的参数

初始化“loadon startup”的 Servlet

Web应用的初始化工作

Web应用的初始化工作是在 ContextConfig 的 configureStart 方法中实现的，应用的初始化主要是要解析web.xml 文件，这个文件描述了一个 Web 应用的关键信息，也是一个 Web 应用的入口。

Tomcat首先会找 globalWebXml 这个文件的搜索路径是在 engine 的工作目录下寻找以下两个文件中的任一个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 包中的 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.getJspFile();

            if (jspFile != null) {

                wrapper.setJspFile(jspFile);

            if (servlet.getLoadOnStartup() != null) {

                wrapper.setLoadOnStartup(servlet.getLoadOnStartup().intValue());

            if (servlet.getEnabled() != null) {

                wrapper.setEnabled(servlet.getEnabled().booleanValue());

            wrapper.setName(servlet.getServletName());

            Map params = servlet.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.getLink());

            wrapper.setServletClass(servlet.getServletClass());

            MultipartDef multipartdef = servlet.getMultipartDef();

            if (multipartdef != null) {

                if (multipartdef.getMaxFileSize() != null &&

                        multipartdef.getMaxRequestSize()!= null &&

                        multipartdef.getFileSizeThreshold() != null) {

                    wrapper.setMultipartConfigElement(new

 MultipartConfigElement(

                            multipartdef.getLocation(),

                            Long.parseLong(multipartdef.getMaxFileSize()),

                            Long.parseLong(multipartdef.getMaxRequestSize()),

                            Integer.parseInt(

                                    multipartdef.getFileSizeThreshold())));

                } else {

                    wrapper.setMultipartConfigElement(new

 MultipartConfigElement(

                            multipartdef.getLocation()));

            if (servlet.getAsyncSupported() != null) {

                wrapper.setAsyncSupported(

                        servlet.getAsyncSupported().booleanValue());

            context.addChild(wrapper);

这段代码清楚的描述了如何将Servlet 包装成 Context 容器中的 StandardWrapper，这里有个疑问，为什么要将 Servlet 包装成StandardWrapper 而不直接是 Servlet 对象。这里 StandardWrapper 是 Tomcat容器中的一部分，它具有容器的特征，而 Servlet 为了一个独立的 web 开发标准，不应该强耦合在 Tomcat中。

除了将Servlet 包装成 StandardWrapper 并作为子容器添加到 Context 中，其它的所有 web.xml属性都被解析到 Context 中，所以说 Context 容器才是真正运行 Servlet 的 Servlet 容器。一个 Web应用对应一个 Context 容器，容器的配置属性由应用的 web.xml 指定，这样我们就能理解 web.xml到底起到什么作用了。

回页首

创建Servlet 实例

前面已经完成了Servlet 的解析工作，并且被包装成 StandardWrapper 添加在 Context容器中，但是它仍然不能为我们工作，它还没有被实例化。下面我们将介绍 Servlet对象是如何创建的，以及如何被初始化的。

创建Servlet 对象

如果Servlet 的 load-on-startup 配置项大于 0，那么在 Context容器启动的时候就会被实例化，前面提到在解析配置文件时会读取默认的 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 去创建一个基于 servletClass.class的对象。如果这个 Servlet 配置了 jsp-file，那么这个 servletClass 就是 conf/web.xml中定义的 org.apache.jasper.servlet.JspServlet 了。

创建Servlet 对象的相关类结构图如下：

图 3.创建 Servlet 对象的相关类结构

servlet的基本原理_简述arp的工作原理我们知道 Java Web 应用是基于 Servlet 规范运转的，那么 Servlet本身又是如何运转的呢？为何要设计这样的体系结构。

图 5.Servlet 顶层类关联图

上图是 Tomcat 创建的 Request 和 Response 的类结构图。Tomcat 一接受到请求首先将会创建org.apache.coyote.Request 和 org.apache.coyote.Response，这两个类是 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的体系结构，现在的问题就是它是如何被调用的。

当用户从浏览器向服务器发起一个请求，通常会包含如下信息：http://hostname: port/contextpath/servletpath，hostname 和 port 是用来与服务器建立 TCP 连接，而后面的 URL才是用来选择服务器中那个子容器服务用户的请求。那服务器是如何根据这个 URL 来达到正确的 Servlet 容器中的呢？

Tomcat7.0 中这件事很容易解决，因为这种映射工作有专门一个类来完成的，这个就是org.apache.tomcat.util.http.mapper，这个类保存了 Tomcat 的 Container容器中的所有子容器的信息，当 org.apache.catalina.connector. Request 类在进入Container 容器之前，mapper 将会根据这次请求的 hostnane 和 contextpath 将 host 和context 容器设置到 Request 的 mappingData 属性中。所以当 Request 进入 Container容器之前，它要访问那个子容器这时就已经确定了。

图 9.Request 的 Mapper 类关系图

public void init() {

        findDefaultHost();

        Engine engine = (Engine) connector.getService().getContainer();

        engine.addContainerListener(this);

        Container[] conHosts = engine.findChildren();

        for (Container conHost : conHosts) {

            Host host = (Host) conHost;

            if (!LifecycleState.NEW.equals(host.getState())) {

                host.addLifecycleListener(this);

                registerHost(host);

这段代码的作用就是将 MapperListener 类作为一个监听者加到整个 Container容器中的每个子容器中，这样只要任何一个容器发生变化，MapperListener 都将会被通知，相应的保存容器关系的MapperListener 的 mapper 属性也会修改。for 循环中就是将 host 及下面的子容器注册到 mapper中。