一、知识回顾
我们知道,接口的参数,一般都要配上注解来一起使用。
 不同的参数注解,决定了传参的方式不同。
为什么会这样?
 如果让你设计接口参数解析,你会怎么做?
首先,我们知道方法参数是形参。具体的实参是request中带来的。
 那么springboot底层是如何将path中的实参与接口的形参对应上的?
二、源码解读
首先,我们知道接口肯定是归DispatcherServlet类来管理的,所以,我们直接进入这个类
 前面的章节,我们已经知道,接口入口方法是:org.springframework.web.servlet.DispatcherServlet#doDispatch
 所以,我们进入这个方法进行断点跟踪并分析原理。
DispatcherServlet#doDispatch方法
1、找到对应request的Handler
这里的原理解释在:
 SpringBoot2:请求处理原理分析-请求Path与接口的映射关系(HandlerMapping)
 
2、找Handler的适配器

 mappedHandler.getHandler()
 这个已经拿到具体的controller了,返回类型是HandlerMehod类型
 那么,为什么不直接就反射调用了?还弄个适配器干啥?
 
 我们进入getHandlerAdapter方法
 
 这里的适配器,有4种
 
 我们在看看适配器结构
 它是一个接口,有三个方法。
 
 它有以下几个实现类
 
 这里我们会发现,实现类有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个返回值处理器
 
 26个参数解析器代码位置:
 org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter#getDefaultArgumentResolvers
 注意ServletModelAttributeMethodProcessor解析器,添加了2次
private List<HandlerMethodArgumentResolver> getDefaultArgumentResolvers() {
		List<HandlerMethodArgumentResolver> resolvers = new ArrayList<>(30);
		// Annotation-based argument resolution
		resolvers.add(new RequestParamMethodArgumentResolver(getBeanFactory(), false));
		resolvers.add(new RequestParamMapMethodArgumentResolver());
		resolvers.add(new PathVariableMethodArgumentResolver());
		resolvers.add(new PathVariableMapMethodArgumentResolver());
		resolvers.add(new MatrixVariableMethodArgumentResolver());
		resolvers.add(new MatrixVariableMapMethodArgumentResolver());
		resolvers.add(new ServletModelAttributeMethodProcessor(false));
		resolvers.add(new RequestResponseBodyMethodProcessor(getMessageConverters(), this.requestResponseBodyAdvice));
		resolvers.add(new RequestPartMethodArgumentResolver(getMessageConverters(), this.requestResponseBodyAdvice));
		resolvers.add(new RequestHeaderMethodArgumentResolver(getBeanFactory()));
		resolvers.add(new RequestHeaderMapMethodArgumentResolver());
		resolvers.add(new ServletCookieValueMethodArgumentResolver(getBeanFactory()));
		resolvers.add(new ExpressionValueMethodArgumentResolver(getBeanFactory()));
		resolvers.add(new SessionAttributeMethodArgumentResolver());
		resolvers.add(new RequestAttributeMethodArgumentResolver());
		// Type-based argument resolution
		resolvers.add(new ServletRequestMethodArgumentResolver());
		resolvers.add(new ServletResponseMethodArgumentResolver());
		resolvers.add(new HttpEntityMethodProcessor(getMessageConverters(), this.requestResponseBodyAdvice));
		resolvers.add(new RedirectAttributesMethodArgumentResolver());
		resolvers.add(new ModelMethodProcessor());
		resolvers.add(new MapMethodProcessor());
		resolvers.add(new ErrorsMethodArgumentResolver());
		resolvers.add(new SessionStatusMethodArgumentResolver());
		resolvers.add(new UriComponentsBuilderMethodArgumentResolver());
		// Custom arguments
		if (getCustomArgumentResolvers() != null) {
			resolvers.addAll(getCustomArgumentResolvers());
		}
		// Catch-all
		resolvers.add(new RequestParamMethodArgumentResolver(getBeanFactory(), true));
		resolvers.add(new ServletModelAttributeMethodProcessor(true));
		return resolvers;
	}
 

 15个返回值处理器代码位置
 org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter#getDefaultReturnValueHandlers
private List<HandlerMethodReturnValueHandler> getDefaultReturnValueHandlers() {
		List<HandlerMethodReturnValueHandler> handlers = new ArrayList<>(20);
		// Single-purpose return value types
		handlers.add(new ModelAndViewMethodReturnValueHandler());
		handlers.add(new ModelMethodProcessor());
		handlers.add(new ViewMethodReturnValueHandler());
		handlers.add(new ResponseBodyEmitterReturnValueHandler(getMessageConverters(),
				this.reactiveAdapterRegistry, this.taskExecutor, this.contentNegotiationManager));
		handlers.add(new StreamingResponseBodyReturnValueHandler());
		handlers.add(new HttpEntityMethodProcessor(getMessageConverters(),
				this.contentNegotiationManager, this.requestResponseBodyAdvice));
		handlers.add(new HttpHeadersReturnValueHandler());
		handlers.add(new CallableMethodReturnValueHandler());
		handlers.add(new DeferredResultMethodReturnValueHandler());
		handlers.add(new AsyncTaskMethodReturnValueHandler(this.beanFactory));
		// Annotation-based return value types
		handlers.add(new ModelAttributeMethodProcessor(false));
		handlers.add(new RequestResponseBodyMethodProcessor(getMessageConverters(),
				this.contentNegotiationManager, this.requestResponseBodyAdvice));
		// Multi-purpose return value types
		handlers.add(new ViewNameMethodReturnValueHandler());
		handlers.add(new MapMethodProcessor());
		// Custom return value types
		if (getCustomReturnValueHandlers() != null) {
			handlers.addAll(getCustomReturnValueHandlers());
		}
		// Catch-all
		if (!CollectionUtils.isEmpty(getModelAndViewResolvers())) {
			handlers.add(new ModelAndViewResolverMethodReturnValueHandler(getModelAndViewResolvers()));
		}
		else {
			handlers.add(new ModelAttributeMethodProcessor(true));
		}
		return handlers;
	}
 
执行并处理
 
 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接口
 然后,在该类中循环遍历,是否有解析器可以处理当前参数,如果有,具体怎么解析。
关键代码行
 args[i] = this.resolvers.resolveArgument(parameter, mavContainer, request, this.dataBinderFactory);
 通过断点,我们可以看出,此时args[i]被赋值了。
继续进入this.resolvers.resolveArgument查看逻辑
 
 
 99行,获取形参名,108行才是给形参赋值。
 所以,在108行之前,都是解析接口方法形参。
 我们在看下resolveName方法,可以看到,这个方法有很多具体的实现类。
 我这里以PathVariable为例子。
 
 org.springframework.web.servlet.mvc.method.annotation.PathVariableMethodArgumentResolver#resolveName
 
 可以看出,给形参名的值,是从request中获取到的。这样,形参和实参就对应上了。
 那么,这里的request.getAttribute是如何处理好的,这里没有说明。
 网上说是通过org.springframework.web.util.UrlPathHelper类实现的。
 具体有兴趣的同学自己去研究一下。
那么,到这里,源码逻辑就差不多结束了。
三、逻辑梳理
首先,请求接口进入DispatcherServlet#doDispatch方法
先从handlerMapping中获取具体的handler,即找到具体是哪个controller来处理请求。
 而handlerMapping类型默认配置了5种。
找到对应的handler后,在找到对应的handlerAdapter
 handlerAdapters适配器类型默认配置了4种。
再然后,通过具体的handlerAdapter来解析方法参数
 而解析方法参数,用到了参数解析器argumentResolvers
 这里,参数解析器,配置了26种。
 并且用了组合模式+缓存来优化性能。
遍历循环参数解析器,找到对应参数的解析器后
 在通过接口方法的形参信息,如参数类型,参数名称,参数注解等。
 进行具体的参数解析,并从request中获取实参值,赋值给形参,完成参数解析。



















