WEB请求处理三：Servlet容器请求处理

时间 2019-11-12

标签 web 请求处理 servlet 容器栏目 HTML 繁體版

原文原文链接

#0 系列目录#php

本篇文章将给你们讲述Servlet容器中请求处理的过程，在给本篇文章起标题时，一直在“应用服务器”与“Servlet容器”这二者之间拿捏不定，主要是由于要清晰的区分开这二者的关系：Servlet容器能够说是应用服务器的一个子集。又因为本文的初衷是讲述你们日常使用比较多的Servlet为主，因此，给本篇就起了《Servlet容器请求处理》的名字。html

先说下在整个WEB请求处理过程当中，本篇文章讲述的是哪一个流程模块。为直观明了，先上一张图，红色部分为本章所述模块：前端

所讲述的请求流程模块，你们已经很清楚了。那怎么给你们去讲的更清晰，你们理解的更容易呢？固然是，带着问题去学习，吸取或许会更快些啦。：）java

开篇以前，给你们提如下几个问题，这些问题是本文的主体思路（也是我的学习路线）：nginx

WEB服务器那么多，Apache、Tomcat、Nginx、Jetty、Resin，名词那么多，HTTP Server、Application Server、Web Server、Servlet Container，他们是什么？之间关系是什么？区别又在哪？程序员

CGI、WSGI、Servlet、JSP、FastCGI等等，他们是什么？他们之间区别又在哪？和上面WEB服务器之间关系是什么？web

Servlet生命周期及工做原理是什么？算法

HTTP Request进入到Tomcat中执行，请求处理流程如何？如何找到对应的Application并进行请求处理？数据库

#1 WEB服务器# 只要Web上的Server都叫Web Server，可是你们分工不一样，解决的问题也不一样，因此根据Web Server提供的功能，每一个Web Server的名字也会不同。apache

按功能分类，Web Server能够分为：

|- Web Server
        |- Http Server
        |- Application Server
            |- Servlet Container
            |- CGI Server
            |- ......

##1.1 Http Server## HTTP Server本质上也是一种应用程序——它一般运行在服务器之上，绑定服务器的IP地址并监听某一个tcp端口来接收并处理HTTP请求，这样客户端（通常来讲是IE, Firefox，Chrome这样的浏览器）就可以经过HTTP协议来获取服务器上的网页（HTML格式）、文档（PDF格式）、音频（MP4格式）、视频（MOV格式）等等资源。下图描述的就是这一过程：

一个HTTP Server关心的是HTTP协议层面的传输和访问控制，因此在Apache/Nginx上你能够看到代理、负载均衡等功能。

客户端经过HTTP Server访问服务器上存储的静态资源（HTML文件、图片文件等等）。

经过CGI/Servlet技术，也能够将处理过的动态内容经过HTTP Server分发，可是一个HTTP Server始终只是把服务器上的文件如实的经过HTTP协议传输给客户端。

HTTP Server中常用的是Apache、Nginx两种，HTTP Server主要用来作静态内容服务、代理服务器、负载均衡等。直面外来请求转发给后面的应用服务（Tomcat，django什么的）。

|- Http Server
    |- Apache
    |- Nginx

###1.1.1 Apache HTTP服务器### Apache HTTP服务器是一个模块化的服务器，能够运行在几乎全部普遍使用的计算机平台上。Apache支持模块多，性能稳定，Apache自己是静态解析，适合静态HTML、图片等，但能够经过扩展脚本、模块等支持动态页面等。

Apache能够支持PHPcgiperl，可是要使用Java的话，你须要Tomcat在Apache后台支撑，将Java请求由Apache转发给Tomcat处理。

###1.1.2 Nginx HTTP服务器### Nginx是一个高性能的HTTP和反向代理服务器，同时也是一个IMAP/POP3/SMTP 代理服务器。

其特色是占有内存少，并发能力强。Nginx代码彻底用C语言从头写成。

具备很高的稳定性。其它HTTP服务器，当遇到访问的峰值，或者有人恶意发起慢速链接时，也极可能会致使服务器物理内存耗尽频繁交换，失去响应，只能重启服务器。例如当前apache一旦上到200个以上进程，web响应速度就明显很是缓慢了。

而Nginx采起了分阶段资源分配技术，使得它的CPU与内存占用率很是低。Nginx官方表示保持10000个没有活动的链接，它只占2.5M内存，因此相似DOS这样的攻击对nginx来讲基本上是毫无用处的。就稳定性而言，Nginx比Lighthttpd更胜一筹。

###1.1.3 Nginx与Apache比较### Nginx相对于Apache的优势：

轻量级，一样启动WEB服务，比Apache占用更少的内存以及资源；

抗并发性能高，核心区别在于Apache是同步多进程模型，一个链接对应一个进程。Nginx是异步的，多个链接（万级别）能够对应一个进程；

Nginx模块较少，配置简单，因此Nginx能够将资源用在数据处理以及进程上面，Apache模块较多比较全，相对稳定，但在内存资源上消耗比较大；

Nginx能够在不间断的状况下进行软件版本的升级；

Nginx处理静态页面性能比apache高3倍多；

选择高并发高性能就选择Nginx，若是要稳定，选择Apache，主要根据服务器要面临的需求而定。

固然，二者也能够组合使用：

Nginx放前端+apache放后端+MYSQL+PHP：能够提升服务器负载能力

Nginx处理静态页面请求如MP3，GIF.JPG.JS，apache处理动态页面请求，充分结合了两者的优点；

##1.2 Application Server## Application Server 是一个应用执行的服务器。它首先须要支持开发语言的 Runtime（对于 Tomcat 来讲，就是 Java），保证应用可以在应用服务器上正常运行。其次，须要支持应用相关的规范，例如类库、安全方面的特性。与HTTP Server相比，Application Server可以动态的生成资源并返回到客户端。

|- Application Server
    |- Tomcat
    |- Jetty

当初在Apache Server开发时还未出现Servlet的概念，因此Apache不能内置支持Servlet。实际上，除了Apache，其余许多HTTP Server软件都不能直接支持Servlet。为了支持Servlet，一般要单独开发程序，这种程序通常称为服务器小程序容器（Servlet Container），有时也叫作服务器小程序引擎（Servlet Engine）。它是Web服务器或应用程序服务器的一部分，用于在发送的请求和响应之上提供网络服务，解码基于MIME的请求，格式化基于MIME的响应，它在Servlet的生命周期内包容和管理Servlet，是一个实时运行的外壳程序。运行时由Web服务器软件处理通常请求，并把Servlet调用传递给“容器”来处理。

好比，对于 Tomcat 来讲，就是须要提供 JSP/Sevlet 运行须要的标准类库、Interface 等。为了方便，应用服务器每每也会集成 HTTP Server 的功能，可是不如专业的 HTTP Server 那么强大，因此Application Server每每是运行在 HTTP Server 的背后，执行应用，将动态的内容转化为静态的内容以后，经过 HTTP Server 分发到客户端。

Tomcat运行在JVM之上，它和HTTP服务器同样，绑定IP地址并监听TCP端口，同时还包含如下指责：

管理Servlet程序的生命周期；

将URL映射到指定的Servlet进行处理；

与Servlet程序合做处理HTTP请求——根据HTTP请求生成HttpServletRequest/Response对象并传递给Servlet进行处理，将Servlet中的HttpServletResponse对象生成的内容返回给浏览器；

因此 Tomcat 属因而一个「Application Server」，可是更准确的来讲，是一个「Servlet/JSP」应用的容器（Ruby/Python 等其余语言开发的应用也没法直接运行在 Tomcat 上）。

###1.2.1 Servlet容器工做模式### 按照工做模式的不一样，Servlet容器能够分为如下3类：

独立运行的Servlet容器

在这种模式下，Servlet容器做为构成Web服务器的一部分而存在。当使用基于Java的Web服务器时，就属于这种状况。这种方式是Tomcat的默认模式，然而大多数Web服务器并非基于Java的，因此就产生了下面的两种其余类型。

内置的Servlet容器

Servlet容器由Web服务器插件和Java容器两部分组成。采用这种方式时，Web服务器插件须要在某个Web服务器内部地址空间中打开一个JVM（Java虚拟机），在此JVM上加载Java容器并运行Servlet。若是客户端调用Servlet，Web服务器插件首先得到此请求的控制并将它传递（使用JNI技术）给Java容器，而后Java容器把此请求交给Servlet来处理。这种方式运行速度较快，而且可以提供良好的性能，适用于单进程、多线程服务器，可是在伸缩性方面存在不足。

外置的Servlet容器

采用这种方式时，Servlet容器运行在Web服务器外部地址空间。先由Web服务器插件在某个Web服务器外部地址空间打开一个JVM（Java虚拟机），而后加载Java容器来运行Servlet。Web服务器插件和JVM之间使用IPC（进程间通讯）机制（一般是TCP/IPSockets）。若是客户端调用Servlet，Web服务器插件首先得到此请求的控制并将它传递（使用IPC技术）给Java容器，而后Java容器把此请求交给Servlet来处理。这种方式对客户端请求的处理速度不如内置Servlet那样快，可是在其余方面（如可伸缩性、稳定性等）具备优点。

Tomcat属于Servlet容器，其工做模式也分为上述3种，因此Tomcat既可被用做独立运行的Servlet引擎（便于开发和调试），又可做为一个须要加强功能的Web服务器（如当前的Apache、IIS和Netscape服务器）插件。在配置Tomcat以前，就须要肯定采用哪一种工做模式，工做模式（1）比较简单，直接安装Tomcat便可，工做模式（2）和（3）有些复杂，除了安装Tomcat、Web服务器以外，还须要安装链接二者的中间链接件。

###1.2.2 Apache与Tomcat整合使用### 虽然Tomcat也能够认为是HTTP服务器，但一般它仍然会和Apache/Nginx配合在一块儿使用：

动静态资源分离——运用Nginx的反向代理功能分发请求：全部动态资源的请求交给Tomcat，而静态资源的请求（例如图片、视频、CSS、JavaScript文件等）则直接由Nginx返回到浏览器，这样能大大减轻Tomcat的压力；

负载均衡——当业务压力增大时，可能一个Tomcat的实例不足以处理，那么这时能够启动多个Tomcat实例进行水平扩展，而Nginx的负载均衡功能能够把请求经过算法分发到各个不一样的实例进行处理；

整合的好处：

若是客户端请求的是静态页面，则只须要Apache服务器响应请求。

若是客户端请求动态页面，则是Tomcat服务器响应请求。

由于JSP是服务器端解释代码的，这样整合就能够减小Tomcat的服务开销。

#2 什么是CGI# 如上文所述，HTTP服务器是一个很简单的东西，并不负责动态网页的构建，只能转发静态网页。事物老是不断发展，网站也愈来愈复杂，因此出现动态技术。同时Apache也说，它能支持perl，生成动态网页。这个支持perl，实际上是Apache越位了，作了一件额外的事情。

既然HTTP Server本身不能作，外包给别人吧，可是要与第三作个约定，我给你什么，而后你给我什么，就是握把请求参数发送给你，而后我接收你的处理结果给客户端。那这个约定就是Common Gateway Interface，简称CGI。

CGI全称是“通用网关接口”(Common Gateway Interface)，是HTTP服务器与你的或其它机器上的程序进行“交谈”的一种工具，其程序须运行在网络服务器上，是一种根据请求信息动态产生响应内容的接口协议。CGI能够用任何一种语言编写，只要这种语言具备标准输入、输出和环境变量。如php，perl，tcl等。

经过CGI，HTTP Server能够将根据请求不一样启动不一样的外部程序，并将请求内容转发给该程序，在程序执行结束后，将执行结果做为回应返回给客户端。也就是说，对于每一个请求，都要产生一个新的进程进行处理。由于每一个进程都会占有不少服务器的资源和时间，这就致使服务器没法同时处理不少的并发请求。另外CGI程序都是与操做系统平台相关的，虽然在互联网爆发的初期，CGI为开发互联网应用作出了很大的贡献，可是随着技术的发展，开始逐渐衰落。

因此，CGI的定义是：外部应用程序与HTTP 服务器之间的接口协议。

##2.1 CGI工做原理## HTTP Server与CGI程序请求处理流程：

HTTP服务器将根据CGI程序的类型决定数据向CGI程序的传送方式，通常来说是经过标准输入/输出流和环境变量来与CGI程序间传递数据。以下图所示：

**CGI程序经过标准输入（STDIN）和标准输出（STDOUT）来进行输入输出。**此外CGI程序还经过环境变量来获得输入，操做系统提供了许多环境变量，它们定义了程序的执行环境，应用程序能够存取它们。HTTP服务器和CGI接口又另外设置了一些环境变量，用来向CGI程序传递一些重要的参数。CGI的GET方法还经过环境变量QUERY-STRING向CGI程序传递Form中的数据。

##2.2 CGI环境变量## 下面是一些经常使用的CGI环境变量：

每当客户请求CGI的时候，HTTP服务器就请求操做系统生成一个新的CGI解释器进程(如php-cgi.exe)，CGI的一个进程则处理完一个请求后退出，下一个请求来时再建立新进程。固然，这样在访问量不多没有并发的状况也行。但是当访问量增大，并发存在，这种方式就不适合了。因而就有了FastCGI。

#3 什么是FastCGI# FastCGI像是一个常驻(long-live)型的CGI，它能够一直执行着，只要激活后，不会每次都要花费时间去fork一次(这是CGI最为人诟病的fork-and-execute 模式)。它还支持分布式的运算, 即 FastCGI 程序能够在网站服务器之外的主机上执行而且接受来自其它网站服务器来的请求。

FastCGI是语言无关的、可伸缩架构的CGI开放扩展，其主要行为是将CGI解释器进程保持在内存中并所以得到较高的性能。众所周知，CGI解释器的反复加载是CGI性能低下的主要缘由，若是CGI解释器保持在内存中并接受FastCGI进程管理器调度，则能够提供良好的性能、伸缩性、Fail- Over特性等等。

##3.1 FastCGI工做原理##

HTTP Server启动时载入FastCGI进程管理器（IIS ISAPI或Apache Module)；

FastCGI进程管理器自身初始化，启动多个CGI解释器进程(可见多个php-cgi)并等待来自HTTP Server的链接；

当客户端请求到达HTTP Server时，FastCGI进程管理器选择并链接到一个CGI解释器。HTTP Server将CGI环境变量和标准输入发送到FastCGI子进程php-cgi；

FastCGI子进程完成处理后将标准输出和错误信息从同一链接返回HTTP Server。当FastCGI子进程关闭链接时，请求便告处理完成。FastCGI子进程接着等待并处理来自FastCGI进程管理器(运行在HTTP Server中)的下一个链接。在CGI模式中，php-cgi在此便退出了。

在上述状况中，你能够想象CGI一般有多慢。每个Web请求PHP都必须从新解析php.ini、从新载入所有扩展并重初始化所有数据结构。使用FastCGI，全部这些都只在进程启动时发生一次。一个额外的好处是，持续数据库链接(Persistent database connection)能够工做。

##3.2 FastCGI与CGI特色##

如CGI，FastCGI也具备语言无关性；
如CGI，FastCGI在进程中的应用程序，独立于核心web服务器运行，提供了一个比API更安全的环境。(API把应用程序的代码与核心的web服务器连接在一块儿，这意味着在一个错误的API的应用程序可能会损坏其余应用程序或核心服务器; 恶意的API的应用程序代码甚至能够窃取另外一个应用程序或核心服务器的密钥。)
FastCGI技术目前支持语言有：C/C++、Java、Perl、Tcl、Python、SmallTalk、Ruby等。相关模块在Apache, ISS, Lighttpd等流行的服务器上也是可用的。
如CGI，FastCGI的不依赖于任何Web服务器的内部架构，所以即便服务器技术的变化, FastCGI依然稳定不变。

#4 什么是PHP-CGI# PHP-CGI是PHP自带的FastCGI管理器。PHP-CGI的不足：

PHP-CGI变动php.ini配置后，需重启PHP-CGI才能让新的php-ini生效，不能够平滑重启；

直接杀死PHP-CGI进程，php就不能运行了。(PHP-FPM和Spawn-FCGI就没有这个问题，守护进程会平滑重新生成新的子进程。）

#5 什么是PHP-FPM# PHP-FPM是一个PHP FastCGI管理器，是只用于PHP的，使用PHP-FPM来控制PHP-CGI的FastCGI进程，它负责管理一个进程池，来处理来自Web服务器的请求。能够在 http://php-fpm.org/download 下载获得。

相对Spawn-FCGI，PHP-FPM在CPU和内存方面的控制都更胜一筹，并且前者很容易崩溃，必须用crontab进行监控，而PHP-FPM则没有这种烦恼。

PHP-FPM提供了更好的PHP进程管理方式，能够有效控制内存和进程、能够平滑重载PHP配置，比Spawn-FCGI具备更多优势，因此被PHP官方收录了。在PHP 5.3.3中能够直接使用PHP-FPM了。

在./configure的时候带 –enable-fpm参数便可开启PHP-FPM。

##5.1 PHP-FPM工做原理## Apache+PHP配合使用，会在Apache配置下面一段：

LoadModule php5_module C:/php/php5apache2_2.dll

当PHP须要在Apache服务器下运行时，通常来讲，它能够模块的形式集成，此时模块的做用是接收Apache传递过来的PHP文件请求，并处理这些请求，而后将处理后的结果返回给Apache。若是咱们在Apache启动前在其配置文件中配置好了PHP模块，PHP模块经过注册apache2的ap_hook_post_config挂钩，在Apache启动的时候启动此模块以接受PHP文件的请求。

**Apache的Hook机制是指：Apache容许模块(包括内部模块和外部模块，例如mod_php5.so，mod_perl.so等)将自定义的函数注入到请求处理循环中。**换句话说，模块能够在Apache的任何一个处理阶段中挂接(Hook)上本身的处理函数，从而参与Apache的请求处理过程。mod_php5.so/php5apache2.dll就是将所包含的自定义函数，经过Hook机制注入到Apache中，在Apache处理流程的各个阶段负责处理php请求。

有人测试Nginx+PHP-FPM在高并发状况下可能会达到Apache+mod_php5的5~10倍，如今Nginx+PHP-FPM使用的人愈来愈多。

#6 什么是Spawn-FCGI# Spawn-FCGI是一个通用的FastCGI管理服务器，它是lighttpd中的一部份，不少人都用Lighttpd的Spawn-FCGI进行FastCGI模式下的管理工做，不过有很多缺点。而PHP-FPM的出现多少缓解了一些问题，但PHP-FPM有个缺点就是要从新编译，这对于一些已经运行的环境可能有不小的风险(refer)。

Spawn-FCGI目前已经独成为一个项目，更加稳定一些，也给不少Web 站点的配置带来便利。已经有很多站点将它与nginx搭配来解决动态网页。

##6.1 PHP-FPM与Spawn-CGI对比## PHP-FPM、Spawn-FCGI都是守护PHP-CGI的进程管理器。

PHP-FPM的使用很是方便，配置都是在PHP-FPM.ini的文件内，而启动、重启均可以从php/sbin/PHP-FPM中进行。更方便的是修改php.ini后能够直接使用PHP-FPM reload进行加载，无需杀掉进程就能够完成php.ini的修改加载。使用PHP-FPM可使PHP有不小的性能提高。PHP-FPM控制的进程CPU回收的速度比较慢，内存分配的很均匀。

Spawn-FCGI控制的进程CPU降低的很快，而内存分配的比较不均匀。有不少进程彷佛未分配到，而另一些却占用很高。多是因为进程任务分配的不均匀致使的。而这也致使了整体响应速度的降低。而PHP-FPM合理的分配，致使整体响应的提到以及任务的平均。

#7 什么是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技术的。

##7.1 Servlet生命周期## 做为一名专业编程人员，您碰到的大多数 Java servlet 都是为响应 Web 应用程序上下文中的 HTTP 请求而设计的。**所以，javax.servlet 和 javax.servlet.http 包中特定于 HTTP 的类是您应该关心的。**对于Servlet容器(Tomcat)与HttpServlet是怎样进行交互的呢，看下类图：

Servlet的框架是由两个Java包组成的：javax.servlet与javax.servlet.http。在javax.servlet包中定义了全部的Servlet类都必须实现或者扩展的通用接口和类。在javax.servlet.http包中定义了采用Http协议通讯的HttpServlet类。Servlet的框架的核心是javax.servlet.Servlet接口，全部的Servlet都必须实现这个接口。在Servlet接口中定义了5个方法，其中3个方法表明了Servlet的生命周期：

init(ServletConfig)方法：负责初始化Servlet对象，在Servlet的生命周期中，该方法执行一次；该方法执行在单线程的环境下，所以开发者不用考虑线程安全的问题；

service(ServletRequest req,ServletResponse res)方法：负责响应客户的请求；为了提升效率，Servlet规范要求一个Servlet实例必须可以同时服务于多个客户端请求，即service()方法运行在多线程的环境下，Servlet开发者必须保证该方法的线程安全性；

destroy()方法：当Servlet对象退出生命周期时，负责释放占用的资源；

编程注意事项说明：

当Server Thread线程执行Servlet实例的init()方法时，全部的Client Service Thread线程都不能执行该实例的service()方法，更没有线程可以执行该实例的destroy()方法，所以Servlet的init()方法是工做在单线程的环境下，开发者没必要考虑任何线程安全的问题。
当服务器接收到来自客户端的多个请求时，服务器会在单独的Client Service Thread线程中执行Servlet实例的service()方法服务于每一个客户端。此时会有多个线程同时执行同一个Servlet实例的service()方法，所以必须考虑线程安全的问题。
请你们注意，虽然service()方法运行在多线程的环境下，并不必定要同步该方法。而是要看这个方法在执行过程当中访问的资源类型及对资源的访问方式。分析以下：

若是service()方法没有访问Servlet的成员变量也没有访问全局的资源好比静态变量、文件、数据库链接等，而是只使用了当前线程本身的资源，好比非指向全局资源的临时变量、request和response对象等。该方法自己就是线程安全的，没必要进行任何的同步控制。

若是service()方法访问了Servlet的成员变量，可是对该变量的操做是只读操做，该方法自己就是线程安全的，没必要进行任何的同步控制。

若是service()方法访问了Servlet的成员变量，而且对该变量的操做既有读又有写，一般须要加上同步控制语句。

若是service()方法访问了全局的静态变量，若是同一时刻系统中也可能有其它线程访问该静态变量，若是既有读也有写的操做，一般须要加上同步控制语句。

若是service()方法访问了全局的资源，好比文件、数据库链接等，一般须要加上同步控制语句。

在建立一个 Java servlet 时，通常须要子类 HttpServlet。该类中的方法容许您访问请求和响应包装器（wrapper），您能够用这个包装器来处理请求和建立响应。大多数程序员都知道Servlet的生命周期，简单的归纳这就分为四步：

Servlet类加载--->实例化--->服务--->销毁；

建立Servlet对象的时机：

**默认状况下，在Servlet容器启动后：**客户首次向Servlet发出请求，Servlet容器会判断内存中是否存在指定的Servlet对象，若是没有则建立它，而后根据客户的请求建立HttpRequest、HttpResponse对象，从而调用Servlet对象的service方法；
**Servlet容器启动时：**当web.xml文件中若是<servlet>元素中指定了<load-on-startup>子元素时，Servlet容器在启动web服务器时，将按照顺序建立并初始化Servlet对象；
**Servlet的类文件被更新后，从新建立Servlet。**Servlet容器在启动时自动建立Servlet，这是由在web.xml文件中为Servlet设置的<load-on-startup>属性决定的。从中咱们也能看到同一个类型的Servlet对象在Servlet容器中以单例的形式存在；

注意：在web.xml文件中，某些Servlet只有<serlvet>元素，没有<servlet-mapping>元素，这样咱们没法经过url的方式访问这些Servlet，这种Servlet一般会在<servlet>元素中配置一个<load-on-startup>子元素，让容器在启动的时候自动加载这些Servlet并调用init(ServletConfig config)方法来初始化该Servlet。其中方法参数config中包含了Servlet的配置信息，好比初始化参数，该对象由服务器建立。

销毁Servlet对象的时机：

Servlet容器中止或者从新启动：Servlet容器调用Servlet对象的destroy方法来释放资源。以上所讲的就是Servlet对象的生命周期。那么Servlet容器如何知道建立哪个Servlet对象？Servlet对象如何配置？实际上这些信息是经过读取web.xml配置文件来实现的。

<servlet>
    <!-- Servlet对象的名称 -->
    <servlet-name>action<servlet-name>
    <!-- 建立Servlet对象所要调用的类 -->
    <servlet-class>org.apache.struts.action.ActionServlet</servlet-class>
    <init-param>
        <!-- 参数名称 -->
        <param-name>config</param-name>
        <!-- 参数值 -->
        <param-value>/WEB-INF/struts-config.xml</param-value>
    </init-param>
    <init-param>
        <param-name>detail</param-name>
        <param-value>2</param-value>
    </init-param>
    <init-param>
        <param-name>debug</param-name>
        <param-value>2</param-value>
    </init-param>
    <!-- Servlet容器启动时加载Servlet对象的顺序 -->
    <load-on-startup>2</load-on-startup>
</servlet>
<!-- 要与servlet中的servlet-name配置节内容对应 -->
<servlet-mapping>
    <servlet-name>action</servlet-name>
    <!-- 客户访问的Servlet的相对URL路径 -->
    <url-pattern>*.do</url-pattern>
</servlet-mapping>

当Servlet容器启动的时候读取<servlet>配置节信息，根据<servlet-class>配置节信息建立Servlet对象，同时根据<init-param>配置节信息建立HttpServletConfig对象，而后执行Servlet对象的init方法，而且根据<load-on-startup>配置节信息来决定建立Servlet对象的顺序，若是此配置节信息为负数或者没有配置，那么在Servlet容器启动时，将不加载此Servlet对象。当客户访问Servlet容器时，Servlet容器根据客户访问的URL地址，经过<servlet-mapping>配置节中的<url-pattern>配置节信息找到指定的Servlet对象，并调用此Servlet对象的service方法。

在整个Servlet的生命周期过程当中，建立Servlet实例、调用实例的init()和destroy()方法都只进行一次，当初始化完成后，Servlet容器会将该实例保存在内存中，经过调用它的service()方法，为接收到的请求服务。下面给出Servlet整个生命周期过程的UML序列图，如图所示：

若是须要让Servlet容器在启动时即加载Servlet，能够在web.xml文件中配置<load-on-startup>元素。

##7.2 Servlet工做原理## 上面描述了Servlet的生命周期，接着咱们描述一下Tomcat与Servlet是如何工做的，首先看下面的时序图：

Web Client 向Servlet容器（Tomcat）发出Http请求；

Servlet容器接收Web Client的请求；

Servlet容器建立一个HttpRequest对象，将Web Client请求的信息封装到这个对象中；

Servlet容器建立一个HttpResponse对象；

Servlet容器调用HttpServlet对象的service方法，把HttpRequest对象与HttpResponse对象做为参数传给 HttpServlet对象；

HttpServlet调用HttpRequest对象的有关方法，获取Http请求信息；

HttpServlet调用HttpResponse对象的有关方法，生成响应数据；

Servlet容器把HttpServlet的响应结果传给Web Client；

##7.3 CGI与Servlet比较## CGI应用开发比较困难，由于它要求程序员有处理参数传递的知识，这不是一种通用的技能。CGI不可移植，为某一特定平台编写的CGI应用只能运行于这一环境中。每个CGI应用存在于一个由客户端请求激活的进程中，而且在请求被服务后被卸载。这种模式将引发很高的内存、CPU开销，并且在同一进程中不能服务多个客户。

Servlet对CGI的最主要优点在于一个Servlet被客户端发送的第一个请求激活，而后它将继续运行于后台，等待之后的请求。每一个请求将生成一个新的线程，而不是一个完整的进程。多个客户可以在同一个进程中同时获得服务。通常来讲，Servlet进程只是在Web Server卸载时被卸载。

Servlet提供了Java应用程序的全部优点——可移植、稳健、易开发。使用Servlet Tag技术，Servlet可以生成嵌于静态HTML页面中的动态内容。

综上，Servlet处于服务器进程中，它经过多线程方式运行其service方法，一个实例能够服务于多个请求，而且其实例通常不会销毁。而CGI对每一个请求都产生新的进程，服务完成后就销毁，因此效率上低于Servlet。

CGI与Servlet的对比：

**对比一：**当用户浏览器发出一个Http/CGI的请求，或者说调用一个CGI程序的时候，服务器端就要新启用一个进程(并且是每次都要调用)，调用CGI程序越多(特别是访问量高的时候)，就要消耗系统越多的处理时间，只剩下愈来愈少的系统资源，对于用户来讲，只能是漫长的等待服务器端的返回页面了，这对于电子商务激烈发展的今天来讲，不能不说是一种技术上的遗憾。

而Servlet充分发挥了服务器端的资源并高效的利用。每次调用Servlet时并非新启用一个进程，而是在一个Web服务器的进程中共享和分离线程，而线程最大的好处在于能够共享一个数据源，使系统资源被有效利用。

**对比二：**传统的CGI程序，不具有平台无关性特征，系统环境发生变化，CGI程序就要瘫痪，而Servlet具有Java的平台无关性，在系统开发过程当中保持了系统的可扩展性、高效性。

对比三：传统技术中，通常大都为二层的系统架构，即Web服务器+数据库服务器，致使网站访问量大的时候，没法克服CGI程序与数据库创建链接时速度慢的瓶颈，从而死机、数据库死锁现象频繁发生。而Servlet有链接池的概念，它能够利用多线程的优势，在系统缓存中事先创建好若干与数据库的链接，到时候若想和数据库打交道能够随时跟系统"要"一个链接便可，反应速度可想而知。

#8 Tomcat工做原理# Tomcat 的结构很复杂，可是 Tomcat 也很是的模块化，找到了 Tomcat 最核心的模块，您就抓住了 Tomcat 的“七寸”。下面是 Tomcat 的整体结构图：

从上图能够看出Tomcat的核心是两个组件：链接器（Connector）和容器（Container）。Connector组件是负责生成请求对象和响应对象的，Tomcat默认的是HttpConnector，负责根据收到的Http请求报文生成Request对象和Response对象，并把这两个对象传递给Container，而后根据Response中的内容生成相应的HTTP报文。

Container是容器的父接口，全部子容器都必须实现这个接口，简单来讲就是服务器部署的项目是运行在Container中的。Container里面的项目获取到Connector传递过来对应的的Request对象和Response对象进行相应的操做。

Connector能够根据不一样的设计和应用场景进行替换。一个Container能够选择对应多个Connector。多个Connector和一个Container就造成了一个Service，有了Service就能够对外提供服务了。

Tomcat要为一个Servlet的请求提供服务，须要作三件事：

建立一个request对象并填充那些有可能被所引用的Servlet使用的信息，如参数，头部、cookies、查询字符串等。一个request对象就是javax.servlet.ServletRequest或javax.servlet.http.ServletRequest接口的一个实例。

建立一个response对象，所引用的servlet使用它来给客户端发送响应。一个response对象是javax.servlet.ServletResponse或javax.servlet.http.ServletResponse接口的一个实例。

调用servlet的service方法，并传入request和response对象。这里servlet会从request对象取值，给response写值。

根据servlet返回的response生成相应的HTTP响应报文。

既然咱们已经抓到Tomcat的“七寸”，两个核心组件：链接器（Connector）和容器（Container），那这样从链接器（Connector）入手，来看下Tomcat处理HTTP请求的流程。

不少开源应用服务器都是集成tomcat做为web container的，并且对于tomcat的servlet container这部分代码不多改动。这样，这些应用服务器的性能基本上就取决于Tomcat处理HTTP请求的connector模块的性能。

##8.1 Connector种类## Tomcat源码中与connector相关的类位于org.apache.coyote包中，Connector分为如下几类：

Http Connector，基于HTTP协议，负责创建HTTP链接。它又分为BIO Http Connector与NIO Http Connector两种，后者提供非阻塞IO与长链接Comet支持。

AJP Connector，基于AJP协议，AJP是专门设计用来为tomcat与http服务器之间通讯专门定制的协议，能提供较高的通讯速度和效率。如与Apache服务器集成时，采用这个协议。

APR HTTP Connector，用C实现，经过JNI调用的。主要提高对静态资源（如HTML、图片、CSS、JS等）的访问性能。如今这个库已独立出来可用在任何项目中。Tomcat在配置APR以后性能很是强劲。

##8.2 Connector配置## 对Connector的配置位于conf/server.xml文件中。

###8.2.1 BIO HTTP/1.1 Connector配置###

<Connector port=”8080” protocol=”HTTP/1.1” maxThreads=”150” 
    connectionTimeout=”20000” redirectPort=”8443” />

其它一些重要属性以下：

acceptCount : 接受链接request的最大链接数目，默认值是10；

address : 绑定IP地址，若是不绑定，默认将绑定任何IP地址；

allowTrace : 若是是true,将容许TRACE HTTP方法；

compressibleMimeTypes : 各个mimeType, 以逗号分隔，如text/html,text/xml；

compression : 若是带宽有限的话，能够用GZIP压缩；

connectionTimeout : 超时时间，默认为60000ms (60s)；

maxKeepAliveRequest : 默认值是100；

maxThreads : 处理请求的Connector的线程数目，默认值为200；

若是是SSL配置，以下：

<Connector port="8181" protocol="HTTP/1.1" SSLEnabled="true" 
    maxThreads="150" scheme="https" secure="true" 
    clientAuth="false" sslProtocol = "TLS" 
    address="0.0.0.0" 
    keystoreFile="E:/java/jonas-full-5.1.0-RC3/conf/keystore.jks" 
    keystorePass="changeit" />

其中，keystoreFile为证书位置，keystorePass为证书密码。

###8.2.2 NIO HTTP/1.1 Connector配置###

<Connector port=”8080” protocol=”org.apache.coyote.http11.Http11NioProtocol” 
    maxThreads=”150” connectionTimeout=”20000” redirectPort=”8443” />

###8.2.3 Native APR Connector配置###

ARP是用C/C++写的，对静态资源（HTML，图片等）进行了优化。因此要下载本地库tcnative-1.dll与openssl.exe，将其放在%tomcat%\bin目录下。

下载地址是：http://tomcat.heanet.ie/native/1.1.10/binaries/win32/

在server.xml中要配置一个Listener,以下图。这个配置tomcat是默认配好的。

<!--APR library loader. Documentation at /docs/apr.html --> 
<Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" />

配置使用APR connector

<Connector port=”8080” protocol=”org.apache.coyote.http11.Http11AprProtocol” 
    maxThreads=”150” connectionTimeout=”20000” redirectPort=”8443” />

若是配置成功，启动tomcat,会看到以下信息：

org.apache.coyote.http11.Http11AprProtocol init

##8.3 Tomcat架构模块##

Server(服务器)是Tomcat构成的顶级构成元素，全部一切均包含在Server中，Server的实现类StandardServer能够包含一个到多个Services;

次顶级元素Service的实现类为StandardService调用了容器(Container)接口，实际上是调用了Servlet Engine(引擎)，并且StandardService类中也指明了该Service归属的Server；

接下来次级的构成元素就是容器(Container)：主机(Host)、上下文(Context)和引擎(Engine)均继承自Container接口，因此它们都是容器。可是，它们是有父子关系的，在主机(Host)、上下文(Context)和引擎(Engine)这三类容器中，引擎是顶级容器，直接包含是主机容器，而主机容器又包含上下文容器，因此引擎、主机和上下文从大小上来讲又构成父子关系，虽然它们都继承自Container接口。

链接器(Connector)将Service和Container链接起来，首先它须要注册到一个Service，它的做用就是把来自客户端的请求转发到Container(容器)，这就是它为何称做链接器的缘由。

##8.4 Tomcat运行流程##

假设来自客户的请求为：http://localhost:8080/test/index.jsp

请求被发送到本机端口8080，被在那里侦听的Coyote HTTP/1.1 Connector得到；

Connector把该请求交给它所在的Service的Engine来处理，并等待Engine的回应；

Engine得到请求localhost:8080/test/index.jsp，匹配它全部虚拟主机Host；

Engine匹配到名为localhost的Host（即便匹配不到也把请求交给该Host处理，由于该Host被定义为该Engine的默认主机）；

localhost Host得到请求/test/index.jsp，匹配它所拥有的全部Context；

Host匹配到路径为/test的Context（若是匹配不到就把该请求交给路径名为""的Context去处理）；

path="/test"的Context得到请求/index.jsp，在它的mapping table中寻找对应的servlet；

Context匹配到URL PATTERN为*.jsp的servlet，对应于JspServlet类；

构造HttpServletRequest对象和HttpServletResponse对象，做为参数调用JspServlet的doGet或doPost方法；

Context把执行完了以后的HttpServletResponse对象返回给Host；

Host把HttpServletResponse对象返回给Engine；

Engine把HttpServletResponse对象返回给Connector；

Connector把HttpServletResponse对象返回给客户browser；