SpringBoot2：请求处理原理分析-接口参数解析原理

news2024/11/16 9:01:17

一、知识回顾

我们知道，接口的参数，一般都要配上注解来一起使用。
不同的参数注解，决定了传参的方式不同。

为什么会这样？
如果让你设计接口参数解析，你会怎么做？
本篇就来探究springboot底层是如何通过参数注解，来解析不同的参数传递方式的。

二、源码解读

首先，我们知道接口肯定是归DispatcherServlet类来管理的，所以，我们直接进入这个类
前面的章节，我们已经知道，接口入口方法是：org.springframework.web.servlet.DispatcherServlet#doDispatch
所以，我们进入这个方法进行断点跟踪并分析原理。

DispatcherServlet#doDispatch方法

1、找到对应request的Handler

这里的原理解释在：
SpringBoot2：请求处理原理分析-请求Path与接口的映射关系(HandlerMapping)
在这里插入图片描述

2、找Handler的适配器

在这里插入图片描述
mappedHandler.getHandler()
这个已经拿到具体的controller了，返回类型是HandlerMehod类型
那么，为什么不直接就反射调用了？还弄个适配器干啥？

我们进入getHandlerAdapter方法

这里的适配器，有四种

我们在看看适配器结构
它是一个接口，有三个方法。
在这里插入图片描述
它有以下几个实现类

这里我们会发现，实现类有6个，为什么，handlerAdapters变量只有4个了？
我们继续看源码，会发现是通过DispatcherServlet.properties配置好的。

D:/app/maven/repository/org/springframework/spring-webmvc/5.2.9.RELEASE/spring-webmvc-5.2.9.RELEASE.jar!/org/springframework/web/servlet/DispatcherServlet.properties
在这里插入图片描述
继续往下看
通过getHandlerAdapter方法，我们可以看出，Adapters是通过supports方法来确定具体哪个适配器来处理。
supports的具体逻辑就不看了，因为，每个实现的adapter判断逻辑不通。

也就是说，getHandlerAdapter方法循环遍历四个adapters，通过adapter的supports方法，找到了handler对应的HandlerAdapter类。

3、通过适配器来真正调用controller接口

我们常用的是@RequestMapping类型的接口注解。
所以这里，我主要解读一下org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter
在这里插入图片描述
这里，我们可以看出ha.handle是具体的哪个adapter来实现的，从而进入对应的实现类里进行处理。
我这里肯定是进入RequestMappingHandlerAdapter类中看具体逻辑。

3.1、查看RequestMappingHandlerAdapter适配器处理逻辑

org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter#handleInternal
在这里插入图片描述
org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter#invokeHandlerMethod
这里设置参数解析器和返回值处理器。

有26个参数解析器和15个返回值处理器

执行并处理

org.springframework.web.servlet.mvc.method.annotation.ServletInvocableHandlerMethod#invokeAndHandle
通过这个名字，我们也可以看出，这里invokeForRequest就是已经处理完请求了。
在这里插入图片描述
进入invokeForRequest
关键代码找到了，getMethodArgumentValues获取方法参数值。

org.springframework.web.method.support.InvocableHandlerMethod#getMethodArgumentValues

	protected Object[] getMethodArgumentValues(NativeWebRequest request, @Nullable ModelAndViewContainer mavContainer,
			Object... providedArgs) throws Exception {

		MethodParameter[] parameters = getMethodParameters();
		if (ObjectUtils.isEmpty(parameters)) {
			return EMPTY_ARGS;
		}

		Object[] args = new Object[parameters.length];
		for (int i = 0; i < parameters.length; i++) {
			MethodParameter parameter = parameters[i];
			parameter.initParameterNameDiscovery(this.parameterNameDiscoverer);
			args[i] = findProvidedArgument(parameter, providedArgs);
			if (args[i] != null) {
				continue;
			}
			if (!this.resolvers.supportsParameter(parameter)) {
				throw new IllegalStateException(formatArgumentError(parameter, "No suitable resolver"));
			}
			try {
				args[i] = this.resolvers.resolveArgument(parameter, mavContainer, request, this.dataBinderFactory);
			}
			catch (Exception ex) {
				// Leave stack trace for later, exception may actually be resolved and handled...
				if (logger.isDebugEnabled()) {
					String exMsg = ex.getMessage();
					if (exMsg != null && !exMsg.contains(parameter.getExecutable().toGenericString())) {
						logger.debug(formatArgumentError(parameter, exMsg));
					}
				}
				throw ex;
			}
		}
		return args;
	}

首先，我们看下参数解析器规范
有两个方法
supportsParameter用来判断是否支持解析
resolveArgument用来进行具体的解析操作
在这里插入图片描述
这里用了设计模式中的组合模式
HandlerMethodArgumentResolverComposite实现了HandlerMethodArgumentResolver接口
然后，在该类中循环遍历，是否有解析器可以处理当前参数，如果有，具体怎么解析。