Java程序员应知应会，为什么现在我们不用Servlet了？

　　每个学习Java的同学都会从Servlet开始学习。ServletAPI发表于1998年，可以说JavaEE众多API中最成功的一个。多年以来，它的核心API一直变化不大，非常的稳定。
　　但是，新入行的程序员们现在却很少用它了，甚至很多人如果是转行过来，直接就开始写项目的话，可能完全不熟悉Servlet的编码风格了。程序员们可能已经习惯了基于SpringMVC的Springboot风格，已经熟悉了Restful的开发方法。那么，我们真的不再使用Servlet了吗？答案是否定的，我们依然在使用Servlet，只不过原来是我们直接写Servlet，而现在是框架代替我们完成Servlet的工作而已。
　　类似于Structs、SpringMVC等框架，它们的核心理念都是Servlet与handler之间的一个mapping。
　　以SpringMVC为例，它有一个DispatherServlet，负责处理请求，并且调用了我们写的Controller。作为Controller的前端控制器DispatcherServlet最终是继承了HttpServlet的，只不过springmvc帮助你做好了url和method的映射了（注解实现），不需要你自己在web。xml一个servlet和一个method去配置了。
　　DisPatcherServlet是Spring中唯一的Servlet，Servlet将所有请求都转发到DisPatcherServlet，然后DisPatcherServlet分发请求通过HandlerMapping（处理器映射器）和HandlerAdapter（处理器适配器）找到具体的Controller。而Controller只是一个普通的JavaBean。
　　DisPatcherServlet的生命周期和Servlet是相同的，都是在第一次被访问时创建，容器关闭时销毁。具体的过程如下图所示：
　　那么为什么我们需要框架去做这些工作呢？这就不得不提到Servlet本身存在的一些缺点和不便之处了。
　　Servlet最大的缺点是一个类只能写一个接口，而每一个Servlet都要在web。xml中进行相应的配置，我们想在一个Servlet里写很多个方法的话，则需要采用传递参数的形式，分解到每一个方法中。如果有很多Servlet，就会导致web。xml内容过于繁多。而这样的结构很明显是不利于分组开发的。
　　另外，在Servlet中，doGet方法和doPost方法有HttpServletRequest和HttpServletResponse参数。这两个参数与容器相关，如果想在servlet中作单元测试，则必须初始化这两个参数。在我们目前已经习惯了进行单元测试的情况下，Servlet就显得很不方便。
　　因此，人们才用框架把Servlet封装起来，替我们完成这些繁琐的工作，从而增加开发效率。
　　所以，事实上并不是我们不用Servlet了，而是基于Servlet实现的各类框架，替我们完成了相关的工作，从而不需要我们自己编写Servlet了。