Servlet是Server+Applet的缩写，表示一个服务应用。其实Servlet就是一套规范，我们按照这套规范写的代码就可以直接在Java的服务器上面运行。
既然Servlet是一套规范，那么最重要的当然就是接口了。Servlet3.1中Servlet的接口，如下代码清单：
▪️init方法在容器启动时被容器调用（当load-on-startup设置为负数或者不设置时会在Servlet第一次用到时才被调用），只会调用一次；
▪️getServletConfig方法用于获取ServletConfig，；
▪️service方法用于具体处理一个请求；
▪️getServletInfo方法可以获取一些Servlet相关的信息，如作者、版权等，这个方法需要自己实现，默认返回空字符串；
▪️destroy方法主要用于在Servlet销毁（一般指关闭服务器）时释放一些资源，也只会调用一次。
init方法被调用时会接收到一个ServletConfig类型的参数，是容器传进去的。ServletConfig顾名思义指的是Servlet的配置，我们在web.xml中定义Servlet时通过init-param标签配置的参数就是通过ServletConfig来保存的，比如，定义Spring MVC的Servlet时指定配置文件位置的contextConfigLocation参数就保存在ServletConfig中，例如下面的配置：
Tomcat中Servlet的init方法是在org.apache.catalina.core.StandardWrapper的initServlet方法中调用的，ServletConfig传入的是StandardWrapper(里面封装着Servlet)自身的门面类StandardWrapperFacade。其实这个也很容易，Servlet是通过xml文件配置的，在解析xml时就会把配置参数給设置进去，这样StandardWrapper本身就包含配置项了，当然并不是StandardWrapper的所有内容都是Config相关的，所以就用了其门面Facade类。下面是ServletConfig接口的定义：
getServletName用于获取Servlet的名字，也就是我们在web.xml中定义的servlet-name；getInitParameter方法用于获取init-param配置的参数；getInitParameterNames用于获取配置的所有init-param的名字集合；getServletContext非常重要，它的返回值ServletContext代表的是我们这个应用本身，如果你看了前面Tomcat的分析就会想到，ServletContext其实就是Tomcat中Context的门面类AppliactionContextFacade（具体代码参考StandardContext的getServletContext）。既然ServletContext代表应用本身，那么ServletContext里面设置的参数就可以被当前应用的所有Servlet共享了。我们做项目的时候都知道参数可以保存在Session中，也可以保存在Application中，而后者很多时候就是保存在了ServletContext中。
我们可以这么理解，ServletConfig是Servlet级的，而ServletContext是Context（也就是Application级的）。当然，ServletContext的功能要强大很多，并不只是保存一下配置参数，否则就叫ServletContextConfig了。
有的读者可能会想，Servlet级和Context级都可以操作，那有没有更高一层的站点也就是Tomcat中的Host级的相应操作呢？在Servlet的标准例其实还真有，在ServetContext接口中有这么一个方法：public ServletContext getContext(String uripath)，它可以根据路径获取到同一个站点下单别的应用等ServletContext！当然由于安全的原因，一般会返回null，如果想使用需要进行一些设置。
ServletConfig和ServletContext最常见的使用之一是传递初始化参数。我们就以spring配置中使用得最多的contextConfigLocation参数为例来看一下：
注意：如果设置metadata-complete="true"，会在启动时不扫描注解（annotation）。如果不扫描注解的话，用注解进行的配置就无法生效，例如：@WebServlet
上面通过context-param配置的contextConfigLocation配置到了ServletContext中，而通过servlet下单init-param配置的contextConfigLocation配置到了ServletConfig中。在Servlet中可以分别通过它们的getInitParameter方法进行获取，比如：
为了操作方便，GenericServlet定义了getInitParameter方法，内部返回getServletConfig().getInitParameter的返回值，因此我们如果需要获取ServletConfig中的参数，可以不再调用getServletConfig()，而直接调用getInitParameter。
另外ServletContext中非常常用的用法就是保存Application级的属性，这个可以使用setAttribute来完成，比如：
getServltContext().setAttribute("contextConfigLocation","new path");
需要注意的是，这里设置的同名Attribute并不会覆盖initParameter中的参数值，它们是两套数据，互不干扰。ServletConfig不可以设置属性。
GenericServlet是Servlet的默认实现，主要做了三件事：
▪️实现了ServletConfig接口，我们可以直接调用ServletConfig里面的方法；
▪️提供了无参的init方法；
▪️提供了log方法。
GenericServlet实现了ServletConfig接口，我们在需要调用ServletConfig中方法等时候可以直接调用，而不再需要先获取ServletConfig了，比如，获取ServletContext的时候可以直接调用getServletContext，而无须调用getServletConfig.getServletContext()了，不过其底层实现其实是在内部调用了。getServletContext的代码如下：
GenericServlet实现了Servlet的init(ServletConfig config)方法，在里面将config设置給了内部变量config，然后调用了无参点init()方法，这个方法是个模版方法，在子类中可以通过通过覆盖它来完成自己的初始化工作，代码如下：
这种做法有三个作用：
▪️首先，将参数config设置給了内部属性config，这样就可以在ServletConfig的接口方法中直接调用config的相应方法来执行；
▪️其次，这么做之后我们在写Servlet的时候就可以只处理自己的初始化逻辑，而不需要再关心config了；
▪️还有一个作用就是在重写init()方法时也不需要再调用super.init(config)了。如果在自己的Servlet中重写了带参数的init方法，那么一定要记着调用super.init(config)，否则这里的config属性就接收不到值，相应地ServletConfig接口方法也就不能执行了。
GenericServlet提供了2个log方法，一个记录日志，一个记录异常。具体实现是通过传给ServletContext的日志实现的。
一般我们都有自己的日志处理方式，所以这个用得部署很多。
GenericServlet是与具体协议无关的。
HttpServlet是用HTTP协议实现的Servlet的基类，写Servlet时直接继承它就可以了，不需要再从头实现Servlet接口，我们要分析的Spring MVC中的DispatcherServlet就是继承的HttpServlet。既然HttpServlet是跟协议相关的，当然主要关心的是如何处理请求了，所以HttpServlet主要重写了service方法。在service方法中首先将ServletReuqest和ServletResponse转换为了HttpServletRequest和HttpServletResponse，然后根据Http请求的类型不同将请求路由到了的处理方法。代码如下：
service(request,response)的具体实现，如下代码清单所示：
承接上图
具体处理方法是doXXX的结构，如最常用doGet、doPost就是在这里定义的。doGet、doPost、doPut和doDelet方法都是模版方法，而且如果子类没有实现将抛出异常，在调用doGet的请求，然后返回空body的Response；doOptions和doTrace正常不需要使用，主要是用来做一些调试工作，doOptions返回所有支持的处理类型的集合，正常情况下可以禁用，doTrace是用来远程诊断服务器的，它会将接收到的header原封不动地返回，这种做法很可能会被黑客利用，存在安全漏洞，所以如果不是必须使用，最好禁用。由于doOptions和doTrace的功能非常固定，所以HttpServlet做了默认的实现。doGet代码如下(doPost、doPut、doDelete与之类似)；
这就是HttpServlet，它主要将不同的请求方式路由到了不同的处理方法。不过Spring MVC中由于处理思路不一样，又将所有请求合并到了统一的一个方法进行处理，在Spring MVC中再详细讲解。
▪️HttpServlet继承自GenericServlet，如下代码清单：
▪️GenericServlet实现了Servlet，ServletConfig接口，如下代码清单
▪️Spring MVC与HttpServlet之间的关系，如下代码清单
不出所料，但是HttpServletBean是个抽象类，看看FrameworkServlet怎么回事，如下代码清单
然而FrameworkServlet仍然是个抽象类，我们熟悉的DispatcherServlet上场了。
spring MVC中servlet一共有三个层次，分别是HttpServletBean、FrameworkServlet和DispatcherServlet。HttpServletBean直接继承自java的HttpServlet,其作用是将Servlet中配置的参数设置到相应的属性；FrameworkServlet继承HttpServletBean，有processRequest方法，主要作用是初始化了WebApplicationContext,DispactherServlet继承了FrameworkServlet，重写了doService方法，主要作用初始化了自身的9个组件。
DispactherServlet中的核心方法doService和doDispatch
doService：重写了FrameworkServlet的doService方法，主要作用是，检查是否为include请求，假如是，对request的attribute进行snapshot，检查是否有FlashMap,设置request一些属性，然后进入doDispatch方法；
doDispatch：检查是否为上传请求(Multipart)，根据request生成HandlerMapping,找到Handler和Interceptor,根据Handler找到HandlerAdapter，Adapter会检查Last-Modified,执行相应的Interceptor;
整体结构非常简单--分三个层次做了三件事，但具体实现过程还是有点复杂的。这其实也是spring的特点：结构简单，实现复杂。结构简单主要是顶层设计好，实现复杂的主要是提供的功能比较多，可配置的地方也非常多个九个组件分别是：
▪️HandlerMapping
▪️HandlerAdapter
▪️HandlerExceptionResolver
▪️ViewResovler
▪️RequestToViewNameTranslator
▪️LocaleResolver
▪️ThemeResolver
▪️MultipartResolver
▪️FlashMapManager
**如果需要給我修改意见的发送邮箱：erghjmncq6643981@163.com**
**资料参考：《看透Spring MVC-源代码分析与实践》**
**转发博客，请注明，谢谢。**
