深入理解Servlet(上)

本文介绍: 但是针对每一种请求，业务逻辑代码是不同的，Ht t pSe r v let无法知晓子类想干嘛，所以就抽出七个方法，并且提供了默认实现：报405、400错误，提示请求不支持。五个方法，最难的地方在于形参，然而To m cat会事先把形参对象封装好传给我…除此以外，既不需要我写TCP连接数据库，也不需要我解析HTTP请求，更不需要我把结果转成HTTP响应，request 对象和response 对象帮我搞定了。如果你观察培训班的教材，会发现进入Tomcat阶段后，我们开始全面面向接口编程，而且最早出现在JDBC阶段。

作者简介：大家好，我是smart哥，前中兴通讯、美团架构师，现某互联网公司CTO

联系qq：184480602，加我进群，大家一起学习，一起进步，一起对抗互联网寒冬

为什么要了解Se r v let

现如今各种框架层出不穷，Spr in gMVC早已经成过去式，几乎所有公司都直接使用Spr in gBo ot、微服务了。我甚至怀疑，还有多少人知道Ser v let这玩意…

但正所谓基础不牢地动山摇，如果你对Ser v let那一套机制不熟悉的话，往后学习Sp r ingMVC、Sp r ingBo ot时常常会感到困惑，甚至束手无策。举个简单的例子：

很多人都知道SpringMVC的Interc ept or可以用来拦截请求，符合条件的返回 true，请求继续往后走

对于这个问题，符合条件的自然好处理，直接返回 tr ue 即可，关键是不符合条件的怎么办？直接return false吗？

@Component
public class MyInterceptor extends HandlerInterceptorAdapter {

    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        // 由于返回值限定为boolean，所以你没法做return Result.error(...)之类的操作
        return false;
    }
}

@Configuration
public class MvcConfig implements WebMvcConfigurer {
    @Autowired
    private MyInterceptor myInterceptor;

    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        registry.addInterceptor(myInterceptor).addPathPatterns("/**");
    }
}

你会发现，如果Interceptor直接return fa lse，客户端将收不到任何消息（响应体为空），这对客户端而言是极其不友好的，因为它无法知道被拦截的原因：

此时，我们可以抛异常出去，在@RestControllerAd vi ce 统一处理：

@RestControllerAdvice
public class GlobalExceptionHandler {

    /**
     * 处理运行时异常
     * 比较正规的处理方式是返回统一结果，为了方便，这里直接返回String
     *
     * @param e
     * @return
     */
    @ExceptionHandler(RuntimeException.class)
    public String handleRuntimeException(RuntimeException e) {
        return e.getMessage();
    }

}

@Component
public class MyInterceptor extends HandlerInterceptorAdapter {

    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {

        // 模拟判断逻辑，如果不符合条件，直接抛异常
        if (ThreadLocalRandom.current().nextBoolean()) {
            throw new RuntimeException("未登录");
        }

        return true;
    }
}

但其实还可以利用Writer直接输出响应流：

@Component
public class MyInterceptor extends HandlerInterceptorAdapter {

    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {

        // 模拟判断逻辑，如果不符合条件，响应错误信息
        if (ThreadLocalRandom.current().nextBoolean()) {
            responseErrorMsg(response);
        }

        return true;
    }

    private void responseErrorMsg(HttpServletResponse response) throws IOException {
        PrintWriter writer = response.getWriter();
        writer.write("need login");
        writer.flush();
        writer.close();
    }
}

如果你对Servlet那一套不了解，也没好好研究过SpringMVC，上面的问题可能会让你手足无措。

所以，无论出于什么原因，我认为Java程序员都有必要了解一下Servlet，学习Servlet其实就是学习JavaWeb的请求响应机制。

很多人可能和我当初一样，把Servlet和太多东西联系起来。其实Servlet本身在Tomcat中是“非常被动”的一个角色，处理的事情也很简单。网络请求与响应，不是他的主要职责，它其实更偏向于业务代码。所谓的Request和Response是Tomcat传给它，用来处理请求和响应的工具，但它本身不处理这些。

文章会比较长，但是看完会拔高你看待Servlet的视角。

Servlet的前世今生

类似于Servlet是Server Applet（运行在服务端的小程序）等其他博文已经提过的内容，这里就不重复了。它就是用来处理请求的业务逻辑的。

之前在Tomcat外传中我们聊过，所谓Tomcat其实是Web服务器和Servlet容器的结合体。

什么是Web服务器？

比如，我当前在杭州，你能否用自己的电脑访问我桌面上的一张图片？恐怕不行。我们太习惯通过URL访问一个网站、下载一部电影了。一个资源，如果没有URL映射，那么外界几乎很难访问。而Web服务器的作用说穿了就是：将某个主机上的资源映射为一个URL供外界访问。

什么是Servlet容器？

Servlet容器，顾名思义里面存放着Servlet对象。我们为什么能通过Web服务器映射的URL访问资源？肯定需要写程序处理请求，主要3个过程：

接收请求
处理请求
响应请求

任何一个应用程序，必然包括这三个步骤。其中接收请求和响应请求是共性功能，且没有差异性。比如访问淘宝和访问京东，都是请求一个URL，然后服务器会响应一段JSON数据给浏览器。于是，大家就把接收和响应两个通用步骤抽取成Web服务器：

但处理请求的逻辑是不同的。没关系，抽取出来做成Servlet，交给程序员自己编写。

当然，随着后期互联网发展，出现了三层架构，所以一些逻辑就从Servlet抽取出来，分担到Service和Dao。

但是Servlet并不擅长往浏览器输出HTML页面，所以出现了JSP。

等Spring家族出现后，Servlet开始退居幕后，取而代之的是方便的SpringMVC。SpringMVC的核心组件DispatcherServlet其实本质就是一个Servlet，只不过它已经自立门户，在原来HttpServlet的基础上，又封装了一些复杂的逻辑。

总之，很多新手程序员框架用久了反而迷糊，觉得SpringMVC是凭空实现的，和Servlet没半毛钱关系。

我所理解的JavaWeb三大 组件

不知道从什么时候开始，我们已经不再关心、甚至根本不知道到底谁调用了我写的这个程序，反正我写了一个类，甚至从来没new过，它就跑起来了…

我们把模糊的记忆往前推一推，没错，就是在学了Tomcat后！从Tomcat开始，我们再也没写过main 方法。以前，一个main方法启动，程序间的调用井然有序，我们知道程序所有流转过程。但是到了Java web后，Servlet/Filter/Listener一路下来我们越学越沮丧。没有main，也没有new，写一个类然后在web.xml中配个标签，它们就这么兀自运行了。

其实，这一切的一切，简单来说就是“注入”和“回调”。想象一下吧朋友们，Tomcat里有个 main方法，假设是这样的：

其实，编程学习越往后越是如此，我们能做的其实很有限。大部分工作，框架都已经帮我们做了。只要我们实现xxx 接口，它会帮我们创建实例，然后搬运（接口注入）到它合适的位置，然后一套既定的流程下来，肯定会执行到。我只能用中国一个古老的成语形容这种开发模式：闭门造车，出门合辙（闭门造车完整的意思其实是形容一个人技艺高超，家里瞎捣鼓，完事就可以上路了）。

很多时候，框架就像一个傀儡师，我们写的程序是傀儡，顶多就是给傀儡化化妆、打扮打扮，实际的运作全是傀儡师搞的。

了解到这个层面后，JavaWeb三大组件任何生命周期相关的方法、以及调用时Tomcat传入的形参，这里就不再强调。肯定是程序的某处，在创建实例后紧接着就传入参数调用了呗。没啥神秘的。

如何编写一个Servlet

Servlet的定位

首先，我们心里必须有一个信念：我们都是菜鸡，框架肯定不会让我们写很难的代码，所以Servlet既然交给我们实现，肯定是很简单的！

（没有网络请求和响应需要我们处理，都封装好了！）

你别不服。如果你观察培训班的教材，会发现进入Tomcat阶段后，我们开始全面面向接口编程，而且最早出现在JDBC阶段。我就问你，JDBC接口是你自己实现的吗？别闹了，你导入MySQL的驱动包，它给你搞定了一切。

真正的连接过程太难写了，朋友们。底层就是TCP连接数据库啊，你会吗？写Soc ket，然后进行数据库校验，最后返回Conn ection？这显然超出我们的能力范围了。我们这么菜，JDBC不可能让我们自己动手的。所以各大数据库厂商体贴地推出了驱动包，里面有个Driver类，调用：

driver.connect(url, username, password);

即可得到Conn ec tion。

BUT，这一次难得Tomcat竟然这么瞧得起我黄某，仅仅提供了javax.servlet 接口，这是打算让我自己去实现？

不，不可能的，肯定是因为太简单了。

查看接口方法：

五个方法，最难的地方在于形参，然而Tomcat会事先把形参对象封装好传给我…除此以外，既不需要我写TCP连接数据库，也不需要我解析HTTP请求，更不需要我把结果转成HTTP响应，request 对象和response对象帮我搞定了。

看吧，Tomcat是不是把我们当成智障啊。

Tomcat之所以放心地交给我们实现，是因为Servlet里主要写的代码都是业务逻辑代码。和原始的、底层的解析、连接等没有丝毫关系。最难的几个操作，人家已经给你封装成形参传进来了。也就是说，Servlet虽然是个接口，但实现类只是个空壳，我们写点业务逻辑就好了。

总的来说，Tomcat已经替我们完成了所有“菜鸡程序员搞不定的骚操作”，并且传入三个对象：ServletConfig、ServletRequest、ServletResponse。

ServletConfig

翻译过来就是“Servlet配置”。我们在哪配置Servlet来着？web.xml嘛。请问你会用dom4j解析 xml得到对象吗？

可能…会吧，就是不熟练，嘿嘿嘿。

所以，Tomcat还真没错怪我们，已经帮“菜鸡们”搞掂啦：

也就是说，servletConfig对象封装了servlet的一些参数信息。如果需要，我们可以从它获取。

如何编写Servlet

Request/Response两位老朋友，不用多介绍了，也是大家最在意的网络请求相关的内容。但这其实也是Tomcat处理并封装好了的，不需要Servlet（我们）操心。很多人看待HTTP和Request/Response的眼光过于分裂，其实它们的关系就像菜园里的大白菜和餐桌上的酸辣白菜一样亲近！HTTP请求到了Tomcat后，Tomcat通过字符串解析，把各个请求头（Header），请求地址（URL），请求参数（QueryString）都封装进了Request对象中。通过调用：

request.getHeader();
request.getUrl()；
request.getQueryString();
...

等等方法，都可以得到浏览器当初发送的请求信息。

至于Response，Tomcat传给Servlet时，它还是空的对象。Servlet逻辑处理后得到结果，最终通过 response.write()方法，将结果写入 response内部的缓冲区。Tomcat会在servlet处理结束后，拿到response，遍历里面的信息，组装成HTTP响应发给客户端。

Servlet接口5个方法，其中init、service、destroy是生命周期方法。init和destroy各自只执行一次，即servlet创建和销毁时。而service会在每次有新请求到来时被调用。也就是说，我们主要的业务代码需要写在service中。

但是，浏览器发送请求最基本的有两种：Get/Post，于是我们必须这样写：

很烦啊。有没有办法简化这个操作？我不想直接实现javax.servlet接口啊。于是，菜鸡程序员找了下，发现了GenericServlet，是个抽象类。

我们发现GenericServlet做了以下改良：

提升了init方法中原本是形参的servletConfig对象的作用域（成员变量），方便其他方法使用
init方法中还调用了一个init空参方法，如果我们希望在servlet创建时做一些什么初始化操作，可以继承GenericServlet后，覆盖 init空参方法
由于其他方法内也可以使用servletConfig，于是写了一个getServletContext方法
service竟然没实现…要它何用