目标问题：
- Servlet容器如何工作
- Servlet容器如何解析web.xml中定义的Servlet
- 用户请求如何分配给指定的Servlet
- Servlet容器如何管理Servlet生命周期
Servlet容器与Servlet的关系：
- Servlet的运行需要基于Servlet容器，例如web服务与Jetty、Tomcat服务的关系
- Servlet的生命周期的管理（创建到销毁），都由Servlet容器负责
以tomcat为例：在tomcat中真正管理Servlet的是Context容器，一个Context对应一个web工程
Servlet容器启动过程：
tomcat7开始支持嵌入式功能，增加启动类org.apache.catalina.startup.Tomcat
- 创建一个实例对象并调用start方法就可以启动Tomcat
- 还可以通过该类，增加和修改Tomcat的配置参数，如可以动态的添加Context和Servlet等。
启动过程：
添加web应用
--> 创建StandardContext(Context容器)，并设置必要的参数，如：url（访问路径）、path（应用实际物理路径）
--> 将Context容器添加的父容器Host中当Context容器初始化状态为init时，添加到Context容器的Listener将会被调用。
ContextConfig类：
- ContextConfig集成了LifecycleListener接口，它是在调用Tamcat.addWebApp时被加入到StandardContext容器中的。
- ContextConfig类会负责整个web应用的配置文件的解析工作。
init方法：
- 创建用于解析XML配置文件的contextDigester对象
- 读取默认的context.xml配置文件，如果存在则解析它
- 读取Host配置文件，如果存在则解析它
- 读取Context自身的配置文件，如果存在则解析
- 设置Context的DocBase
startInternal方法：
当init方法执行完成之后，执行该方法
- 创建读取资源文件的对象
- 创建ClassLoader对象
- 设置对应的工作目录
- 启动相关的辅助类，如logger、realm、resources等
- 修改启动状态，通知感兴趣的观察者（web应用的配置）
Tomcat的启动逻辑是基于观察者模式设计的，所有容器都继承LifeCycle接口，它管理容器的整个生命周期，所有容器的修改和状态的改变都会由Lifecycle去通知已经注册的观察者（Listener）
- 子容器的初始化
- 获取ServletContext并设置必要的参数
- 初始化“load on startup”的Servlet
web应用的初始化：
ContextConfig类中configureStart方法，负责web应用的初始化工作，应用的初始化如要解析web.xml文件，这个配置文件描述一个web应用的关键信息，也是一个web应用的入口。
初始化过程：
- 找到globalWebXml：搜索路径是engine工作目录下的org/apache/catalina/startup/NO_DEFAULT_XML或者conf/web.xml
- 找到hostWebXml，这个文件可能会在System.getProperty("catalina.base")/conf/
{HostName}/web.xml.default中
- 找到应用配置文件，*/WEB-INF/web.xml
- web.xml文件解析成相应的属性保存到webXml对象中
- 将webXml对象中的属性设置到Context容器中（通过webXml中的configuerContext方法），包括创建Servlet对象、filter、listener等
- Servlet被包装成StandardWrapper，作为子容器添加到Context容器中。除此以外，其它所有的web.xml属性都被解析到Context中，
在web应用初始化过程中，Servlet被 包装成StandardWrapper，添加到Context容器中，但Servlet并未实例化。
Servlet对象的创建：
如果Servlet的load-on-startup配置项大于0，那么在Context容器启动时就会被实例化。
- web应用初始化过程中，会默认读取globalWebXml，在conf/web.xml文件中，定义了两个Servlet（随Context启动而实例化），分别是org.apache.cataline.servlets.DefaultServlet、org.apache.jasper.servlet.JspServlet。这两个的load-on-startup分别时1和3。
Servlet初始化：
Servlet的初始化在StandardWrapper的initServlet方法中，调用Servlet的init方法，同时把包装了StandardWrapper对象的StandardWrapperFacade作为ServletConfig传给Servlet。如果该servlet关联的是一个JSP文件，那么前面初始化的JspServlet会模拟一次请求，调用该JSP文件，以便编译该JSP文件为类，并初始化该类。
Servlet体系结构
Servlet顶层类关系
Servlet
--> ServletConfig --> ServletContext
--> ServletRequest
--> ServletResponse
Servlet主动关联ServletConfig、ServletRequest、ServletResponse，这三个类都是通过容器传给Servlet的。
- ServletConfig在初始化Servlet时传递
- ServletRequest、ServletResponse在请求时传递
ServletConfig、ServletContext的作用：
- Servlet的运行模型是一个典型的“握手型的交互式”运行模式，ServletContext提供交互的场景，而ServletConfig提供给场景的配置
- 前面提到Servlet初始化时，是将包装了ServletWrapper的StandaraWrapperFacade作为ServletConfig传递给Servlet的。
- ServletWrapper、StandardWrapperFacade都继承了ServletConfig，在传递过程StandardWrapperFacade保证了，Servlet拿到的ServletConfig中的配置，而其它数据不被暴露。
与上相同，ServletContext与ServletConfig的处理方式相同，Servlet拿到的ServletContext的实际对象是ApplicationContextFacade，而该类保证了ServletContext只能从容器中拿到该拿的数据。
Servlet工作流程
用户浏览器发起http请求 --> hostname和port用来与服务器建立TCP链接，后面的URL用来选择在服务器中的那个子容器服务用户的请求。
URL与Servlet的映射实现：
- Tomcat7中由org.apache.tomcat.util.mapper类完成。
- mapper类保存了Tomcat的Container容器中的所有子容器的信息，org.apcahe.catalina.connector.Request类在进入Container容器前，Mapper将根据请求的hostname和contextpath将host和context容器设置到Request的mappingData属性中。
Mapper的映射创建：
MapperListener在初始化过程中，init方法将MapperListener类作为一个监听者添加到整个container容器的每个子容器中，只要任何一个容器发生变化，都会通知到MapperListener，MapperListener接到通知处理mapper的创建和修改工作
请求流程：
http请求
--> {Request [Mapping Data]}
-- Pipeline --> Engine容器（StandardEngineValue）
-- request.getHost --> (Host容器)StandardHostValue
-- request.getContext --> (Context容器) StandardContextValue
-- request.getWrapper --> （wrapper容器）StandardWrapperValueRequest
-- 传入host和URL--> MapperListener (init -- Mapper)
-- 设置请求容器和路径 --> Request当请求进入到Wapper容器之后，就进入到执行Servlet的service方法中。但是在达到正确的Servlet之前还需要执行Filter链，以及通知web.xml中配置的Listener
当前MVC框架实现的Servlet流程原理：所有的请求都映射到一个Servlet，然后实现service方法，这个service也就是MVC框架的入口。
Servlet中的Listener
- 整个tomcat中的Listener是基于观察者模式设计的，是为开发servlet程序提供的快捷手段（能够方便的从另一个纵向维度控制程序和数据）
- 六种两类事件的观察者接口：
- EventListeners类型的ServletContextAttributeListener、ServletRequestAttributeListener、ServletRequestListener、HttpSessionAttributeListener
- LifecycleListener类型的ServletContextListener、HttpSessionListener
- 所有的Listener接口都继承了Listener接口，并添加了各自不同实现的接口，这个Listener的配置可以在web.xml中的<Llistener>标签中设置，也可以在代码中进行配置。
Filter链
- 配置：web.xml中的<filter>、<filter-mapping>组合标签进行配置
- 提供FilterChain，灵活控制请求的流转
- 在tomcat容器中，FilterConfig和FilterChain的实现类分别是ApplicationFilterConfig和ApplicationFilterChain，而Filter的实现类由用户自定义。
Filter接口中有三个方法：
- init(FilterCnfig)：初始化接口，在用户自定义的Filter初始化时被调用。
- doFilter(ServlteRequest,ServletResponse,FilterChain)：每个用户的请求进来时都会被调用，并在在Servlet的service方法之前调用。方法中传递的FilterChain就是当前整个请求链，调用FilterChain.doFilter可以将请求传递下去，如果该请求被拦截，则不调用FilterChain.doFilter方法，直接返回。
- destory:当filter销毁时调用。
- Filter是一种责任链设计模式
- Filter类的核心是传递FilterChain对象，这个对象保存了最终到Servlet对象的所有Filter对象（ApplicationFilterChain对象的filters数组中）
- FilterChain链上每执行一个Filter，记录数组的当前计数就会加一，知道计数等于数组长度，当前FilterChain链上所有的Filter执行完成之后，就会执行最终的Servlet。
Servlet中的url-pattern（url匹配原理）
- 在web.xml中<servlet-mapping>、<filter-mapping>标签中都有<url-patter>配置项
- Filter的url-pattern匹配是在创建ApplicationFilterChain对象时进行的，它会把所有定义的Filter的url-pattern与当前URL进行匹配，如果匹配成功，就将这个Filter保存到ApplicationFilterChain的filters数组中，然后由FilterChain依次调用。
- web.xml在加载时，会首先检查<url-pattern>配置是否符合规则，这个检查是在StandardContext的validateUrlPattern方法中检查的，如果检查不成功，Context容器启动失败。
<url-pattern>解析规则：
- 精确匹配：如/temple.html只会匹配到temple.html这个URL
- 路径匹配：如/ifcs/*会匹配到以ifcs为前缀的URL
- 后缀匹配：如*.html会匹配到以.html为后缀的URL
