从01开始 从01开始
首页
  • 计算机科学导论
  • 数字电路
  • 计算机组成原理

    • 计算机组成原理-北大网课
  • 操作系统
  • Linux
  • Docker
  • 计算机网络
  • 计算机常识
  • Git
  • JavaSE
  • Java高级
  • JavaEE

    • Ant
    • Maven
    • Log4j
    • Junit
    • JDBC
    • XML-JSON
  • JavaWeb

    • 服务器软件
    • Servlet
  • Spring
  • 主流框架

    • Redis
    • Mybatis
    • Lucene
    • Elasticsearch
    • RabbitMQ
    • MyCat
    • Lombok
  • SpringMVC
  • SpringBoot
  • 学习网课的心得
  • 输入法
  • 节假日TodoList
  • 其他
  • 关于本站
  • 网站日记
  • 友人帐
  • 如何搭建一个博客
GitHub (opens new window)

peterjxl

人生如逆旅,我亦是行人
首页
  • 计算机科学导论
  • 数字电路
  • 计算机组成原理

    • 计算机组成原理-北大网课
  • 操作系统
  • Linux
  • Docker
  • 计算机网络
  • 计算机常识
  • Git
  • JavaSE
  • Java高级
  • JavaEE

    • Ant
    • Maven
    • Log4j
    • Junit
    • JDBC
    • XML-JSON
  • JavaWeb

    • 服务器软件
    • Servlet
  • Spring
  • 主流框架

    • Redis
    • Mybatis
    • Lucene
    • Elasticsearch
    • RabbitMQ
    • MyCat
    • Lombok
  • SpringMVC
  • SpringBoot
  • 学习网课的心得
  • 输入法
  • 节假日TodoList
  • 其他
  • 关于本站
  • 网站日记
  • 友人帐
  • 如何搭建一个博客
GitHub (opens new window)
  • JavaSE

  • JavaSenior

  • JavaEE

  • JavaWeb

  • Spring

  • 主流框架

  • SpringMVC

  • SpringBoot

    • SpringBoot教程-尚硅谷

      • SpringBoot课程介绍
      • Spring和SpringBoot
      • HelloWorld
      • 了解自动配置原理
      • 底层注解-@Configuration详解
      • 底层注解-@Import导入组件
      • 底层注解-@Conditional条件装配
      • 原生配置文件引入-@ImportResource
      • 底层注解-配置绑定@ConfigurationProperties
      • 自动配置原理
      • 自动配置流程
      • Lombok简化开发
      • DevTools
      • Spring-Initailizr
      • 配置文件-Yaml用法
      • Web开发简介
      • web开发-静态资源规则于定制化
      • 静态资源配置原理
      • Rest映射及源码解析
      • 请求映射原理
        • DispatcherServlet
        • doDispatch
        • ​HandlerMapping​​
        • 自动配置的​HandlerMapping​
        • 总结
      • 常用参数注解使用
      • MatrixVariable:矩阵变量
      • 各种类型参数解析原理
      • Servlet-API参数解析原理
      • Model、Map参数解析原理
      • 自定义对象参数绑定原理
      • 自定义Converter原理
      • 数据响应原理
      • 内容协商原理
      • 基于请求参数的内容原理
      • 自定义MessageConverter原理
      • Thymeleaf初体验
      • web实验-后台管理系统
      • web实验-抽取公共页面
      • web实验-遍历数据
      • 源码分析-视图解析器与视图
      • 拦截器-登录检查与静态资源放行
      • 拦截器的执行时机和原理
      • 单文件和多文件上传的使用
      • 文件上传原理
      • 错误处理机制
      • 错误处理-底层组件源码分析
      • 异常处理流程
      • 几种异常处理原理
      • Web原生对象注入
      • 嵌入式Servlet容器
      • 定制化原理
      • 数据库场景的自动配置分析和整合测试
      • 自定义方式整合Druid
      • 通过starter整合Druid
      • 整合Mybatis
      • 使用注解整合Mybatis
      • 整合MybatisPlus操作数据库
      • MybatisPlus-列表分页展示
      • 整合Redis
      • 单元测试-Junit5
      • 单元测试-断言机制
      • 单元测试-前置条件
      • 单元测试-嵌套测试
      • 单元测试-参数化测试
      • 指标监控-基本概念
      • 指标监控-配置EndPoint
      • 指标监控-可视化
      • 原理解析-Profile功能
      • 配置文件深入
      • 自定义Starter
      • SpringApplication初始化过程
      • SpringBoot完整启动过程
      • SpringBoot
  • Java并发

  • Java源码

  • JVM

  • 韩顺平

  • Java
  • Java
  • SpringBoot
  • SpringBoot教程-尚硅谷
2023-08-22
目录

请求映射原理

# 200.请求映射原理

接下来我们讲解请求映射原理,也就是一个请求,具体是怎么找到具体的方法去处理的      ‍

# DispatcherServlet

首先,SpringBoot用的是SpringMVC;而在SpringMVC中,核心组件是DispatcherServlet,前端控制器。

我们可以打开其源码(在IDEA中按两下shift键,就会打开搜索框,希望读者自己也跟着动手看源码),然后我们可以分析出其继承关系是这样的:DispatcherServlet​ → FrameworkServlet​ → HttpServletBean​ → HttpServlet​,所以它还是一个Servlet;

那么它必须重写doGet和doPost方法,但是不是在DispatcherServlet​,而是在FrameworkServlet​重写的。其部分源码如下:

@Override
protected final void doGet(HttpServletRequest request, HttpServletResponse response)
		throws ServletException, IOException {
	processRequest(request, response);
}

@Override
protected final void doPost(HttpServletRequest request, HttpServletResponse response)
		throws ServletException, IOException {
	processRequest(request, response);
}

@Override
protected final void doPut(HttpServletRequest request, HttpServletResponse response)
		throws ServletException, IOException {
	processRequest(request, response);
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

‍

可以看到,所有请求方法都是调用processRequest方法来处理的,而在该方法中,最主要的代码是:

try {
	doService(request, response);
}
1
2
3

‍

接下来我们看doService方法:可以看到其是一个抽象方法。

protected abstract void doService(HttpServletRequest request, HttpServletResponse response)
			throws Exception;
1
2

‍

既然是抽象方法,理所当然就得是子类去实现了,因此我们分析DispatcherServlet​的doService方法,在该方法一开始都是一些初始化的过程,关键还是调用了doDispatch方法,该方法就是用来做转发的了:

try {
    doDispatch(request, response);
}
1
2
3

也就是每个请求,都会调用该方法,我们分析映射原理,也是要看该方法

‍

# doDispatch

接下来我们在该方法打个断点,并以debug 的方式来启动,来逐步分析请求;

​​

‍

然后我们可以将鼠标放到request参数上,会有个小弹框:

​​

‍

点击它,就能展开该变量的详细情况了:例如可以看到请求路径是/user​

​​

‍

‍

然后我们往下执行代码(快捷键F8)

​​

‍

‍

protected void doDispatch(HttpServletRequest request, HttpServletResponse response) throws Exception {
		HttpServletRequest processedRequest = request;
		HandlerExecutionChain mappedHandler = null;
		boolean multipartRequestParsed = false;

                WebAsyncManager asyncManager = WebAsyncUtils.getAsyncManager(request);
1
2
3
4
5
6

前几行代码:

  • 首先用一个变量接受了request请求,
  • 第二行则是一个调用链,后续再说;
  • 第3行则是判断是否文件上传请求,默认是false
  • 然后是一个异步请求的处理,我们先不管

‍

‍

接下来的代码:

try {
    ModelAndView mv = null;
    Exception dispatchException = null;

    try {
    	processedRequest = checkMultipart(request);
	multipartRequestParsed = (processedRequest != request);

	// Determine handler for the current request.
	mappedHandler = getHandler(processedRequest);
	if (mappedHandler == null) {
		noHandlerFound(processedRequest, response);
		return;
	}
1
2
3
4
5
6
7
8
9
10
11
12
13
14

一开始几行是初始化的,关键是第10行开始,上面也有注释:决定哪个handler处理当前请求

‍

我们一步步执行,直到第10行,然后点击步入(快捷键F7)

​​

‍

可以看到,其首先判断handlerMappings​是否为空(这里不为空,有5个值)

​​

‍

# ​HandlerMapping​​

​HandlerMapping​,就是处理器映射,存储了某个请求该由谁处理的信息,并存储在一个集合里。我们可以看到第1个,WelcomePageHandlerMapping,就是欢迎页的处理,可以展开来看,其路径是 /​,并且对应的资源(view)是index.html:

​​​​

‍

接下来我们看第0个:RequestMappingHandlerMapping,这就是我们使用注解@RequestMapping后,存储的路径和方法信息都会存到这里:

​​​​

‍

‍

那么该handlerMappings​集合的内容是哪来的呢?不言而喻,就是我们项目启动的时候,SpringBoot帮我们扫描的,然后放到该集合里。

接下来就是for循环,从该集合里找到当前请求,具体是哪个方法来处理了。

protected HandlerExecutionChain getHandler(HttpServletRequest request) throws Exception {
	if (this.handlerMappings != null) {
		for (HandlerMapping mapping : this.handlerMappings) {
			HandlerExecutionChain handler = mapping.getHandler(request);
			if (handler != null) {
				return handler;
			}
		}
	}
	return null;
}
1
2
3
4
5
6
7
8
9
10
11

‍

我们继续往下,直到执行第4行的的时候,不如进去,此时可以看到是AbstractHandlerMapping​类的getHandler​方法被执行,然后我们执行到第2步,继续步入:

public final HandlerExecutionChain getHandler(HttpServletRequest request) throws Exception {
	Object handler = getHandlerInternal(request);
	if (handler == null) {
		handler = getDefaultHandler();
	}
	if (handler == null) {
		return null;
	}
1
2
3
4
5
6
7
8

‍

然后我们看getHandlerInternal方法,可以看到会调用父类的方法:

@Override
protected HandlerMethod getHandlerInternal(HttpServletRequest request) throws Exception {
	request.removeAttribute(PRODUCIBLE_MEDIA_TYPES_ATTRIBUTE);
	try {
		return super.getHandlerInternal(request);
	}
	finally {
		ProducesRequestCondition.clearMediaTypesAttribute(request);
	}
}
1
2
3
4
5
6
7
8
9
10

‍

我们继续步入到父类的方法中:

protected HandlerMethod getHandlerInternal(HttpServletRequest request) throws Exception {
	String lookupPath = getUrlPathHelper().getLookupPathForRequest(request);
	request.setAttribute(LOOKUP_PATH, lookupPath);
	this.mappingRegistry.acquireReadLock();
	try {
		HandlerMethod handlerMethod = lookupHandlerMethod(lookupPath, request);
		return (handlerMethod != null ? handlerMethod.createWithResolvedBean() : null);
	}
	finally {
		this.mappingRegistry.releaseReadLock();
	}
}
1
2
3
4
5
6
7
8
9
10
11
12

分析:

  • 首先获取lookupPath,也就是访问的路径
  • 第4行还获取了一把锁,避免并发的问题
  • 然后第6行,就是获取具体的方法了,我们步入进去

‍

‍

lookupHandlerMethod方法源码如下:

@Nullable
protected HandlerMethod lookupHandlerMethod(String lookupPath, HttpServletRequest request) throws Exception {
	List<Match> matches = new ArrayList<>();
	List<T> directPathMatches = this.mappingRegistry.getMappingsByUrl(lookupPath);
	if (directPathMatches != null) {
		addMatchingMappings(directPathMatches, matches, request);
	}
	if (matches.isEmpty()) {
		// No choice but to go through all mappings...
		addMatchingMappings(this.mappingRegistry.getMappings().keySet(), matches, request);
	}

	if (!matches.isEmpty()) {
		Match bestMatch = matches.get(0);
		if (matches.size() > 1) {
			Comparator<Match> comparator = new MatchComparator(getMappingComparator(request));
			matches.sort(comparator);
			bestMatch = matches.get(0);
			if (logger.isTraceEnabled()) {
				logger.trace(matches.size() + " matching mappings: " + matches);
			}
			if (CorsUtils.isPreFlightRequest(request)) {
				return PREFLIGHT_AMBIGUOUS_MATCH;
			}
			Match secondBestMatch = matches.get(1);
			if (comparator.compare(bestMatch, secondBestMatch) == 0) {
				Method m1 = bestMatch.handlerMethod.getMethod();
				Method m2 = secondBestMatch.handlerMethod.getMethod();
				String uri = request.getRequestURI();
				throw new IllegalStateException(
						"Ambiguous handler methods mapped for '" + uri + "': {" + m1 + ", " + m2 + "}");
			}
		}
		request.setAttribute(BEST_MATCHING_HANDLER_ATTRIBUTE, bestMatch.handlerMethod);
		handleMatch(bestMatch.mapping, lookupPath, request);
		return bestMatch.handlerMethod;
	}
	else {
		return handleNoMatch(this.mappingRegistry.getMappings().keySet(), lookupPath, request);
	}
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

‍

首先,第4行先根据URL找,找到所有的处理器(因为/user有很多处理器,只不过HTTP请求的方式不同),这里推测是4个,debug的结果也是4个:

​​

‍

下一步,就是将所有找到的处理器,添加到集合里:

if (directPathMatches != null) {
	addMatchingMappings(directPathMatches, matches, request);
}
1
2
3

‍

如果没找到,则添加一些空的元素进去:

if (matches.isEmpty()) {
	// No choice but to go through all mappings...
	addMatchingMappings(this.mappingRegistry.getMappings().keySet(), matches, request);
}
1
2
3
4

‍

‍

‍

接下来就是寻找真正匹配的处理器了。首先会判断是否为空,不为空则先获取第一个;

然后如果找到了多个(大于1),说明找到了多个,那么if判断里会先排个序,看看哪个才是真正最佳匹配的(url相同,请求方式也相同),如果找不到最佳匹配的,说明有多个处理器,都可以处理该请求,则会报错

if (!matches.isEmpty()) {
		Match bestMatch = matches.get(0);
		if (matches.size() > 1) {
			Comparator<Match> comparator = new MatchComparator(getMappingComparator(request));
			matches.sort(comparator);
                // 省略其他代码
                throw new IllegalStateException("Ambiguous handler methods mapped for '" 
                                            + uri + "': {" + m1 + ", " + m2 + "}");
1
2
3
4
5
6
7
8

‍

‍

# 自动配置的​HandlerMapping​

刚刚我们讲过handlerMappings存储了几个组件:

​​

‍

这几个是SpringBoot自动帮我们配置的,可以看到WebMvcAutoConfiguration​类中有对应的@Bean:

@Bean
@Primary
@Override
public RequestMappingHandlerMapping requestMappingHandlerMapping(....){...}


@Bean
public WelcomePageHandlerMapping welcomePageHandlerMapping(....){...}
1
2
3
4
5
6
7
8

‍

‍

# 总结

所有的请求映射都在HandlerMapping中:

  • 自动配置了欢迎页的 WelcomePageHandlerMapping 。访问/​,能访问到index.html;

  • SpringBoot自动配置了默认了RequestMappingHandlerMapping

  • 请求进来时,会挨个尝试所有的HandlerMapping看是否有请求信息。

    • 如果有就找到这个请求对应的handler
    • 如果没有就是下一个 HandlerMapping
  • 如果需要一些自定义的映射处理,也可以自己给容器中放HandlerMapping(自定义)

‍

‍

‍

在GitHub上编辑此页 (opens new window)
上次更新: 2023/8/23 10:10:57
Rest映射及源码解析
常用参数注解使用

← Rest映射及源码解析 常用参数注解使用→

Theme by Vdoing | Copyright © 2022-2023 粤ICP备2022067627号-1 粤公网安备 44011302003646号
  • 跟随系统
  • 浅色模式
  • 深色模式
  • 阅读模式