面试官：听说你很懂SpringMVC,那讲讲其内部对于请求的处理吧！-编程知识

前言

在当下这个时代，我们每天都会借助浏览器浏览很多内容。但你是否有考虑过当你在浏览器中访问某一个网址时候，这背后都发生了那些事情呢？

事实上，当在浏览器中键入url后，其背后的处理逻辑可大致如下图所示：

可以看到，键入url后其大致会经历如下几个步骤：

DNS解析： 首先，浏览器会解析网址中的主机名，以获取服务器的IP地址。这个过程通过DNS（域名系统）完成。
建立TCP连接： 一旦浏览器知道了服务器的IP地址，它会尝试建立到服务器的TCP连接。通常这个过程会包括三次握手，以确保客户端和服务器之间的连接建立成功。
发送HTTP请求： 一旦TCP连接建立，浏览器会发送一个Http请求到服务器。这个请求包括了要访问的资源路径、HTTP方法（GET、POST等）、请求头（包含用户代理、接受的数据类型等）以及任何附加数据（例如，表单数据或请求体）。
服务器处理请求： 服务器收到HTTP请求后，会根据请求的路径和方法来确定如何处理请求。这通常涉及到后端应用程序的控制器（例如，SpringMVC的Controller）处理请求，执行相应的业务逻辑。
生成HTTP响应,发送响应： 一旦服务器完成请求处理，它会生成一个Http响应。而这个响应通常包括:状态码、响应头以及响应体。
浏览器渲染： 浏览器接收到HTTP响应后，根据响应的内容类型（例如，HTML、CSS、JavaScript等）来渲染页面。

实际上Http请求的处理流程会涉及到很多复杂细节，笔者在此也只是做一个抛砖引玉的介绍，其主要目的也是在于让读者对于Http请求的大致处理过程有一个大致的认识。

简化Http请求的处理流程

虽然上述已经对Http请求的处理流程进行了极大的简化，但可能你还是会觉得上述对于Http请求处理的有些繁琐。那能不能对上述步骤再进行一层抽象，让其更容易理解呢？答案当然是肯定的！

基于此，我们对上图所示的Http请求处理流程进行再一次抽象，得到下图所示内容：

可以看到当对复杂事物进行抽象后，一切似乎好像开始变得简单了。接下来，我们大致来分析下图中的大致流程：

浏览器发起Http请求至中间件,这个中间件可以概括很多东西。比如：反向代理，路由跳转、网络分发等。
Http请求到达后端服务器Tomcat，其实你可以将Tomcat理解为一个接待请求Http请求的接待员，其主要负责统筹处理请求，而不是所有的事情都自己做。进一步，其会将处理逻辑委托给进程。

为了进一步方便理解，我们举一个网购的例子来分析Http请求处理的大致逻辑。首先，当我们在浏览器键入发起购物的Http请求后，这个Http请求在不丢包的前提下，最终会历经万水千山到达Tomcat；然后，Tomcat会将Http请求分发给专门管理订单的进程，并记录其对于某个商品的购买数量。此外，还需要告诉管理库存的进程，进行库存的扣减，同时，还要告诉支付的进程，应该支付的金额。最后，在将处理结果返回给浏览器进行解析。

可以看到Tomcat会将Http请求分发给专门的进程来处理Http请求，而具体到Java后端搭建的服务来看，其会将Http请求交给交给SpringMVC来进行处理。

其实讲了这么多，重点在于分析清楚Http请求是如何到达后端服务的；在此基础上，我们重点关注后端服务SpringMVC内部是如何来完成对Http请求的处理。

SpringMVC内部对于Http请求的处理

在开始分析之前，我们先来看看后端服务是如何来定义前端待访问的url的：

@RestController
@RequestMapping("/demo")
public class HelloWorldController {@GetMapping(value="/say-hello")public String sayHello(){return "helloworld";}
}

观察上述代码你会发现，其主要做了如下工作：

定义了一个待访问的url信息，即暴露给前端的地址信息为/demo/say-hello；
该url的请求方式为Get方式；
url对应的处理逻辑为sayHello方法。

明白了这些后，不妨思考一个问题，如果你来处理前端传来的/demo/say-hello请求，你该如何处理？ 我想你的思路大致如下：

获取请求的url信息；
根据url信息获取对应的处理逻辑，具体到SpringMVC中即寻找url对应的方法信息；
处理请求中的参数信息，执行url中对应的方法，并将结果返回。

进一步，将上述逻辑翻译为代码即有如下内容：

public class HttpRequestHandler {// 定义url信息和方法间的映射关系Map<RequestUrl， Method> mapper = new HashMap<>();/*** 处理前端传来的请求信息*/public Object handle(HttpRequest httpRequest {// 获取前端传来的url信息RequestUrl requestKey = getRequestUrl(httpRequest);// 根据url信息获取对应的处理逻辑Method method = this.mapper.getValue(requesUrl);// 解析前端传递的参数信息Object[] args = resolveArgsAccordingToMethod(httpRequest， method);// 执行方法，将结果进行返回return method.invoke(controllerObject, args);
}

事实上，这也就是SpringMVC中处理Http请求的底层了逻辑。虽然上述代码中省略了很多方法的编写，但这并不影响理解。

熟悉了SpringMVC处理Http请求的底层逻辑后，我们再来进一步看看SpringMVC在处理Http请求时的具体细节。

Http请求从Tomcat转交到SpringMVC控制器

我们首先来看Tomcat内部是如何将对Http请求的处理权转交给SpringMVC的。

众所周知，对于 SpringBoot应用而言，其本身并不提供通信层的支持，它是依赖于 Tomcat、Jetty 等容器来完成通信层的支持。而在SpringBoot应用中Tomcat是如何被启动的我们在此便不再赘述了。

进一步，当Tomcat启动后，此时遇到HTTP 请求访问，其会触发 Tomcat 底层提供的 NIO 通信来完成数据的接收，并最终将请求事件丢入线程池去处理，进而根据servlet-mapping配置的url-pater来选取对应的Servlet来进行处理。

这就是为什么使用SpringMVC时，需要将DispatcherServlet中的url-pattern改为/*拦截所有请求的原因。

SpringMVC控制器对于请求的处理

进一步，当url请求到达DispatcherServlet后，最终会调用到其中的doDispatch方法。而这个方法我们之前曾具体分析过，其大致处理逻辑如下：

这个过程具体会涉及到哪些处理逻辑，在此我们在此就不再赘述了。但其总结来看无非完成如下逻辑：

分发，即根据请求寻找对应的执行方法。 这个过程主要涉及到url与处理器之间的匹配。这一过程中会涉及到的组件有：HandlerMapping(处理器映射器)、HandlerAdapter(处理器适配器)等。
执行，反射执行寻找到的执行方法。 这一过程的本质就是通过反射机制来调用被@ReqeustMapping标注的方法。

进一步，在SpringMVC中：“对于前端传来的url信息，最终会交由RequestMappingHandlerAdapter中的handleInternal来进行处理”。更进一步，其本质会将方法反射执行的逻辑委托给ServletInvocableHandlerMethod来处理，其相关调用链如下：