tomcat 详解
首先搞清楚几个概念:Servlet容器与web容器。Servlet容器的主要任务是管理servlet的生命周期,而web容器更准确的说应该叫web服务器,它是来管理和部署web应用的。还有一种服务器叫做应用服务器,它的功能比web服务器要强大的多,它可以部署EJB应用,可以实现容器管理的事务,一般的应用服务器有weblogic和websphere等,它们都是商业服务器,功能强大但都是收费的。web容器最典型的就是tomcat,apache了。
Tomcat是一个免费的开源的Serlvet容器,也就是说它可以处理servlet请求。但它也不仅仅是一个servlet容器,它也是一个web容器,具有传统web服务器的功能,比如处理html页面等。但是它处理静态html,css,js的能力不如Apache,Apache只是web容器,不能用来处理jsp和servlet请求,但是它在对文字,图片,js,css等内容的请求有自己的一套管理方法,非常优秀,因此一般用来处理对这类静态资源的请求。因此,我们可以在部署应用的时候把tomcat和apache结合起来,让apache来负责处理静态资源的请求,而tomcat用来负责解析动态的jsp和servlet的请求。
在 Tomcat中,应用程序的部署很简单,只要讲应用打成WAR包,放到Tomcat的webapp目录下,Tomcat会自动检测到这个文件,并将其解压。通常在浏览器中第一次访问某个应用的jsp时,速度都会比较慢,这是因为Tomcat要将jsp解析成servlet文件,然后进行编译。编译过一次之后,以后再次访问这个页面,速度就会很快了。另外 Tomcat也提供了一个应用:manager,访问这个应用需要用户名和密码,用户名和密码存储在一个xml文件中。通过这个应用,辅助于Ftp,可以在远程通过Web部署和撤销应用。当然本地也可以。
① Server 一个server代表了整个catalina servlet容器,其实就是BackGroud程序,在Tomcat里面的Server的用处是启动和监听服务端事件(诸如重启、关闭等命令)。
② Service Service是由一个或多个Connector与一个Engine的组合。这些Connector共享一个Engine来处理请求。
③ Connector Connector将在某个指定的端口上来监听客户的请求,把从socket传递过来的数据,封装成Request,传递给Engine来处理,并从Engine处获得响应并返回给客户。 Tomcat通常会用到两种Connector: a) Http Connector 在端口8080处侦听来自客户browser的http请求。 b) AJP Connector 在端口8009处侦听来自其它WebServer(Apache)的servlet/jsp代理请求。
④ Engine 负责处理来自相关联的service的所有请求,处理后,将结果返回给service,而connector是作为service与engine的中间媒介出现的。 一个engine下可以配置多个虚拟主机,每个虚拟主机都有一个域名。当engine获得一个请求时,它把该请求匹配到某个虚拟主机(host)上,然后把请求交给该主机来处理。 Engine有一个默认主机,当请求无法匹配到任何一个虚拟主机时,将交给默认host来处理。
⑤ Host 代表一个虚拟主机,每个虚拟主机和某个网络域名(Domain Name)相匹配。 每个虚拟主机下都可以部署一个或多个web应用,每个web应用对应于一个context,有一个context path。 当Host获得一个请求时,将把该请求匹配到某个Context上,然后把该请求交给该Context来处理匹配的方法是“最长匹配”,所以一个path==””的Context将成为该Host的默认Context所有无法和其它Context的路径名匹配的请求都将最终和该默认Context匹配。
⑥ Context 一个Context对应于一个Web应用,一个Web应用由一个或者多个Servlet组成Context在创建的时候将根据配置文件$CATALINA_HOME/conf/web.xml和$WEBAPP_HOME/WEB-INF/web.xml载入Servlet类。当Context获得请求时,将在自己的映射表(mapping table)中寻找相匹配的Servlet类,如果找到,则执行该类,获得请求的回应,并返回。
在Container这层,包含了3种容器:Engine,Host,Context。容器里面又盛装着各种各样的组件,可以理解为提供各种各样的增值服务。 Manager:当一个容器里面装了manager组件后,这个容器就支持session管理了, 事实上在tomcat里面的session管理,就是靠的在context里面装的manager component。 Logger:当一个容器里面装了logger组件后,这个容器里所发生的事情,就被该组件记录下来了。我们通常会在logs/这个目录下看见catalina_log.time.txt以及localhost.time.txt和localhost_examples_log.time.txt。这就是因为我们分别为:engine,host以及context(examples)这三个容器安装了logger组件,这也是默认安装,又叫做标配。
下面我们来了解一下tomcat中的主要的配置文件: ① Server.xml 这个文件描述了如何启动tomcat server。
a) 在这个文件的开头我们就可以看到“<Server port="8005" shutdown="SHUTDOWN" debug="0">”,前面说到Tomcat里的Server的用处是启动和监听服务端事件,这里的“SHUTDOWN”就是server在监听服务端事件的时候所使用的命令字,server在端口8005处等待关闭命令,如果接收到”SHUTDOWN”字符串则关闭服务器。
b) 下面看一下connector的配置:
- <Connector port="8080" protocol="HTTP/1.1" URIEncoding="GBK"
- maxThreads="150"
- minSpareThreads="25"
- maxSpareThreads="75"
- acceptCount="100"
- connectionTimeout="20000"
- redirectPort="8443" />
<Connector port="8080" protocol="HTTP/1.1" URIEncoding="GBK" maxThreads="150" minSpareThreads="25" maxSpareThreads="75" acceptCount="100" connectionTimeout="20000" redirectPort="8443" />
port:表示在端口号8080处侦听来自客户browser的HTTP1.1请求。 minProcessors :该Connector先创建5个线程放入线程池中等待客户请求,每个客户请求由一个线程负责。 minSpareThreads:表示线程池中将始终保持有这么多个线程,即使没有人用也将开这么多空线程等待。 maxSpareThreads:表示线程池中最多可以保留的空闲线程数,例如maxSpareThreads=75,某时刻有80个请求在访问服务器,然后访问结束,这80个空闲的线程不会都保留下来,tomcat会关闭5个空闲线程,最多只保留75个空闲的线程。 maxThreads:线程池中的最大线程数量,表示服务器可以最多同时处理这么多个连接请求。当线程池中现有的线程不够服务客户请求时,若线程总数不足maxThreads,则创建新线程来处理请求。 acceptCount :当现有线程已经达到最大数maxThreads时,接下来的客户请求将进入请求队列中进行排队,当排队队列中请求数超过acceptCount时,后来的请求将对其返回Connection refused错误。 redirectport :当客户请求是https时,把该请求转发到端口8443去。
c) Engine的配置 Engine用来处理Connector收到的http请求,它将请求匹配到自己的某个虚拟主机上,并把请求转交给对应的host来处理。默认的虚拟主机是localhost。
- <Engine name="Catalina" defaultHost="localhost">
<Engine name="Catalina" defaultHost="localhost">
d) 虚拟主机host的配置
- <Host name="localhost" appBase="webapps"
- unpackWARs="true" autoDeploy="true"
- xmlValidation="false" xmlNamespaceAware="false">
<Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true" xmlValidation="false" xmlNamespaceAware="false">
appBase表示了该虚拟主机localhost的根目录是webapps/,虚拟主机会将请求匹配到自己的context路径上,并把请求转交给对应的context来处理。
e) Context的配置
- <Context path="/adv" reloadable="false" docBase="E:\workspace\addataextract" />
<Context path="/adv" reloadable="false" docBase="E:\workspace\addataextract" />
一个Context就代表了一个web应用,path表示该web应用的路径,docBase指定了该应用的根目录所在。
② Web.xml 前面说过了一个Context对应于一个Web App,每个Web App是由一个或者多个servlet组成的,而web.xml就是web app的部署配置文件。当一个Web App被初始化的时候,它将用自己的ClassLoader对象载入web.xml中定义的每个servlet类。
它首先载入在$CATALINA_HOME/conf/web.xml中部署的servlet类,然后载入在自己的Web App根目录下的WEB-INF/web.xml中部署的servlet类。
web.xml文件有两部分:servlet类定义和servlet映射定义。每个被载入的servlet类都有一个名字,且被填入该Context的映射表(mapping table)中,和某种URL PATTERN对应。当该Context获得请求时,将查询mapping table,找到被请求的servlet,并执行以获得请求回应。
下面我们来分析一下tomcat的$CATALINA_HOME/conf/web.xml,这个文件是所有web app的共用的部署配置文件。当部署一个web app时,这个文件将首先被读取处理,然后才是web app自己的在WEB-INF目录下的web.xml文件。
- <servlet>
- <servlet-name>default</servlet-name>
- <servlet-class>org.apache.catalina.servlets.DefaultServlet</servlet-class>
- <init-param>
- <param-name>debug</param-name>
- <param-value>0</param-value>
- </init-param>
- <init-param>
- <param-name>listings</param-name>
- <param-value>false</param-value>
- </init-param>
- <load-on-startup>1</load-on-startup>
- </servlet>
- <servlet-mapping>
- <servlet-name>default</servlet-name>
- <url-pattern>/</url-pattern>
- </servlet-mapping>
<servlet> <servlet-name>default</servlet-name> <servlet-class>org.apache.catalina.servlets.DefaultServlet</servlet-class> <init-param> <param-name>debug</param-name> <param-value>0</param-value> </init-param> <init-param> <param-name>listings</param-name> <param-value>false</param-value> </init-param> <load-on-startup>1</load-on-startup> </servlet> <servlet-mapping> <servlet-name>default</servlet-name> <url-pattern>/</url-pattern> </servlet-mapping>
这个servlet是default servlet,也就是说当用户的Http请求无法匹配到任何一个servlet的时候,就执行该servlet。 这里面有个参数交listings,默认是设置为false的,因为tomcat6出于安全问题的考虑,默认是禁止目录浏览。之前版本的tomcat在访问某个目录的时候,例如test,tomcat会把test目录下的所有文件都列出来。但是这样一来的话,这个目录下的文件都变成对外可见的了。因此tomcat6默认是禁止这个功能的,当然,你可以把listings设置为true来开启这个功能。一般来说,在上到生产环境的时候,最好把listings设置为false。
- <servlet>
- <servlet-name>jsp</servlet-name>
- <servlet-class>org.apache.jasper.servlet.JspServlet</servlet-class>
- <init-param>
- <param-name>fork</param-name>
- <param-value>false</param-value>
- </init-param>
- <init-param>
- <param-name>xpoweredBy</param-name>
- <param-value>false</param-value>
- </init-param>
- <load-on-startup>3</load-on-startup>
- </servlet>
- <servlet-mapping>
- <servlet-name>jsp</servlet-name>
- <url-pattern>*.jsp</url-pattern>
- </servlet-mapping>
<servlet> <servlet-name>jsp</servlet-name> <servlet-class>org.apache.jasper.servlet.JspServlet</servlet-class> <init-param> <param-name>fork</param-name> <param-value>false</param-value> </init-param> <init-param> <param-name>xpoweredBy</param-name> <param-value>false</param-value> </init-param> <load-on-startup>3</load-on-startup> </servlet> <servlet-mapping> <servlet-name>jsp</servlet-name> <url-pattern>*.jsp</url-pattern> </servlet-mapping>
这个jsp servlet也是很重要的,表示当请求的是一个jsp页面的时候(即请求.jsp时),将调用该servlet,它是一个jsp编译器,用来将请求的jsp页面编译成servlet再执行。
二 tomcat的启动
对于engine, host, context来说,它们都属于容器,当接收到客户端请求的时候,请求会被传递到容器中,在一个容器中处理完毕之后,会被传递给下一个容器处理。因此,我们可以这样理解tomcat,总的来说,tomcat就是一种自上而下,一个容器里面又嵌套包含了另一个子容器的结构。所以,在tomcat启动的时候,我们也可以想象,它必定要先启动父容器,然后再启动子容器,在启动每一层容器的时候,还会启动容器中的一些相关组件,当所有的容器与组件都安装启动完毕,那么tomcat就启动完毕了。
因此,很容易理解,tomcat 启动的第一步就是进行容器的装配,就是把父容器和子容器拼装起来,并且安装上相关的组件,这很像一个车间装配的过程。
当一切装配齐全,机器已经在各个工人的手中完全组装好了,那么接下来的一步,我们只需要按下开关,机器就可以工作啦。多么方便哪!
1、 一切事情的起点都源于org.apache.catalina.startup.Bootstrap的“引导”。Bootstrap负责对catalina的配置文件路径进行了一番指导,指定了三种类型的classLoader,接下来catalina就可以用这三种类型的classLoader来负责装配容器了。然后Bootstrap用反射机制调用了org.apache.catalina.startup.Catalina的process方法,引导catalina进行启动。
2、 Catalina的工作首先是用digester来装配各个容器与组件(degester是Jakarta子项目Commons下的一个模块,支持基于规则的对任意XML文档的处理,提供了一种将XML与Java对象进行映射的方便方法),这个装配就像我们上面说的那样,就是把server下的service进行安装,然后依次把service下的engine,host,context这些容器以及容器中的各种组件按照父子关系一一拼装。这些配置文件的来源都是Bootstrap之间就已经告知了的。在这里它只负责组装。 接着,catalina会对server进行初始化工作,主要就是把service中配置的connector进行初始化(HTTP与AJP)。 然后调用server的start方法,启动tomcat server。 最后,为server注册一个hook程序,检测当server shutdown的时候,关闭tomcat的各个容器。
3、 进入server的start方法。 启动server的容器的三个lifecycle事件:BEFORE_START_EVENT,START_EVENT,AFTER_START_EVENT。 启动server的子容器service。
4、 进入service的start方法。启动engine与connector。
5、 下面就开始进入engine了。 之前说过,engine, host与context都是容器,它们都继承自Container类。它们既然都是一种container,那么在处理手法上一定又很多类似的地方,因此,tomcat使用了ContainerBase这个类,把它作为engine, host与context的父类,让这些容器都可以通过super.start()方法来达到大部分主要逻辑的复用。
那么,我们首先就来看一下这个ContainerBase中都做了些什么,也就可以知道容器大致都怎么处理请求的。 a) 触发启动前事件(BEFORE_START_EVENT)。 b) 设置标签,表示该容器已启动。 c) 启动容器中的各个组件,如loader, logger, manager, cluster, realm, resources等。 d) 启动当前容器的子容器。 e) 启动当前容器的管道pipeline*。 f) 触发启动中事件(START_EVENT)。 g) 触发启动后事件(AFTER_START_EVENT)。 *:pipeline:当一个容器要把从上一级传递过来的需求转交给子容器的时候,它就会把这个需求放进容器的管道(pipeline)里面去,这个管道里面呢有多个阀门机关(value),而需求在管道里面流动的时候,就会被管道里面的各个阀门拦截下来,只有满足了过关的要求,阀门才会放行。比如管道里面放了两个阀门,第一个阀门叫做“access_allow_vavle”,也就是说需求流过来的时候,它会看这个需求是哪个IP过来的,如果这个IP已经在黑名单里面了,OK,立马拦截,这个需求最远就只能走到这里了,不可能再往下走了!第二个阀门叫做“defaul_access_valve”,它会做例行的检查,如果通过的话,OK,把需求传递给当前容器的子容器。 就是通过这种方式, 需求就在各个容器里面传递,流动, 最后抵达目的地的了。
以上就是ContainerBase中进行的一些处理。尽管大部分内容都是共用的,但每个容器还是有一些自己特别的处理的,这些各个容器特有的任务都会放在调用ContainerBase之前进行处理。在engine中的特别处理包括engine自己的log以及mbean的处理等等。
6、 Host是engine的子容器,所以host也会调用ContainerBase的start()方法。 而host的特殊处理主要就是往pipeline里面安装了一个errorReportValue的阀门。这个errorReportValue的作用主要就是用来检查response的。需求在被Engine传递给Host后, 会继续传递给Context做具体的处理。 这里需求其实就是作为参数传递的Request, Response。所以在context把需求处理完后,通常会改动response。而这个org.apache.catalina.valves.ErrorReportValve的作用就是检察response是否包含错误, 如果有就做相应的处理。
7、 终于到了Context了。Context的启动是从 StandardContext的start()开始的。下面我们一步一步来看StandardContext的start()中都做了些什么。
a) 触发启动前事件(BEFORE_START_EVENT)。 b) 设置web app的具体目录webappResources。 c) 为context指定loader,Loader就是用来指定这个context会用到哪些类啊,哪些jar包啊这些什么的。 d) GetCharsetMapper(),得到字符编码格式,tomcat自己有一个默认的配置文件用来设置默认情况下的字符编码格式,如果用户没有自定义的话,就采用默认的配置,一般为为/org/apache/catalina/util/CharsetMapperDefault.properties。 e) postWorkDirectory (),创建临时文件目录。Tomcat下面有一个work目录,用来存放临时文件。这个步骤就是在那里创建一个目录,一般说来会在%CATALINA_HOME%/work/Standalone\localhost\这个地方生成一个目录。 f) Binding thread(),负责绑定当前线程与context。首先要转换class loader,因为之前需要的是tomcat下的所有class和lib,接下来需要的就是当前context,也就是web app的class和lib了,所以要重新设置当前的的contextClassLoader,同时要记录下旧的class loader。然后就要进行线程的绑定了。
- threadBindings.put(Thread.currentThread(), context);
- threadNameBindings.put(Thread.currentThread(), name);
threadBindings.put(Thread.currentThread(), context); threadNameBindings.put(Thread.currentThread(), name);
threadBindings和threadNameBindings都是HashTable,这两步操作把当前线程与当前的这个context绑定起来。接下来这个线程就作为这个web app的主线程了。 g) 启动当前context的loader。 h) 重置logger并启动它。 i) 若存在子容器,启动子容器,并启动其管道pipeline。 j) 触发START_EVENT事件监听,
- lifecycle.fireLifecycleEvent(START_EVENT, null);
lifecycle.fireLifecycleEvent(START_EVENT, null);
在这个事件监听里面会启动ContextConfig的start()事件,ContextConfig是用来配置web.xml的。比如这个Context有多少Servlet,又有多少Filter,就是在这里给Context装上去的。ContextConfig主要做了这些工作:
- defaultWebConfig(); //每个context要配置一个默认的web.xml,就是omcat/conf/web.xml,这样container servlet才能被加载。
- applicationWebConfig(); //配置web app自己的web.xml
- validateSecurityRoles(); //验证访问角色的安全性。就是web app的部署权限,通常我们会通过访问/admin 或者/manager来进入应用的部署界面,一般用户是admin或者manager才能访问。访问的用户以及可以访问的资源都是可以限制的,这些都可以通过权限验证来实现。
- authenticatorConfig(); //配置自动认证
defaultWebConfig(); //每个context要配置一个默认的web.xml,就是omcat/conf/web.xml,这样container servlet才能被加载。 applicationWebConfig(); //配置web app自己的web.xml validateSecurityRoles(); //验证访问角色的安全性。就是web app的部署权限,通常我们会通过访问/admin 或者/manager来进入应用的部署界面,一般用户是admin或者manager才能访问。访问的用户以及可以访问的资源都是可以限制的,这些都可以通过权限验证来实现。 authenticatorConfig(); //配置自动认证
k) 为context创建welcome files,通常是这三个启动文件:index.html、index.htm、index.jsp,它们就被默认地绑在了这个context上。 l) 触发AFTER_START_EVENT事件。 m) 配置listener。 n) 启动manager。Manager是用来管理session的。对于服务器来说,每个请求传递过来的时候,会在request里面加上一个叫做sessionId的属性,服务器就通过这个sessionId来知道这个请求到底是属于哪一个session的。 o) 启动context的后台主线程。 p) 配置filter。 q) 启动带有<load-on-startup>的Servlet。如<load-on-startup>1</load-on-startup>,启动的顺序从1开始按照数字从小到大,1, 2, 3 ……,最后才是0。 默认情况下,至少会启动如下3个的Servlet: org.apache.catalina.servlets.DefaultServlet 负责处理静态资源的Servlet,例如图片、html、css、js等等。 org.apache.catalina.servlets.InvokerServlet负责处理没有做Servlet Mapping的那些Servlet。 org.apache.jasper.servlet.JspServlet负责处理JSP文件。 r) 标识context已经启动完毕,如果在启动的时候发生错误,则stop server。 s) 注册JMX。registerJMX(); t) 关闭所有JAR,以免在启动的时候打开的文件数量总是很高。
如果文字看不下来的话,可以看看下面的流程图,如果你坚持看完了上面一大段话的话,呃,也可以再看看下面的图。
到这里tomcat就算启动完毕了,我们可以看到它的启动过程是一环套一环的过程,先是父容器,然后是子容器,一层层往下递进。
三 请求处理
在这第三部分里面我们主要看一下tomcat是如何接收客户端请求,并把这个请求一层一层的传递到子容器中,并最后交到应用程序中进行处理的。
首先,我们来了解一下什么叫做NIO和BIO。 在前面的解读tomcat里面,我们已经说到过了线程池。线程池,顾名思义,里面存放了一定数量的线程,这些线程用来处理用户请求。现在我们要讨论的NIO和BIO就是如何分配线程池中的线程来处理用户请求的方式。
BIO(Block IO):阻塞式IO。在tomcat6之前一直都是采用的这种方式。当一个客户端的连接请求到达的时候,ServerSocket.accept负责接收连接,然后会从线程池中取出一个空闲的线程,在该线程读取InputStream并解析HTTP协议,然后把输入流中的内容封装成Request和Response,在线程中执行这个请求的Servlet ,最后把Response的内容发送到客户端连接并关闭本次连接。这就完成了一个客户端的请求过程。我们要注意的是在阻塞式IO中,tomcat是直接从线程池中取出一个线程来处理客户端请求的,那么如果这些处理线程在执行网络操作期间发生了阻塞的话,那么线程将一直阻塞,导致新的连接一直无法分配到空闲线程,得不到响应。
NIO(Non-blocking IO):tomcat中的非阻塞式IO与阻塞式的不同,它采用了一个主线程来读取InputStream。也就是说当一个客户端请求到达的时候,这个主线程会负责从网络中读取字节流,把读入的字节流放入channel中。然后这个主线程就会到线程池中去找有没有空闲的线程,如果找到了,那么就会由空闲线程来负责从channel中取出字节,然后解析Http,转换成request和response,进行处理。当处理线程把要返回给客户端的内容放在Response之后,处理线程就可以把处理结束的字节流也放入channel中,最后主线程会给这个channel加个标识,表示现在需要操作系统去进行io操作,要把这个channel中的内容返回给客户端。这样的话,线程池中的处理线程的任务就集中在如何处理用户请求上了,而把与网络有交互的操作都交给主线程去处理。
对于这个非阻塞式IO,anne我想了一个很有趣的比喻,就好像去饭店吃饭点菜一样。餐馆的接待员就好像我们的操作系统,客人来了,他要负责记下客人的点菜,然后传达给厨房,厨房里面有好几位烧菜厨师(处理线程),主厨(主线程)呢比较懒,不下厨,只负责分配厨师的工作。现在来了一个客人,跟接待员说要吃宫宝鸡丁,然后接待员就写了张纸条,上面写了1号桌客人要点宫宝鸡丁,从厨房柜台上的一摞盘子里面拿了一个空的,把点菜单放在盘子里面。然后主厨就时刻关注这这些盘子,看到有盘子里面有点菜单的,就从厨房里面喊一个空闲的厨子说,你来把这菜给烧一下,这个厨子就从这个盘子里面拿出点菜单去烧菜了,好了这下这个盘子又空了,如果这时候还有客人来,那么接待员还可以把点菜单放到这个盘子里面去。等厨师烧好了菜,他就从柜台上找一个空盘子,把菜盛在里面,贴上纸条说这个是1号桌客人点的宫宝鸡丁。然后主厨看看,嗯,烧的还不错,可以上菜了,就在盘子上贴个字条说这盘菜烧好了,上菜去吧。最后接待员就来了,他一直在这候着呢,看到终于有菜可以上了,赶紧端去。嗯,自我感觉挺形象的,你们说呢?
因此,我们可以分析出tomcat中的阻塞式IO与非阻塞式IO的主要区别就是这个主线程。Tomcat6之前的版本都是只采用的阻塞式IO的方式,服务器接收了客户端连接之后,马上分配处理线程来处理这个连接;tomcat6中既提供了阻塞式的IO,也提供了非阻塞式IO处理方式,非阻塞式IO把接收连接的工作都交给主线程处理,处理线程只关心具体的如何处理请求。
好了,我们现在知道了tomcat是采用非阻塞式IO来分配请求的了。那么接下来我们就可以从发出一个请求开始看看tomcat是怎么把它传递到我们自己的应用程序中的。
程序员最爱看类图了,所以anne画了个类图,我们来照着类图,一个一个类来看。
我们首先从NioEndPoint开始,这个类是实际处理tcp连接的类,它里面包括一个操作线程池,socket接收线程(acceptorThread),socket轮询线程(pollerThread)。
首先我们看到的是start()方法,在这个方法里面我们可以看到启动了线程池,acceptorThread和pollerThread。然后,在这个类中还定义了一些子类,包括SocketProcessor,Acceptor,Poller,Worker,NioBufferHandler等等。SocketProcessor,Acceptor,Poller和Worker都实现了Runnable接口。 我想还是按照接收请求的调用顺序来讲会比较清楚,所以我们从Acceptor开始。
1、Acceptor负责接收socket,一旦得到一个tcp连接,它就会尝试去从nioChannels中去取出一个空闲的nioChannel,然后把这个连接的socket交给它,接着它会告诉轮询线程poller,我这里有个channel已经准备好了,你注意着点,可能不久之后就要有数据过来啦。下面的事情它就不管了,接着等待下一个tcp连接的到来。 我们可以看一下它是怎么把socket交给channel的:
- protected boolean setSocketOptions(SocketChannel socket) {
- try {
- ... //ignore
- //从nioChannels中取出一个channel
- NioChannel channel = nioChannels.poll();
- //若没有可用的channel,根据不同情况新建一个channel
- if ( channel == null ) {
- if (sslContext != null) {
- ...//ignore
- channel = new SecureNioChannel(...);
- } else {
- ...// normal tcp setup
- channel = new NioChannel(...);
- }
- } else {
- channel.setIOChannel(socket);
- ...//根据channel的类型做相应reset
- }
- getPoller0().register(channel); // 把channel交给poller
- } catch (Throwable t) {
- try {
- return false; // 返回false,关闭socket
- }
- return true;
- }
protected boolean setSocketOptions(SocketChannel socket) { try { ... //ignore //从nioChannels中取出一个channel NioChannel channel = nioChannels.poll(); //若没有可用的channel,根据不同情况新建一个channel if ( channel == null ) { if (sslContext != null) { ...//ignore channel = new SecureNioChannel(...); } else { ...// normal tcp setup channel = new NioChannel(...); } } else { channel.setIOChannel(socket); ...//根据channel的类型做相应reset } getPoller0().register(channel); // 把channel交给poller } catch (Throwable t) { try { return false; // 返回false,关闭socket } return true; }
要说明的是,Acceptor这个类在BIO的endpoint类中也是存在的。对于BIO来说acceptor就是用来接收请求,然后给这个请求分配一个空闲的线程来处理它,所以是起到了一个连接请求与处理线程的作用。现在在NIO中,我们可以看到Acceptor.run()里面是把processSocket(socket);给注释掉了(processSocket这个方法就是分配线程来处理socket的方法,这个anne打算在后面讲)。
2、Poller这个类其实就是我们在前面说到的nio的主线程。它里面也有一个run()方法,在这里我们就会轮询channel啦。看下面的代码:
- Iterator iterator = keyCount > 0 ? selector.selectedKeys().iterator() : null;
- while (iterator != null && iterator.hasNext()) {
- SelectionKey sk = (SelectionKey) iterator.next();
- KeyAttachment attachment = (KeyAttachment)sk.attachment();
- attachment.access();
- iterator.remove();
- processKey(sk, attachment);
- }
Iterator iterator = keyCount > 0 ? selector.selectedKeys().iterator() : null; while (iterator != null && iterator.hasNext()) { SelectionKey sk = (SelectionKey) iterator.next(); KeyAttachment attachment = (KeyAttachment)sk.attachment(); attachment.access(); iterator.remove(); processKey(sk, attachment); }
我们可以看到,程序遍历了所有selectedKeys,这个SelectionKey就是一种可以用来读取channel的钥匙。这个KeyAttachment又是个什么类型的对象呢?其实它记录了包括channel信息在内的又与这个channel息息相关的一些附加信息。MS很长的一句话,这么说吧,它里面有channel对象,还有lastAccess(最近一次访问时间),error(错误信息),sendfileData(发送的文件数据)等等。然后在processKey这个方法里面我们就可以把channel里面的字节流交给处理线程去处理了。 然后我们来看一下这个processKey方法:
- protected boolean processKey(SelectionKey sk, KeyAttachment attachment) {
- boolean result = true;
- try {
- if ( close ) {
- cancelledKey(sk, SocketStatus.STOP, false);
- } else if ( sk.isValid() && attachment != null ) {
- attachment.access();
- sk.attach(attachment);
- NioChannel channel = attachment.getChannel();
- ① if (sk.isReadable() || sk.isWritable() ) {
- ② if ( attachment.getSendfileData() != null ) {
- processSendfile(sk,attachment,true);
- } else if ( attachment.getComet() ) {
- if ( isWorkerAvailable() ) {
- reg(sk, attachment, 0);
- if (sk.isReadable()) {
- if (!processSocket(channel, SocketStatus.OPEN))
- processSocket(channel, SocketStatus.DISCONNECT);
- } else {
- if (!processSocket(channel, SocketStatus.OPEN))
- processSocket(channel, SocketStatus.DISCONNECT);
- }
- } else {
- result = false;
- }
- } else {
- if ( isWorkerAvailable() ) {
- unreg(sk, attachment,sk.readyOps());
- ③ boolean close = (!processSocket(channel));
- if (close) {
- cancelledKey(sk,SocketStatus.DISCONNECT,false);
- }
- } else {
- result = false;
- }
- } }
- }
- } else {
- //invalid key
- cancelledKey(sk, SocketStatus.ERROR,false);
- }
- } catch ( CancelledKeyException ckx ) {
- cancelledKey(sk, SocketStatus.ERROR,false);
- } catch (Throwable t) {
- log.error("",t);
- }
- return result;
- }
protected boolean processKey(SelectionKey sk, KeyAttachment attachment) { boolean result = true; try { if ( close ) { cancelledKey(sk, SocketStatus.STOP, false); } else if ( sk.isValid() && attachment != null ) { attachment.access(); sk.attach(attachment); NioChannel channel = attachment.getChannel(); ① if (sk.isReadable() || sk.isWritable() ) { ② if ( attachment.getSendfileData() != null ) { processSendfile(sk,attachment,true); } else if ( attachment.getComet() ) { if ( isWorkerAvailable() ) { reg(sk, attachment, 0); if (sk.isReadable()) { if (!processSocket(channel, SocketStatus.OPEN)) processSocket(channel, SocketStatus.DISCONNECT); } else { if (!processSocket(channel, SocketStatus.OPEN)) processSocket(channel, SocketStatus.DISCONNECT); } } else { result = false; } } else { if ( isWorkerAvailable() ) { unreg(sk, attachment,sk.readyOps()); ③ boolean close = (!processSocket(channel)); if (close) { cancelledKey(sk,SocketStatus.DISCONNECT,false); } } else { result = false; } } } } } else { //invalid key cancelledKey(sk, SocketStatus.ERROR,false); } } catch ( CancelledKeyException ckx ) { cancelledKey(sk, SocketStatus.ERROR,false); } catch (Throwable t) { log.error("",t); } return result; }
首先是判断一下这个selection key是否可用,没有超时,然后从sk中取出channel备用。然后看一下这个sk的状态是否是可读的,或者可写的,代码①处。代码②处是返回阶段,要往客户端写数据时候的路径,程序会判断是否有要发送的数据,这部分我们后面再看,先往下看request进来的情况。然后我们就可以在下面看到开始进行真正的处理socket的工作了,代码③处,进入processSocket()方法了。
- protected boolean processSocket(NioChannel socket, SocketStatus status, boolean dispatch) {
- try {
- KeyAttachment attachment = (KeyAttachment)socket.getAttachment(false);
- attachment.setCometNotify(false);
- if (executor == null) {
- ④ getWorkerThread().assign(socket, status);
- } else {
- SocketProcessor sc = processorCache.poll();
- if ( sc == null ) sc = new SocketProcessor(socket,status);
- else sc.reset(socket,status);
- if ( dispatch ) executor.execute(sc);
- else sc.run();
- }
- } catch (Throwable t) {
- return false;
- }
- return true;
protected boolean processSocket(NioChannel socket, SocketStatus status, boolean dispatch) { try { KeyAttachment attachment = (KeyAttachment)socket.getAttachment(false); attachment.setCometNotify(false); if (executor == null) { ④ getWorkerThread().assign(socket, status); } else { SocketProcessor sc = processorCache.poll(); if ( sc == null ) sc = new SocketProcessor(socket,status); else sc.reset(socket,status); if ( dispatch ) executor.execute(sc); else sc.run(); } } catch (Throwable t) { return false; } return true; }
从④处可以看到明显是取了线程池中的一个线程来操作这个channel,也就是说在这个方法里面我们就开始进入线程池了。那么executor呢?executor可以算是一个配置项,如果使用了executor,那么线程池就使用java自带的线程池,如果不使用executor的话,就使用tomcat的线程池WorkerStack,这个WrokerStack我在后面有专门写它,现在先跳过。我们可以看到在start()方法里面,是这样写的:
- if (getUseExecutor()) {
- if ( executor == null ) {
- executor = new ThreadPoolExecutor(...);
- }
- } else if ( executor == null ) {
- workers = new WorkerStack(maxThreads);
- }
if (getUseExecutor()) { if ( executor == null ) { executor = new ThreadPoolExecutor(...); } } else if ( executor == null ) { workers = new WorkerStack(maxThreads); }
好了,现在回到processSocket(),我们先来看有executor的情况,就是使用java自己的线程池。首先从processorCache中取出一个线程socketProcessor,然后把channel交给这个线程,启动线程的run方法。于是我们终于脱离主线程,进入了SocketProcessor的run方法啦!
3、SocketProcessor:这个类是真正处理用户请求的类。 我们只看最重要的一步,如何处理channel:
- boolean closed = (status==null)?(handler.process(socket)==Handler.SocketState.CLOSED) : (handler.event(socket,status)==Handler.SocketState.CLOSED);
boolean closed = (status==null)?(handler.process(socket)==Handler.SocketState.CLOSED) : (handler.event(socket,status)==Handler.SocketState.CLOSED);
这里的handler是Http11NioProtocal里面的一个子类Http11ConnectionHandler。在这里对于这个socket有没有状态是分开处理的,还记得前面的processKey()方法里面,有好几处的if-else,有三个分支处都调用了processSocket(),有的是有status的,有的只有一个socket传进去,分别就在此处。其实大体都差不多,所以,我们就着重来看看handler.process()吧。
不管怎么样,我们首先都要得到一个processor对象,这个processor也是从一个可回收的数组中取出来的,然后主要的是调用processor的process方法。
- SocketState state = processor.process(socket);
SocketState state = processor.process(socket);
在Http11NioProcessor的process方法就是用来从channel里面把字节流读出来,然后把它转换成容器需要的request和response对象(通过inputBuffer的parseRequestLine, parseRequest等方法来实现这个功能的)。然后,封装好了request,并且也创建好了response之后,会用adapter.service(request, response);来把request和response传递进context。
- public SocketState process(NioChannel socket){
- if (!error) {
- try {
- adapter.service(request, response);
- ...
- }
- }
- }
public SocketState process(NioChannel socket){ if (!error) { try { adapter.service(request, response); ... } } }
这个service方法中我们只关注下面一段。
- req.getRequestProcessor().setWorkerThreadName(Thread.currentThread().getName());
- if (postParseRequest(req, request, res, response)) {
- connector.getContainer().getPipeline().getFirst().invoke(request, response);
req.getRequestProcessor().setWorkerThreadName(Thread.currentThread().getName()); if (postParseRequest(req, request, res, response)) { connector.getContainer().getPipeline().getFirst().invoke(request, response); }
好了,我们看到,第一步就是给这个request设置处理它的线程。第二步,在这个里面会对request进行一些处理,譬如说sessionId就是在这里处理的,通过parstSessionId把sessionId设置到request里面。第三步,就开始调用container了,接下来的过程anne我打算后面慢慢分解。
4、在NioEndpoint类中还有个子类叫做WorkerStack,这是一个存放Worker的堆栈。 前面在讲到调用processSocket方法的时候,说从这里开始要取线程池中的线程了,如果使用了executor,那么线程池就使用java自带的线程池,如果不使用executor的话,就使用tomcat的线程池WorkerStack。
- public class WorkerStack {
- protected Worker[] workers = null;
- protected int end = 0;
- public WorkerStack(int size) {
- workers = new Worker[size];
- }
- public void push(Worker worker) {
- workers[end++] = worker;
- }
- public Worker pop() {
- if (end > 0) {
- return workers[--end];
- }
- return null;
- }
- ...
- }
public class WorkerStack { protected Worker[] workers = null; protected int end = 0; public WorkerStack(int size) { workers = new Worker[size]; } public void push(Worker worker) { workers[end++] = worker; } public Worker pop() { if (end > 0) { return workers[--end]; } return null; } ... }
Workers[]当然不用说,是一个Worker对象的数组,end则是数组中Worker的个数。这都非常好理解。现在的问题就是Worker。Worker是用来处理socket的工具。 首先我们要通过getWorkerThread()来得到一个Worker对象,怎么的到呢,先看看workerStack里面有没有空闲的Worker啊,有的话最好,直接就拿出来了,没有的话,就新建一个呗,万一这么倒霉,线程数已经到顶了,不能新建了,那就请先稍微等等,等到有了空闲的worker,就唤醒getWorkerThread()方法。代码如下:
- protected Worker getWorkerThread() {
- Worker workerThread = createWorkerThread();
- while (workerThread == null) {
- try {
- synchronized (workers) {
- workerThread = createWorkerThread();
- if ( workerThread == null ) workers.wait();
- }
- } catch (InterruptedException e) {
- // Ignore
- }
- if ( workerThread == null ) workerThread = createWorkerThread();
- }
- return workerThread;
- }
protected Worker getWorkerThread() { Worker workerThread = createWorkerThread(); while (workerThread == null) { try { synchronized (workers) { workerThread = createWorkerThread(); if ( workerThread == null ) workers.wait(); } } catch (InterruptedException e) { // Ignore } if ( workerThread == null ) workerThread = createWorkerThread(); } return workerThread; }
顺便看一下如何唤醒等待worker的线程。
- protected void recycleWorkerThread(Worker workerThread) {
- synchronized (workers) {
- workers.push(workerThread);
- curThreadsBusy--;
- workers.notify();
- }
- }
protected void recycleWorkerThread(Worker workerThread) { synchronized (workers) { workers.push(workerThread); curThreadsBusy--; workers.notify(); } }
好了,到这里客户端请求的接收就讲完了,当然,anne没有忘记这个过程只到进入container,但大体上我们已经知道inputStream已经变成request了,接下来就要经过engine, host, context的洗礼,最后目标就是servlet。 呃,我还画了一个时序图,虽然比较简陋,但图文并茂的话看起来比较省力。
现在我们脑补一下,假设这个请求servlet已经处理结束了,现在我们要把这个response返回给客户端了!
之前在讲到Http11NioProcessor的process方法的时候,我们知道就是在process里面调用了adapter.service(),这个方法很明显是request进入容器的入口,那么出口是不是也在这里呢,我们在process方法里面往下找找,就可以看到:
- if (sendfileData != null && !error) {
- KeyAttachment ka = (KeyAttachment)socket.getAttachment(false);
- ka.setSendfileData(sendfileData);
- sendfileData.keepAlive = keepAlive;
- SelectionKey key = socket.getIOChannel().keyFor(socket.getPoller().getSelector());
- openSocket = socket.getPoller().processSendfile(key,ka,true);
- break;
if (sendfileData != null && !error) { KeyAttachment ka = (KeyAttachment)socket.getAttachment(false); ka.setSendfileData(sendfileData); sendfileData.keepAlive = keepAlive; SelectionKey key = socket.getIOChannel().keyFor(socket.getPoller().getSelector()); openSocket = socket.getPoller().processSendfile(key,ka,true); break; }
最后的break我们不管,关键是我们看到从key attachement中取出了senfileData,然后调用了Poller的processSendfile()。我们已经知道了,Poller就是NIO中的主线程,现在又跑到主线程中去了,它要做什么呢?
- public boolean processSendfile(SelectionKey sk, KeyAttachment attachment, boolean reg) {
- try {
- SendfileData sd = attachment.getSendfileData();
- .//ignore
- if ( sd.length <= 0 ) {
- attachment.setSendfileData(null);
- if ( sd.keepAlive ) {
- ① if (reg) reg(sk,attachment,SelectionKey.OP_READ);
- } else {
- cancelledKey(sk,SocketStatus.STOP,false);
- }
- } else if ( attachment.interestOps() == 0 && reg ) {
- ② reg(sk,attachment,SelectionKey.OP_WRITE);
- }
- }catch ( IOException x ) {
- cancelledKey(sk,SocketStatus.ERROR,false);
- return false;
- }catch ( Throwable t ) {
- cancelledKey(sk, SocketStatus.ERROR, false);
- return false;
- }
- return true;
- }
public boolean processSendfile(SelectionKey sk, KeyAttachment attachment, boolean reg) { try { SendfileData sd = attachment.getSendfileData(); ...//ignore if ( sd.length <= 0 ) { attachment.setSendfileData(null); if ( sd.keepAlive ) { ① if (reg) reg(sk,attachment,SelectionKey.OP_READ); } else { cancelledKey(sk,SocketStatus.STOP,false); } } else if ( attachment.interestOps() == 0 && reg ) { ② reg(sk,attachment,SelectionKey.OP_WRITE); } }catch ( IOException x ) { cancelledKey(sk,SocketStatus.ERROR,false); return false; }catch ( Throwable t ) { cancelledKey(sk, SocketStatus.ERROR, false); return false; } return true; }
我们可以看到在代码①处和②处(不同的分支),都又调用reg方法,这个意思是告诉操作系统要对channel进行读(写)操作了。
关于对channel的读写操作,NIO 有一个主要的类Selector,这个类似一个观察者,只要我们把需要观察的socket channel告诉Selector,那么当有我们感兴趣的事件发生时,selector就会通知我们,并且传回一组SelectionKey,通过读取这些selection key,我们就可以的到刚才注册过的channel,进而得到channel中的字节流了。Selector的内部原理实际上是一直在对注册的channel进行轮询访问,一旦轮询到一个channel有我们感兴趣的事情发生(比如数据来了),selector就会报告返回这个channel的selection key,让我们通过这个selection key来读取对应channel的内容。
我们已经知道了selection key是对应channel的一把钥匙,之间的代码中我们有看到selection key有isReadalbe和isWriteable两种状态,这个状态是针对主线程(也就是poller)来说的,它告诉主线程现在这个channel是可读的,或者可写的。而出现在代码①处和②处这里的OP_READ和OP_WRITE则是用来告诉给操作系统要做的操作。SelectionKey中的operation有四种:OP_READ, OP_WRITE, OP_CONNECT, OP_ACCEPT。这些状态是由主线程告诉给操作系统要进行操作了。例如reg(sk,attachment,SelectionKey.OP_READ),这个意思就是告诉操作系统要去socket读取数据了,把读入的数据放入到channel中;reg(sk,attachment,SelectionKey.OP_WRITE),就是告诉操作系统现在channel中的数据都已经准备好了,现在可以往客户端写了;同理,OP_CONNECT和OP_ACCEPT分别表示结束连接和接受连接。
- public static final int OP_READ = 1 << 0;
- public static final int OP_WRITE = 1 << 2;
- public static final int OP_CONNECT = 1 << 3;
- public static final int OP_ACCEPT = 1 << 4;
- public final boolean isReadable() {
- return (readyOps() & OP_READ) != 0;
- }
- public final boolean isWritable() {
- return (readyOps() & OP_WRITE) != 0;
- }
public static final int OP_READ = 1 << 0; public static final int OP_WRITE = 1 << 2; public static final int OP_CONNECT = 1 << 3; public static final int OP_ACCEPT = 1 << 4; public final boolean isReadable() { return (readyOps() & OP_READ) != 0; } public final boolean isWritable() { return (readyOps() & OP_WRITE) != 0; }
上面的代码是从SelectionKey类中节选的,我们可以看到OP_READ, OP_WRITE, OP_CONNECT, OP_ACCEPT与isReadable()和isWritable()有着密切的联系。从四个操作的定义我们不难看出,ms这四个操作分别代表了一个字节中的四个位置,一个字节中有8个bit,00000001代表read,00000100代表write,00001000代表connect,00010000代表accept。 拿read来举例,假如这时候我们打算让某个channel去读取客户端数据,那么我们就给这个channel注册OP_READ事件,reg(sk,attachment,SelectionKey.OP_READ)。
- protected void reg(SelectionKey sk, KeyAttachment attachment, int intops) {
- sk.interestOps(intops);
- attachment.interestOps(intops);
- }
protected void reg(SelectionKey sk, KeyAttachment attachment, int intops) { sk.interestOps(intops); attachment.interestOps(intops); }
现在这个channel的interestOps就是00000001。 readyOps()表示的是这个channel当前准备好的状态。假如操作系统还没有给这个channel进行读操作,那么readyOps()当然在代表read的那一位是0了,假如操作系统已经把这个channel中填充了客户端来的数据了,那么就把read这位置为1,这个时候readyOps()就变成了00000001了,那么(readyOps() & OP_READ)就=1啦,表示这个channel现在是isReadable的,所以接下来主线程就可以从这个channel中读取数据了。 我们可以看一下下面的图示。
现在我们从connector.getContainer().getPipeline().getFirst().invoke(request, response)开始进入容器...
前面说到容器的时候,anne一直都只有说三个容器,engine, host, context。其实在context之下,还有一个容器,叫做wrapper,每个wapper包含了一个servlet,因此前文没有接触到servlet的时候,就暂时省略了。好了,现在我们知道了有这四个级别的容器。这四个容器素由上至下逐渐细分,形成树状结构,构成了tomcat容器结构的主体,它们都位于org.apache.catalina包内。
之前在第二部分tomcat的启动的时候,我们就看到了pipeline,pipeline是一种上级容器和下级容器进行沟通的管道,当上级容器种的request和response要被传递到下一个容器中去时,就必须通过这个管道,而value就像管道中的一个个阀门一样,给传递的request和response把把关,只有过了所有的阀门,才能被正确的传递到下一级容器中去。Tomcat中的pipeline/valve是标准的责任链模式,每个级别的容器中pipeline下都有配置value,每种类型的value专门负责做一项工作,比如验证Request的有效性、写日志等等。请求先到达第一个value,value会对其做一些工作,当工作做完后,将请求传递给下一个value。每个pipeline的最后都会有一个BasicValue(比如Engine的StandardEngineValue、Host的StanadrdHostValue),它负责寻找下一级容器的pipeline,并且将请求传递给下一级容器的pipeline中的value,这样一直传递下去直到真正的servlet。
在tomcat中,这个责任链真是最最标准,最最基础的责任链了,我们来看一下StandardPipeline中是怎样为pipeline添加value的:
- public void addValve(Valve valve) {
- if (valve instanceof Contained)
- ((Contained) valve).setContainer(this.container);
- ...// Start the new component if necessary
- // Add this Valve to the set associated with this Pipeline
- if (first == null) {
- first = valve;
- valve.setNext(basic);
- } else {
- Valve current = first;
- while (current != null) {
- if (current.getNext() == basic) {
- current.setNext(valve);
- valve.setNext(basic);
- break;
- }
- current = current.getNext();
- }
public void addValve(Valve valve) { if (valve instanceof Contained) ((Contained) valve).setContainer(this.container); ...// Start the new component if necessary // Add this Valve to the set associated with this Pipeline ① if (first == null) { first = valve; valve.setNext(basic); } else { Valve current = first; while (current != null) { if (current.getNext() == basic) { current.setNext(valve); valve.setNext(basic); break; } current = current.getNext(); } } }
First(代码①处)记录了这个pipeline关联着的第一个value,basic则是pipeline关联的最后一个value,执行完basic,就进入到下一级的容器中去了。 从上面的代码,我们可以看到,pipeline用了一种最基本的方法来维持这个value的链条,每个value都保持了一个下个value的引用。于是,我们就看到connector.getContainer().getPipeline().getFirst()就得到了engine中的第一个value。为什么呢?因为connector.getContainer()得到的是connector父节点(也就是service)中的engine容器,进而getPipeline()得到engine的pipeline,getFirst()得到engine的pipeline中的第一个value。
好了,下面我们来看看具体进入到了value,都做了些什么,我们来看一个AccessLogValue,很明显,是一个用来写日志的value。
- public void invoke(Request request, Response response) throws IOException, ServletException {
- if (started && getEnabled()) {
- long t1 = System.currentTimeMillis();
- getNext().invoke(request, response);
- long t2 = System.currentTimeMillis();
- long time = t2 - t1;
- StringBuffer result = new StringBuffer();
- ... //add log info into result
- log(result.toString());
- } else
- getNext().invoke(request, response);
- }
public void invoke(Request request, Response response) throws IOException, ServletException { if (started && getEnabled()) { long t1 = System.currentTimeMillis(); ② getNext().invoke(request, response); long t2 = System.currentTimeMillis(); long time = t2 - t1; StringBuffer result = new StringBuffer(); ... //add log info into result log(result.toString()); } else getNext().invoke(request, response); }
OK,很明显,value是通过getNext()方法来得到下一个责任链上的value的(代码②处)。那么当这个责任链到头了,进入到了最后一个value的话是怎么处理的呢?前面说了,每个容器的pipeline的责任链的末端都会有一个特殊的value,Engine的StandardEngineValue、Host的StanadrdHostValue,Context的StanadrdContextValue,Wrapper的StanadrdWrapperValue,这些叫做basicValue,对于容器来说,这些basicValue是一定会有的。我们就看一个StandardEngineValue:
- public final void invoke(Request request, Response response)
- throws IOException, ServletException {
- // Select the Host to be used for this Request
- Host host = request.getHost();
- if (host == null) {
- response.sendError
- (HttpServletResponse.SC_BAD_REQUEST,
- sm.getString("standardEngine.noHost",
- request.getServerName()));
- return;
- }
- // Ask this Host to process this request
- ③ host.getPipeline().getFirst().invoke(request, response);
- }
public final void invoke(Request request, Response response) throws IOException, ServletException { // Select the Host to be used for this Request Host host = request.getHost(); if (host == null) { response.sendError (HttpServletResponse.SC_BAD_REQUEST, sm.getString("standardEngine.noHost", request.getServerName())); return; } // Ask this Host to process this request ③ host.getPipeline().getFirst().invoke(request, response); }
我们可以看到在basicValue中得到了下一级容器,并且调用了下级容器的pipeline中的first value(代码③处)。对于StanadrdHostValue,StanadrdContextValue和StanadrdWrapperValue来说,也都是类似的。BasicValue放在org.apache.catalina.core下,而其他的value都放在org.apache.catalina.value下面。
Ok,大家继续脑补一下,现在已经进入到StanadrdWrapperValue了。那根据我们对tomcat的了解下面应该做什么了呢?对了,接下来我们就要穿越过层层filter,进入servlet了。 我们看一下StanadrdWrapperValuede的invoke方法,为了看起来方便一点,anne就大刀阔斧的只截取了一点点我们需要关注的内容。
- public final void invoke(Request request, Response response)
- throws IOException, ServletException {
- ...
- servlet = wrapper.allocate();
- // 下面开始创建filter链啦
- ApplicationFilterFactory factory =
- ApplicationFilterFactory.getInstance();
- ApplicationFilterChain filterChain =
- factory.createFilterChain(request, wrapper, servlet);
- ...
- // 调用filter链
- filterChain.doFilter(request.getRequest(),response.getResponse());
- if (servlet != null) {
- wrapper.deallocate(servlet);
- }
- }
public final void invoke(Request request, Response response) throws IOException, ServletException { ... ④ servlet = wrapper.allocate(); // 下面开始创建filter链啦 ⑤ ApplicationFilterFactory factory = ApplicationFilterFactory.getInstance(); ApplicationFilterChain filterChain = factory.createFilterChain(request, wrapper, servlet); ... // 调用filter链 filterChain.doFilter(request.getRequest(),response.getResponse()); if (servlet != null) { wrapper.deallocate(servlet); } }
因为一个wrapper是对应与一个servlet的,所以wrapper.allocate()就是得到它负责封装的那个servlet(代码④处)。 下面在代码⑤处,我们就要来创建filter chain了,anne照样把createFilterChain中的方法稍微提取了一下:
- public ApplicationFilterChain createFilterChain
- (ServletRequest request, Wrapper wrapper, Servlet servlet) {
- ApplicationFilterChain filterChain = new ApplicationFilterChain();
- filterChain.setServlet(servlet);
- // 得到context的filter mapping
- StandardContext context = (StandardContext) wrapper.getParent();
- FilterMap filterMaps[] = context.findFilterMaps();
- // 遍历filterMaps,如果有符合这个servlet的filter就把它加到filter chain中
- for (int i = 0; i < filterMaps.length; i++) {
- if (!matchDispatcher(filterMaps[i] ,dispatcher)) {
- continue;
- }
- if (!matchFiltersURL(filterMaps[i], requestPath))
- continue;
- ApplicationFilterConfig filterConfig = (ApplicationFilterConfig)
- context.findFilterConfig(filterMaps[i].getFilterName());
- if (filterConfig == null) {
- continue;
- }
- filterChain.addFilter(filterConfig);
- }
- return (filterChain);
- }
public ApplicationFilterChain createFilterChain (ServletRequest request, Wrapper wrapper, Servlet servlet) { ApplicationFilterChain filterChain = new ApplicationFilterChain(); filterChain.setServlet(servlet); // 得到context的filter mapping StandardContext context = (StandardContext) wrapper.getParent(); FilterMap filterMaps[] = context.findFilterMaps(); // 遍历filterMaps,如果有符合这个servlet的filter就把它加到filter chain中 for (int i = 0; i < filterMaps.length; i++) { if (!matchDispatcher(filterMaps[i] ,dispatcher)) { continue; } if (!matchFiltersURL(filterMaps[i], requestPath)) continue; ApplicationFilterConfig filterConfig = (ApplicationFilterConfig) context.findFilterConfig(filterMaps[i].getFilterName()); if (filterConfig == null) { continue; } filterChain.addFilter(filterConfig); } return (filterChain); }
我们都知道filter chain也是采用的责任链模式,前面我们说到pipeline中的value也是采用的责任链模式,每个value都持有了下一个value的引用。我们可以看看ahuaxuan的《请问责任链真的是一种设计模式吗》这篇文章(http://ahuaxuan.iteye.com/blog/105825),这里面谈到了三种责任链的实现方式,filter chain就是这第三种潇洒版责任链。 前面pipeline的value链是通过引用的方式来形成一条隐形的链条,而这里,filterChain是真是存在的。我们只需要把这个链条上面的一个一个关节通过filterChain.addFilter()装上即可。这个filterChain中的每个关节都是一个FilterConfig对象,这个对象中包含了filter,context,initParameter等等。
链条组装完毕! 启动filterChain.doFilter()! doFilter方法主要调用了internalDoFilter()。
- public void doFilter(ServletRequest request, ServletResponse response)
- throws IOException, ServletException {
- ...
- internalDoFilter(request,response);
- }
- private void internalDoFilter(ServletRequest request,
- ServletResponse response)
- throws IOException, ServletException {
- ⑥ if (pos < n) {
- ApplicationFilterConfig filterConfig = filters[pos++];
- Filter filter = null;
- filter = filterConfig.getFilter();
- ...
- filter.doFilter(request, response, this);
- }
- ⑦ if ((request instanceof HttpServletRequest) &&
- (response instanceof HttpServletResponse)) {
- servlet.service((HttpServletRequest) request,
- (HttpServletResponse) response);
- }
- } else {
- servlet.service(request, response);
- }
- }
public void doFilter(ServletRequest request, ServletResponse response) throws IOException, ServletException { ... internalDoFilter(request,response); } private void internalDoFilter(ServletRequest request, ServletResponse response) throws IOException, ServletException { ⑥ if (pos < n) { ApplicationFilterConfig filterConfig = filters[pos++]; Filter filter = null; filter = filterConfig.getFilter(); ... filter.doFilter(request, response, this); } ⑦ if ((request instanceof HttpServletRequest) && (response instanceof HttpServletResponse)) { servlet.service((HttpServletRequest) request, (HttpServletResponse) response); } } else { servlet.service(request, response); } }
代码⑥处的pos是filter chain上的一个标识位,表示现在执行的是哪一个filter。然后调用了filter的doFilter方法。我们来看一个例子,一个用来记录执行时间的filter。
- public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
- rows IOException, ServletException {
- if (attribute != null)
- request.setAttribute(attribute, this);
- long startTime = System.currentTimeMillis();
- ⑧ chain.doFilter(request, response);
- long stopTime = System.currentTimeMillis();
- filterConfig.getServletContext().log
- (this.toString() + ": " + (stopTime - startTime) +
- " milliseconds");
- }
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { if (attribute != null) request.setAttribute(attribute, this); long startTime = System.currentTimeMillis(); ⑧ chain.doFilter(request, response); long stopTime = System.currentTimeMillis(); filterConfig.getServletContext().log (this.toString() + ": " + (stopTime - startTime) + " milliseconds"); }
首先把当前正在执行的这个filter作为一个attribute放到request中去,接下来我们可以看到在两个time之间,调用了chain.doFilter()(代码⑧处),Chain就是filter chain。这下又要回到internalDoFilter,pos又加了1,就变成执行filterChain的下一个filter了。 如果这个filter chain已经到头了(pos=n),那就进入代码⑦处,就表示request和response已经突破filter的重重阻拦,可以进入servlet了。因此,我们就可以调用wrapper内的servlet的service()方法了。自此进入servlet。这下我们知道了filter原来是这样执行的,它是一层包着一层,一直不断的向内层进发,当进入到最内层,就是servlet了。
好了,我们现在终于进入servlet的service方法了。
- protected void service(HttpServletRequest req, HttpServletResponse resp)
- throws ServletException, IOException {
- String method = req.getMethod();
- if (method.equals(METHOD_GET)) {
- ...
- doGet(req, resp);
- } else if (method.equals(METHOD_HEAD)) {
- doHead(req, resp);
- } else if (method.equals(METHOD_POST)) {
- doPost(req, resp);
- } else if (method.equals(METHOD_PUT)) {
- doPut(req, resp);
- } else if (method.equals(METHOD_DELETE)) {
- doDelete(req, resp);
- } else if (method.equals(METHOD_OPTIONS)) {
- doOptions(req,resp);
- } else if (method.equals(METHOD_TRACE)) {
- doTrace(req,resp);
- } else {
- ...// NO servlet supports
- }
- }
protected void service(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { String method = req.getMethod(); if (method.equals(METHOD_GET)) { ... doGet(req, resp); } else if (method.equals(METHOD_HEAD)) { doHead(req, resp); } else if (method.equals(METHOD_POST)) { doPost(req, resp); } else if (method.equals(METHOD_PUT)) { doPut(req, resp); } else if (method.equals(METHOD_DELETE)) { doDelete(req, resp); } else if (method.equals(METHOD_OPTIONS)) { doOptions(req,resp); } else if (method.equals(METHOD_TRACE)) { doTrace(req,resp); } else { ...// NO servlet supports } }
Service方法里面其实很简单,就是根据不同的请求,调用不同的do***()方法。Http的请求类型一共有如上七种。 一个HttpServlet的子类必须至少覆写以下方法中的一个。 1) doGet()方法,适用于HTTP GET请求。自动支持一个HTTP HEAD请求。当覆写doGet()时,首先读取请求数据,写入响应的head,然后获得响应的writer或输出流对象,最后写入响应数据。 2) doPost()方法,适用于HTTP POST请求。覆写该方法与doGet()类似。 3) doPut()方法,适用于HTTP PUT请求。PUT操作允许客户好像使用FTP一样把文件放置到服务器。 4) doDelete()方法,适用于HTTP DELETE请求。DELETE操作允许客户从服务器中删除一个文档或网页。 5) init()和destroy()方法,管理Servlet生命周期中的资源。 6) getServletInfo()方法,提供Servlet本身的信息。
另外还有不需要覆写的方法: 7) doHead()方法,适用于HTTP HEAD请求。当客户端只需要知道响应头,比如Content-Type或者Content-Length,客户端只需要发送一个HEAD请求。HTTP HEAD会准确地计算输出的字节数来设定Content-Length。如果覆写该方法,可以避免计算响应的BODY,而只需设置响应头以改善性能。 8) doOptions()方法,适用于OPTIONS请求。OPTIONS操作决定服务器支持哪种HTTP方法,并返回一个适当的头信息。例如,如果一个servlet覆写了doGet()方法,doOptions()方法将会返回如下头信息:Allow: GET, HEAD, TRACE, OPTIONS。 9) doTrace()方法,适用于TRACE请求。该方法用于程序调试,无需被覆写。
尽管说有这么多do***()方法,可是我们常用的就只有doGet()和doPost()。
Tomcat6讲到这里就大概差不多了,它的组成,启动,消息处理都过了一遍。不过消息处理我只写了nio的处理方式,下篇看看要不写下传统的bio方式。