Servlet容器启动过程详解编程语言

一、概念

所谓Servlet容器其实说白了是符合Servlet规范的Java web容器。目前市场上面常用的开源Java Web容器有Tomcat,resin和Jetty。

注意Web容器和HTTP服务器的不同，虽然都是处理web请求的。

在HTTP服务器领域，Apache HTTP的效率是最高的，也是最稳定的，但是只能用于处理静态请求，如果需要支持动态页面请求，则必须要安装相应的插件，比如mod_perl可以处理Perl脚本，mod_python可以处理Python脚本。

上面列举的三种开源Web容器都是使用Java编写的Http服务器，也可以嵌入到Apache中使用。

Tomcat是使用最广的Java Web容器，功能强大，可扩展性强。最新版本的Tomcat（5.5.17）为了提高响应速度和效率，使用了Apache Portable Runtime（APR）作为最底层，使用了APR中包含Socket、缓冲池等多种技术，性能也提高了。APR也是Apache HTTPD的最底层。可想而知，同属于ASF（Apache Software Foundation）中的成员，互补互用的情况还是很多的，虽然使用了不同的开发语言

二、Tomcat容器之多线程

Tomcat的线程池的实现在tomcat-util包中，包含了两种线程池方案。

方案1：使用APR的Pool技术，使用了JNI；

方案2：使用Java实现的ThreadPool

这里只介绍第二种

ThreadPool默认创建了5个线程，保存在一个200维的线程数组中，创建的时候启动这些线程，当没有请求到来的时候，这些线程均处于ready状态等待（其实就是一个while循环，一直在循环等待notify）。当请求到来时，空闲的线程就会被唤醒执行用户的请求。

具体的请求过程为：

• 服务启动的时候创建一个以为线程数组，长度为maxThread=200，并且创建空闲线程随时等待用户请求（minSpareThreads=5个）英语随时等待用户请求；

• 当用户请求到达时，调用threadpool.runIt（ThreadPoolRunnable）方法，讲一个需要执行的实例传给ThreadPool中。其中用户需要执行的实例必须实现ThreadPoolRunnable接口；

• ThreadPool首先查找空闲的线程，如果存在空闲线程，那么运行要执行ThreadPoolRunnable；如果不存在空闲线程且现存线程数量没有超过maxThreads，就一次性创建minSpareThreads个空闲线程；如果现存线程数量已经达到maxThreads，那么后来的请求就只能等待空闲线程释放了

• 如果得到空闲线程，则将该线程从线程数组中一走。接着唤醒已经找到的空闲线程，用它运行执行实例（ThreadPoolRunnable）。运行完ThreadPoolRunnable之后，九江该线程学会从新放到线程数组中，作为空闲线程供后续使用。

　　总结：Tomcat的线程池实现是比较简单的，ThreadPool.java也只有840行代码。用一个一维数组保存空闲的线程，每次以一个较小步伐（minSpareThreads5个）创建空闲线程并放到线程池中。使用时从数组中移走空闲的线程，用完后，再“归还”给线程池。

上面仅仅介绍了tomcat中线程池的实现，下面简要介绍tomcat线程池的使用

Tomcat有两种EndPoint，分别是AprEndpoint和PoolTcpEndpoint。前者自己实现了一套线程池（其实这和Tomcat 老版本的方案是相同的，至今Tomcat中还保留着老版本的线程池，PoolTcpEndpoint也有类似的代码，通过“策略”可以选择不同的线程池方案）。我们只关注PoolTcpEndpoint如何使用ThreadPool的。
首先，PoolTcpEndpoint创建了一个ThreadPoolRunnable实例——LeaderFollowerWorkerThread，实际上该实例就是接收（Accept）并处理（Process）用户socket请求。接着将该实例放进ThreadPool中并运行，此时就可以接收用户的请求了。
当有Socket请求时，LeaderFollowerWorkerThread首先获得了Socket实例，注意此时LeaderFollowerWorkerThread并没有急着处理该Socket，而是在响应Socket消息前，再次将LeaderFollowerWorkerThread放进ThreadPool中，从而它（当然是另外一个线程了）可以继续处理其他用户的Socket请求；接着，拥有Socket的LeaderFollowerWorkerThread再来处理该用户的Socket请求。
整个过程与传统的处理用户Socket请求是不同的，也和Tomcat老版本不同。传统的处理方法是：有一个后台运行的监听线程负责统一处理接收（注意只是“接收”）Socket请求，当有新的Socket请求时，将它赋值给一个Worker线程（通常是唤醒该线程），并有后者处理Socket请求，监听线程继续等待其他Socket请求。所以整个过程中有一个从Listener到Worker切换的过程。
而新版本Tomcat很有创造性的使用了另外一种方法，正如前文所描述的，接收和处理某个用户Socket请求的始终是由一个线程全程负责，没有切换到其他线程处理，少了这种线程间的切换是否更有效率呢？我还不能确认。不过这种使用方式确实有别于传统模式，有种耳目一新的感觉。

线程池一般有三个重要参数：
1. 最大线程数。在程序运行的任何时候，线程数总数都不会超过这个数。如果请求数量超过最大数时，则会等待其他线程结束后再处理。
2. 最大共享线程数，即最大空闲线程数。如果当前的空闲线程数超过该值，则多余的线程会被杀掉。
3. 最小共享线程数，即最小空闲线程数。如果当前的空闲数小于该值，则一次性创建这个数量的空闲线程，所以它本身也是一个创建线程的步长。
线程池有两个概念：
1. Worker线程。工作线程主要是运行执行代码，有两种状态：空闲状态和运行状态。在空闲状态时，类似“休眠”，等待任务；处理运行状态时，表示正在运行任务（Runnable）。
2. 辅助线程。主要负责监控线程池的状态：空闲线程是否超过最大空闲线程数或者小于最小空闲线程数等。如果不满足要求，就调整之。

三、Servlet的单例多线程

上面介绍了tomcat中多线程的实现和工作机制，但是tomcat中的多线程仅仅用来接收请求，而处理处理请求并进行业务处理的是一个个Servlet，本小节中简要介绍Servlet如何处理多个请求的。

首先明确的是：Servlet容器默认是采用但实例多线程的方式来处理多个请求的：

• 当Web服务器启动的时候或者客户端发送请求到服务器的时候，Servlet就会被加载并且实例化（只实例化一次，所以同一个Servlet只存在一个实例）；

• 容器初始化Servlet主要就是读取配置文件（例如tomcat通过server.xml文件中的<Connector>设置线程池中线程的数量，而初始化线程池通过web.xml文件初始化每个参数值等等）。

• 当请求到达时，Servlet容器通过调度线程（Dispatcher Thread）调度他管理下线程池中等待执行的线程（Worker Thread）给请求者；

• 线程根据请求的内容和web.xml文件找到相应的Servlet，并执行相应Servlet实例的service方法；

• 请求处理结束，Work Thread被放回鲜橙汁，等待再次被调用；

从上面可以看出：

1. Servlet单实例，减少了产生servlet的开销；通过线程池来响应多个请求，提高了请求的响应时间；

2. Servlet容器并不关心到达的Servlet请求访问的是否是同一个Servlet还是另一个Servlet，直接分配给它一个新的线程；

3. 如果是同一个Servlet的多个请求，那么Servlet的service方法将在多线程中并发的执行；

4. 每一个请求由ServletRequest对象来接受请求，由ServletResponse对象来响应该请求；

JSP中存在的多线程问题：

当客户端第一次请求某一个JSP文件时，服务端把该JSP编译成一个CLASS文件，并创建一个该类的实例，然后创建一个线程处理CLIENT端的请求。如果有多个客户端同时请求该JSP文件，则服务端会创建多个线程。每个客户端请求对应一个线程。以多线程方式执行可大大降低对系统的资源需求,提高系统的并发量及响应时间.  
 
对JSP中可能用的的变量说明如下:  
实例变量: 实例变量是在堆中分配的,并被属于该实例的所有线程共享，所以不是线程安全的.  
JSP系统提供的8个类变量  
JSP中用到的OUT,REQUEST,RESPONSE,SESSION,CONFIG,PAGE,PAGECONXT是线程安全的(因为每个线程对应的request，respone对象都是不一样的，不存在共享问题), APPLICATION在整个系统内被使用,所以不是线程安全的.  
 
局部变量: 局部变量在堆栈中分配,因为每个线程都有它自己的堆栈空间,所以是线程安全的.  
静态类: 静态类不用被实例化,就可直接使用,也不是线程安全的.  
 
外部资源: 在程序中可能会有多个线程或进程同时操作同一个资源(如:多个线程或进程同时对一个文件进行写操作).此时也要注意同步问题.  
 
使它以单线程方式执行,这时，仍然只有一个实例，所有客户端的请求以串行方式执行。这样会降低系统的性能  
 
问题  
问题一. 说明其Servlet容器如何采用单实例多线程的方式来处理请求  
问题二. 如何在开发中保证servlet是单实例多线程的方式来工作(也就是说如何开发线程安全的servelt)。  
 
一. Servlet容器如何同时来处理多个请求  
 
Java的内存模型JMM（Java Memory Model）  
JMM主要是为了规定了线程和内存之间的一些关系。根据JMM的设计，系统存在一个主内存(Main Memory)，Java中所有实例变量都储存在主存中，对于所有线程都是共享的。每条线程都有自己的工作内存(Working Memory)，工作内存由缓存和堆栈两部分组成，缓存中保存的是主存中变量的拷贝，缓存可能并不总和主存同步，也就是缓存中变量的修改可能没有立刻写到主存中；堆栈中保存的是线程的局部变量，线程之间无法相互直接访问堆栈中的变量。根据JMM，我们可以将论文中所讨论的Servlet实例的内存模型抽象为图所示的模型。  
工作者线程Work Thread:执行代码的一组线程。  
调度线程Dispatcher Thread：每个线程都具有分配给它的线程优先级,线程是根据优先级调度执行的。  
 
Servlet采用多线程来处理多个请求同时访问。servlet依赖于一个线程池来服务请求。线程池实际上是一系列的工作者线程集合。Servlet使用一个调度线程来管理工作者线程。  
 
当容器收到一个Servlet请求，调度线程从线程池中选出一个工作者线程,将请求传递给该工作者线程，然后由该线程来执行Servlet的service方法。当这个线程正在执行的时候,容器收到另外一个请求,调度线程同样从线程池中选出另一个工作者线程来服务新的请求,容器并不关心这个请求是否访问的是同一个Servlet.当容器同时收到对同一个Servlet的多个请求的时候，那么这个Servlet的service()方法将在多线程中并发执行。  
Servlet容器默认采用单实例多线程的方式来处理请求，这样减少产生Servlet实例的开销，提升了对请求的响应时间，对于Tomcat可以在server.xml中通过<Connector>元素设置线程池中线程的数目。  
 
就实现来说：  
调度者线程类所担负的责任如其名字，该类的责任是调度线程，只需要利用自己的属性完成自己的责任。所以该类是承担了责任的，并且该类的责任又集中到唯一的单体对象中。而其他对象又依赖于该特定对象所承担的责任，我们就需要得到该特定对象。那该类就是一个单例模式的实现了。  
 
 
注意：服务器可以使用多个实例来处理请求，代替单个实例的请求排队带来的效益问题。服务器创建一个Servlet类的多个Servlet实例组成的实例池，对于每个请求分配Servlet实例进行响应处理，之后放回到实例池中等待下此请求。这样就造成并发访问的问题。  
此时,局部变量(字段)也是安全的，但对于全局变量和共享数据是不安全的，需要进行同步处理。而对于这样多实例的情况SingleThreadModel接口并不能解决并发访问问题。 SingleThreadModel接口在servlet规范中已经被废弃了。

　　上面说了Servlet在容器中是单实例，因此要注意线程安全问题，尽量不要再servlet里面保存状态值，但是并不是不可以保存。如果必须要这么做那么就必须要考虑线程安全问题了，通常有两种做法：

1、实现SingleThreadModel接口

该接口指定了系统如何处理对同一个Servlet的调用。如果一个Servlet被这个接口指定,那么在这个Servlet中的service方法将不会有两个线程被同时执行，当然也就不存在线程安全的问题。这种方法只要将前面的Concurrent Test类的类头定义更改为：  
 
Public class Concurrent Test extends HttpServlet implements SingleThreadModel {  
…………  
}

2、同步对共享数据的操作

使用synchronized 关键字能保证一次只有一个线程可以访问被保护的区段，在本论文中的Servlet可以通过同步块操作来保证线程的安全。同步后的代码如下：  
 
…………  
Public class Concurrent Test extends HttpServlet { …………  
Username = request.getParameter ("username");  
Synchronized (this){  
Output = response.getWriter ();  
Try {  
Thread. Sleep (5000);  
} Catch (Interrupted Exception e){}  
output.println("用户名:"+Username+"<BR>");  
}  
}  
}

虽然不提倡将Servlet做成线程安全的，但是可能出于某种原因你必须这么做，那么你就要清楚这么做的代价有哪些：

如果一个Servlet实现了SingleThreadModel接口，那么Servlet引擎将会为每一个请求创建一个单独的Servlet实例，在请求结束之后销毁，这将会造成大量的系统开销。SingleThreadModel在Servlet2.4中已经不再提倡使用；同样在程序中使用同步来保护要使用的共享数据，也会使系统的性能大大下降。这是应为被同步的代码块在同一个时刻只能有一个线程执行他，使得其同时处理客户请求的吞吐量降低，而且很多客户处于阻塞状态。另外保证主存内容和线程中的工作内存中的数据的一致性，要频繁的刷新缓存，这也会大大影响系统的性能。所以在实际的开发中也应该避免或者最小化Servlet中的同步代码；在Servlet中避免使用实例变量是保证Servlet线程安全的最佳选择。从Java内存模型也可以知道，方法中的临时变量是在栈上分配空间，而且每一个线程都有自己私有的栈空间，所以他们不会影响线程的安全。

四、线程安全的Servlet

1，变量的线程安全：这里的变量指字段和共享数据(如表单参数值)。  
a，将 参数变量 本地化。多线程并不共享局部变量.所以我们要尽可能的在servlet中使用局部变量。  
例如：String user = "";  
user = request.getParameter("user");  
 
b，使用同步块Synchronized，防止可能异步调用的代码块。这意味着线程需要排队处理。在使用同板块的时候要尽可能的缩小同步代码的范围，不要直接在sevice方法和响应方法上使用同步，这样会严重影响性能。  
 
2,属性的线程安全：ServletContext，HttpSession，ServletRequest对象中属性。  
ServletContext：（线程是不安全的）  
ServletContext是可以多线程同时读/写属性的，线程是不安全的。要对属性的读写进行同步处理或者进行深度Clone()。所以在Servlet上下文中尽可能少量保存会被修改（写）的数据，可以采取其他方式在多个Servlet中共享，比方我们可以使用单例模式来处理共享数据。  
HttpSession：（线程是不安全的）  
HttpSession对象在用户会话期间存在，只能在处理属于同一个Session的请求的线程中被访问，因此Session对象的属性访问理论上是线程安全的。  
当用户打开多个同属于一个进程的浏览器窗口，在这些窗口的访问属于同一个Session，会出现多次请求，需要多个工作线程来处理请求，可能造成同时多线程读写属性。这时我们需要对属性的读写进行同步处理：使用同步块Synchronized和使用读/写器来解决。  
ServletRequest：（线程是安全的）  
对于每一个请求，由一个工作线程来执行，都会创建有一个新的ServletRequest对象，所以ServletRequest对象只能在一个线程中被访问。ServletRequest是线程安全的。注意：ServletRequest对象在service方法的范围内是有效的，不要试图在service方法结束后仍然保存请求对象的引用。  
 
4，不要在Servlet中创建自己的线程来完成某个功能。  
Servlet本身就是多线程的，在Servlet中再创建线程，将导致执行情况复杂化，出现多线程安全问题。  
 
5，在多个servlet中对外部对象(比方文件)进行修改操作一定要加锁，做到互斥的访问。  
 
6，javax.servlet.SingleThreadModel接口是一个标识接口，如果一个Servlet实现了这个接口，那Servlet容器将保证在一个时刻仅有一个线程可以在给定的servlet实例的service方法中执行。将其他所有请求进行排队。  
 
 
PS： 
Servlet并非只是单例的. 当container开始启动,或是客户端发出请求服务时,Container会按照容器的配置负责加载和实例化一个Servlet（也可以配置为多个，不过一般不这么干）.不过一般来说一个servlet只会有一个实例。 
1) Struts2的Action是原型，非单实例的；会对每一个请求,产生一个Action的实例来处理。  
2) Struts1的Action,Spring的Ioc容器管理的bean 默认是单实例的.  
 
Struts1 Action是单实例的，spring mvc的controller也是如此。因此开发时要求必须是线程安全的，因为仅有Action的一个实例来处理所有的请求。单例策略限制了Struts1 Action能作的事，并且要在开发时特别小心。Action资源必须是线程安全的或同步的。  
Spring的Ioc容器管理的bean 默认是单实例的。 
Struts2 Action对象为每一个请求产生一个实例，因此没有线程安全问题。（实际上，servlet容器给每个请求产生许多可丢弃的对象，并且不会导致性能和垃圾回收问题）。 
当Spring管理Struts2的Action时，bean默认是单实例的，可以通过配置参数将其设置为原型。(scope="prototype ）

五、Servlet生命周期

1.Servlet在web服务器启动时被加载并实例化，容器运行其init方法初始化，请求到达时运行其service方法；

2.service运行请求对应的doXXX(doGet,doPost)方法；

3.服务器销毁实例，运行其destory方法； Servlet的生命周期由Servlet容器管理；

三个概念的理解： Servlet容器 & Web容器 & 应用服务器

1、Servlet容器的主要任务就是管理Servlet的生命周期；

2、Web容器也称之为web服务器，主要任务就是管理和部署web应用的；

3、应用服务器的功能非常强大，不仅可以管理和部署web应用，也可以部署EJB应用，实现容器管理的事务等等 Web服务器/Web容器就是跟基于HTTP的请求打交道，而EJB容器更多是跟数据库，邮件服务、事务管理等服务接口交互，所以应用服务器的功能是很多的。

常见的web服务器就是Tomcat,但Tomcat同样也是Servlet服务器； 常见的应用服务器有WebLogic，WebSphere，但都是收费的； 没有Servlet容器，可以用Web容器直接访问静态Html页面，比如安装了apache等；如果需要显示Jsp/Servlet，就需要安装一个Servlet容器；但是光有servlet容器也是不够的，它需要被解析为html显示，所以仍需要一个web容器；所以，我们常把web容器和Servlet容器视为一体，因为他们两个容器都有对方的功能实现了，都没有独立的存在了，比如tomcat！

六、java Web容器工作原理

以tomcat为例进行说明，here we go。先上两张tomcat结构图

 

 

 一个Tomcat web容器启动server服务器从而对外提供service服务，图一中一个service瓦片代表一个部署在tomcat上面的web服务，一个Service的核心组件为Container，而一个Container的核心是Servlet容器，而Servlet容器中管理Servlet的是Context容器；因此就形成了这样的一种组件依赖链：

Tomcat—Service—Container—Servlet容器—Context容器

Servlet容器的启动过程也是这种顺序，如下。

Web应用有Tomcat实例添加到Tomcat 中，即由Tomcat管理一个新添加的Context容器。前面已经提到一个web应用对应一个Context容器，也就是Servlet运行时的Servlet容器。在Servlet API中有一个ServletContextListener接口，它能够监听ServletContext对象的生命周期，实际上就是监听Web应用的生命周期。

当Web应用启动或者终止的时候，会触发ServletContextEvent事件，该时间是有ServletContextListener来处理。在ServletContextListner接口中定义了处理ServletContextEvent时间的两个方法。contextInitialized（ServletContextEvent event）和contextDestryed（ServletContextEvent event）方法，在Servlet容器启动Web应用时和终止Web应用时调用。

• Servlet容器启动时，触发servletContextEvent事件,并通知相应的监听器servletContextListener；

• Servlet容器在启动的过程中通过servletContextListener监视servletContext的状态（初始化或者销毁servletContext）；即

• servletContextListener中通过contextInitialized初始化方法，根据web.xml对servletContext进行配置，即将Context容器的属性缓存在内存中，供Service服务利用；

contextConfig是一个监听器，在Tomcat创建Context容器时被加入到servletContext中，contextConfig负责整个Web应用的配置文件（包括web.xml）的解析工作。

Web应用的初始化是在contextConfig中实现的，应用的初始化主要是对Web.xml配置文件进行解析，这个文件中描述了Web应用的关键信息，同时也是整个Web应用的入口。Tomcat将web.xml文件解析之后将其中的属性设置到Context容器中，主要包涵下面动作：

• 启动一个WEB项目的时候，WEB容器会去读取它的配置文件web.xml，读取<context-param>结点。

• 容创建一个ServletContext（servlet上下文），这个 web项目的所有部分都将共享这个上下文。 

• 容器将<context-param>转换为键值对，并交给 servletContext。 因为listener, filter 等在初始化时会用到这些上下文中的信息，所以要先加载。 

• 容器创建<listener>中的类实例，创建监听器。

• 加载filter和servlet 

load- on-startup 元素在web应用启动的时候指定了servlet被加载的顺序，它的值必须是一个整数。

如果它的值是一个负整数或是这个元素不存在，那么容器会在该servlet被调用的时候，加载这个servlet。如果值是正整数或零，容器在配置的时候就加载并初始化这个servlet，容器必须保证值小的先被加载。如果值相等，容器可以自动选择先加载谁。

web.xml 的加载顺序是：context-param -> listener -> filter -> servlet。