上一篇:http://blog.csdn.net/wabiaozia/article/details/50311995
深入理解Java Servlet与Web容器之间的关系
理解Java Servlet与Web容器之间的关系,有利于理解Java Web应用的运行方式。进而让Java开发者能够设计和开发出更合理的Java Web应用程序。
【51CTO特稿】自从计算机软件开发进入网络时代,就开始涉及到通讯问题。在客户/服务器(也叫C/S应用)时期,每个软件都有自己的客户端和服务器端软件。并且客户端和服务器端之间的通讯协议差别也很大。后来随着互联网的发展,基于浏览器/服务器的应用逐渐成为主流,通讯协议也统一到HTTP协议。但是,在HTTP协议之上,如何处理来自客户端的请求信息,以及如何对请求进行回应,则经历了很长时间也没有统一下来。目前,对于这个问题的解决方案主要有两种,一个是CGI,另一个是Servlet。
CGI(Common Gateway Interface),通用网关接口
通用网关接口,简称CGI,是一种根据请求信息动态产生回应内容的技术。通过CGI,Web 服务器可以将根据请求不同启动不同的外部程序,并将请求内容转发给该程序,在程序执行结束后,将执行结果作为回应返回给客户端。也就是说,对于每个请求,都要产生一个新的进程进行处理。因为每个进程都会占有很多服务器的资源和时间,这就导致服务器无法同时处理很多的并发请求。另外CGI程序都是与操作系统平台相关的,虽然在互联网爆发的初期,CGI为开发互联网应用做出了很大的贡献,但是随着技术的发展,开始逐渐衰落。
Servlet
Servlet最初是在1995年由James Gosling 提出的,因为使用该技术需要复杂的Web服务器支持,所以当时并没有得到重视,也就放弃了。后来随着Web应用复杂度的提升,并要求提供更高的并发处理能力,Servlet被重新捡起,并在Java平台上得到实现,现在提起Servlet,指的都是Java Servlet。Java Servlet要求必须运行在Web服务器当中,与Web服务器之间属于分工和互补关系。确切的说,在实际运行的时候Java Servlet与Web服务器会融为一体,如同一个程序一样运行在同一个Java虚拟机(JVM)当中。与CGI不同的是,Servlet对每个请求都是单独启动一个线程,而不是进程。这种处理方式大幅度地降低了系统里的进程数量,提高了系统的并发处理能力。另外因为Java Servlet是运行在虚拟机之上的,也就解决了跨平台问题。如果没有Servlet的出现,也就没有互联网的今天。
在Servlet出现之后,随着使用范围的扩大,人们发现了它的一个很大的一个弊端。那就是为了能够输出HTML格式内容,需要编写大量重复代码,造成不必要的重复劳动。为了解决这个问题,基于Servlet技术产生了JavaServet Pages技术,也就是JSP。Servlet和JSP两者分工协作,Servlet侧重于解决运算和业务逻辑问题,JSP则侧重于解决展示问题。Servlet与JSP一起为Web应用开发带来了巨大的贡献,后来出现的众多Java Web应用开发框架都是基于这两种技术的,更确切的说,都是基于Servlet技术的。
Java Servlet与Web容器之间的关系
Java是一种动态加载和运行的语言。也就是说当应用程序持有一个类的地址(CLASSPATH)和名称(包名和类名)的情况下,可以在程序运行期间任何时候加载这个类,并创建和使用该类的对象。Servlet就是基于这个机制与Web容器融合在一起的。目前已知的所有支持Java Servlet的Web容器都是采用Java开发的。当Web容器接收到来自客户端的请求信息之后,会根据URL中的Web元件地址信息到Servlet队列中查找对应的Servlet对象,如果找到则直接使用,如果没有找到则加载对应的类,并创建对象。也就是说,Servlet对象是在第一次被使用的时候才创建的,并且一旦创建就会被反复使用,不再创建新的对象。所有创建出的Servlet对象会在Web服务器停止运行的时候统一进行垃圾回收。
为了解决客户端请求地址与Java Servlet之间对应关系问题,Web容器需要一个用来描述这种对应关系的文件,一般是web.xml文件。如果一个Web应用程序中存在很多个Servlet,那么web.xml会变得非常庞大。在Servlet 3.0规范推出之后,允许在Servlet代码中使用声明式语法来代替web.xml中的描述信息,这才让web.xml瘦身下来。下图是这个过程的一个示意图。
在这个图中,我们仅仅是概要的,采用以比较容易理解的方式描述了Web容器与Servlet之间的关系,以及当接受到请求之后的处理流程。在实际的Web容器中,会比这要复杂很多。
web.xml 中的listener、 filter、servlet 加载顺序及其详解
一、
1、启动一个WEB项目的时候,WEB容器会去读取它的配置文件web.xml,读取<listener> 和<context-param>两个结点。
2、紧急着,容创建一个ServletContext(servlet上下文),这个 web项目的所有部分都将共享这个上下文。
3、容器将<context-param>转换为键值对,并交给 servletContext。
4、容器创建<listener>中的类实例,创建监听器。
二、
load- on-startup 元素在web应用启动的时候指定了servlet被加载的顺序,它的值必须是一个整数。如果它的值是一个负整数或是这个元素不存 在,那么容器会在该servlet被调用的时候,加载这个servlet 。如果值是正整数或零,容器在配置的时候就加载并初始化这个servlet,容 器必须保证值小的先被加载。如果值相等,容器可以自动选择先加载谁。
在servlet的配置当中,<load-on- startup>5</load-on-startup>的含义是:
标记容器是否在启动的时候就加载这个servlet。
当 值为0或者大于0时,表示容器在应用启动时就加载这个servlet;
当是一个负数时或者没有指定时,则指示容器在该servlet被选择时才 加载。
正数的值越小,启动该servlet的优先级越高。
三、
首 先可以肯定的是,加载顺序与它们在 web.xml 文件中的先后顺序无关。即不会因为 filter 写在 listener 的前面而会先加 载 filter。最终得出的结论是:listener -> filter -> servlet
同时还存 在着这样一种配置节:context-param,它用于向 ServletContext 提供键值对,即应用程序上下文信息。我们 的 listener, filter 等在初始化时会用到这些上下文中的信息,那么 context-param 配置节是不是应该写 在 listener 配置节前呢?实际上 context-param 配置节可写在任意位置,因此真正的加载顺序为:context- param -> listener -> filter -> servlet
对于某类配置节而言, 与它们出现的顺序是有关的。以 filter 为例,web.xml 中当然可以定义多个 filter,与 filter 相关的一个配置节 是 filter-mapping,这里一定要注意,对于拥有相同 filter-name 的 filter 和 filter-mapping 配置 节而言,filter-mapping 必须出现在 filter 之后,否则当解析到 filter-mapping 时,它所对应的 filter- name 还未定义。web 容器启动时初始化每个 filter 时,是按照 filter 配置节出现的顺序来初始化的,当请求资源匹配多 个 filter-mapping 时,filter 拦截资源是按照 filter-mapping 配置节出现的顺序来依次调 用 doFilter() 方法的。
servlet 同 filter 类似 ,此处不再赘述。
由 此,可以看出,web.xml 的加载顺序是:context- param -> listener -> filter -> servlet ,而同个类型之间的实际程序调用的时候的顺序是根据 对应的 mapping 的顺序进行调用的。