tomcat中Servlet的工作机制详细介绍

tomcat中Servlet的工作机制

在研究Servlet在tomcat中的工作机制前必须先看看Servlet规范的一些重要的相关规定,规范提供了一个Servlet接口,接口中包含的重要方法是init、service、destroy等方法,Servlet在初始化时要调用init方法,在销毁时要调用destroy方法,而对客户端请求处理时则调用service方法。对于这些机制的支持都必须由Tomcat内部去支持,具体则是由Wrapper容器提供支持。

在tomcat中消息流的流转机制是通过四个不同级别的容器管道机制进行流转的,对于每个请求都是一层一层处理的。如下图,当客户端请求到达服务端后请求被抽象成request对象后向四个容器进行传递,首先经过Engine容器的管道通过若干阀门,最后通过StandardEngineValve阀门流转到Host容器的管道,处理后继续往下流转,通过StandardHostValve阀门流转到Context容器的管道,继续往下流转,通过StandardContextValve阀门流转到Wrapper容器的管道,而对Servlet的核心处理也正是在StandardWrapperValve阀门中。StandardWrapperValve阀门调用Servlet的service方法队请求进行处理,然后对客户端响应。

下面更深入了解下StandardWrapperValve阀门调用Servlet的过程。

web应用的Servlet类都是根据Servlet接口,例如一般我们在写业务处理Servlet类时都会继承HttpServlet类,为了遵循Servlet规范,它其实最终也是实现了Servlet接口,只是HttpServlet定义了HTTP协议的Servlet,将协议共性的东西抽离出来复用。Servlet处理客户端请求的核心方法为service方法,所以对于HttpServlet来说,它需要针对http协议的GET、POST、PU、DELETE、HEAD、OPTIONS、TRACE等请求方法做出不同的分发处理,为方便理解,下面用个简化的代码展示:

public abstract class HttpServlet extends Servlet{
  public void service(ServletRequest req, ServletResponse res) throws ServletException, IOException {
    HttpServletRequest request = (HttpServletRequest) req;
    HttpServletResponse response = (HttpServletResponse) res;
    String method = req.getMethod();
    if (method.equals("GET")) {
      doGet(request, response);
    }else if (method.equals("POST")) {
      doPost(request, response);
    }else if (method.equals("HEAD")) {
      doHead(request, response);
    }
  }
protected void doHead(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException{}
protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException{}
protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {}
}

service方法将请求对象和响应对象转换成HttpServletRequest和HttpServletResponse,然后获取请求方法,根据请求方法调用不同的处理方法,例如如果为GET方法则调用doGet方法,那么在继承了HttpServlet类的Servlet只需重写doGet或doPost方法完成业务逻辑处理,这就是我们熟悉的Servlet了。

这样一来,StandardWrapperValve阀门调用Servlet的工作其实就是通过反射机制实现对Servlet对象的控制,例如在不配置load-on-startup情况下,客户端首次访问该Servlet时由于还不存在该Servlet对象,需要通过反射机制实例化出该Servlet对象,并且调用初始化方法,所以这也是为什么第一次访问某个Servlet时会比较耗时的原因,后面客户端再对该Servlet访问时都会使用该Servlet对象,无需再做实例化和初始化操作。有了Servlet对象后调用其service方法即完成了对客户端请求的处理。

实际上通过反射机制实例化Servlet对象是一个比较复杂的过程,它除了完成实例化和初始化工作外还要解析该Servlet类包含的各种注解并作处理,另外,对于实现了SingleThreadModel接口的Servlet类,它还要维护一个该Servlet对象池。

综上所述,Servlet工作机制大致流程是:request -> StandardEngineValve -> StandardHostValve -> StandardContextValve -> StandardWrapperValve -> 实例化并初始化Servlet对象 -> 调用该Servlet对象的service方法 -> response。

感谢阅读,希望能帮助到大家,谢谢大家对本站的支持!

(0)

相关推荐

  • 详解Java的环境变量和Tomcat服务器配置

    Tomcat 服务器是一个免费的开放源代码的Web 应用服务器,属于轻量级应用服务器,在中小型系统和并发访问用户不是很多的场合下被普遍使用,是开发和调试JSP 程序的首选.对于一个初学者来说,可以这样认为,当在一台机器上配置好Apache 服务器,可利用它响应HTML(标准通用标记语言下的一个应用)页面的访问请求.实际上Tomcat 部分是Apache 服务器的扩展,但它是独立运行的,所以当你运行tomcat 时,它实际上作为一个与Apache 独立的进程单独运行的. 目前Tomcat最新版本为

  • tomcat自定义Web部署文件中docBase和workDir的区别介绍

    本文主要介绍的是tomcat自定义Web部署文件中docBase和workDir的区别,下面话不多说,直接来看详细介绍. 首先看这段tomcat配置文件: <Context path="/web" reloadable="false" docBase="D:\CAPRuntime\src\main\webapp" workDir="D:\CAPRuntime\src\main\webapp"/> 其中的docBas

  • tomcat中Servlet对象池介绍及如何使用

    tomcat中Servlet对象池 Servlet在不实现SingleThreadModel的情况下运行时是以单个实例模式,如下图,这种情况下,Wrapper容器只会通过反射实例化一个Servlet对象,对应此Servlet的所有客户端请求都会共用此Servlet对象,而对于多个客户端请求tomcat会使用多线程处理,所以应该保证此Servlet对象的线程安全,多个线程不管执行顺序如何都能保证执行结果的正确性.例如刚做web应用开发时可能会犯的一个错误:在某个Servlet中使用成员变量累加去统

  • Tomcat怎么实现异步Servlet

    有时Servlet在生成响应报文前必须等待某些耗时的操作,比如在等待一个可用的JDBC连接或等待一个远程Web服务的响应.对于这种情况servlet规范中定义了异步处理方式,由于Servlet中等待阻塞会导致Web容器整体的处理能力低下,所以对于比较耗时的操作可以放置到另外一个线程中进行处理,此过程保留连接的请求和响应对象,在处理完成之后可以把处理的结果通知到客户端. 下面先看Servlet在同步情况下的处理过程,如图所示,Tomcat的客户端请求由管道处理最后会通过Wrapper容器的管道,这

  • 详解Tomcat如何实现Comet

    Comet模式是一种服务器端推技术,它的核心思想提供一种能让当服务器端往客户端发送数据的方式.Comet模式为什么会出现?刚开始人们在客户端通过不断自动刷新整个页面来更新数据,后来觉得体验不好又使用了AJAX不断从客户端轮询服务器更新数据,然后是使用Comet模式由服务器端通过长连接推数据.Comet模式能大大减少发送到服务器端的请求从而避免了很多开销,而且它还具备更好的实时性. 如图所示,客户端发送一个请求到服务器,服务器接收了连接后一直保持住连接不关闭:接着客户端发送一个操作报文告诉服务器需

  • 基于Tomcat7、Java、WebSocket的服务器推送聊天室实例

    前言 HTML5 WebSocket实现了服务器与浏览器的双向通讯,双向通讯使服务器消息推送开发更加简单,最常见的就是即时通讯和对信息实时性要求比较高的应用.以前的服务器消息推送大部分采用的都是"轮询"和"长连接"技术,这两中技术都会对服务器产生相当大的开销,而且实时性不是特别高.WebSocket技术对只会产生很小的开销,并且实时性特别高.下面就开始讲解如何利用WebSocket技术开发聊天室.在这个实例中,采用的是Tomcat7服务器,每个服务器对于WebSoc

  • 详解Tomcat集群如何同步会话

    Tocmat集群中最重要的交换信息就是会话消息,对某个tomcat实例某会话做的更改要同步到集群其他tomcat实例的该会话对象,这样才能保证集群所有实例的会话数据一致.在tribes组件的基础上完成这些工作就相当容易些,tribes是tomcat实现的一个通信框架. 如下图,tomcat实现会话同步的过程中大致会使用如下组件,现在假设中间的tomcat实例的会话改变了,它会通过会话管理器Manager将改变的动作消息封装成消息然后调用集群对象Cluster,通过Cluster将消息发送出去,同

  • Tomcat 部署程序方法步骤

    idea 生成war包.先双击clean,再双击package.生成成功之后就会产生war包. 第二步:将生成好的war文件复制到tomcat文件夹下. 第三步:配置tomcat的server.xml文件. <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true" xmlValidation="false"

  • CentOS系统下安装Tomcat7的过程详解

    1.检查java版本信息 #java -version java version "1.7.0_65" OpenJDK Runtime Environment (rhel-2.5.1.2.el6_5-x86_64 u65-b17) OpenJDK 64-Bit Server VM (build 24.65-b04, mixed mode) 如果没有则安装,则安装jdk 1.1.(以下方式强烈不建议,因为有时候会缺少jar包,导致tomcat启动不成功): yum -y install

  • Tomcat 检测内存泄漏实例详解

     Tomcat如何检测内存泄漏 一般情况下,如果我们重启web应用是通过重启tomcat的话,则不存在内存泄漏问题.但如果不重启tomcat而对web应用进行重加载则可能会导致内存泄漏,因为重加载后有可能会导致原来的某些内存无法让GC回收,例如web应用使用了JDBC,驱动会进行注册,当web应用停止时没有反注册就会导致内存泄漏. 看看是什么原因导致tomcat内存泄漏的.这个要从热部署开始说起,因为tomcat提供了不必重启容器而只需重启web应用以达到热部署的功能,其实现是通过定义一个Web

  • Tomcat 日志切割(logrotate)详细介绍

    Tomcat 日志切割 logrotate是个强大的系统软件,它对日志文件有着一套完整的操作模式,譬如:转储.邮件和压缩等,并且默认logrotate加到cron(/etc/cron.daily/logrotate)作为每日任务执行.自动有了logrotate,我想不用再自己写日志切割脚本. 如下对Tomcat日志catalina.out日志切割 # ls -lh /usr/local/tomcat/logs/catalina.out -rw-r--r-- 1 www www 14M Aug 2

  • Tomcat 热部署的实现原理详解

    Tomcat热部署机制 对于Java应用程序来说,热部署就是在运行时更新Java类文件.在基于Java的应用服务器实现热部署的过程中,类装入器扮演着重要的角色.大多数基于Java的应用服务器,包括EJB服务器和Servlet容器,都支持热部署.类装入器不能重新装入一个已经装入的类,但只要使用一个新的类装入器实例,就可以将类再次装入一个正在运行的应用程序. 我们知道,现在大多数的web服务器都支持热部署,而对于热部署的实现机制,网上讲的却不够完善,下面我们就Tomcat的热部署实现机制,讲解一下它

  • 详解Tomcat7中WebSocket初探

    HTML5中定义了WebSocket规范,该规范使得能够实现在浏览器端和服务器端通过WebSocket协议进行双向通信. 在Web应用中一个常见的场景是Server端向Client端推送某些消息,要实现这项功能,按照传统的思路可以有以下可选方案: Ajax + 轮询 :这种方案仅仅是一个模拟实现,本质还是HTTP请求响应的模式,由于无法预期什么时候推送消息,造成很多无效的请求: 通过 Flash等第三方插件 :这种方式能够实现双向通信,但有一个前提条件就是依赖第三方插件,而在移动端浏览器大多数都

随机推荐