Spring6源码・MVC请求处理流程源码解析

Posted 2023-03-29 步尔斯特

上一篇《【Spring6源码・MVC】初始化registry，完成url和controller的映射关系》我们知道，在IOC容器加载的同时，初始化了registry这个HashMap，这个HashMap中存放了请求路径和对应的方法。当我们请求进来，会通过这个registry去获取对应的方法。

在SpringBoot项目启动的时候，会加载一个线程：

步入run方法：

步入run方法：

当前这个类是Worker：Class Worker 主要维护运行任务的线程的中断控制状态，以及其他次要簿记。此类适时地扩展了 AbstractQueuedSyncer，以简化获取和释放围绕每个任务执行的锁。这可以防止旨在唤醒等待任务的工作线程而不是中断正在运行的任务的中断。我们实现了一个简单的非重入互斥锁，而不是使用 ReentrantLock，因为我们不希望工作线程任务在调用池控制方法（如 setCorePoolSize）时能够重新获取锁。此外，为了在线程实际开始运行任务之前抑制中断，我们将锁定状态初始化为负值，并在启动时清除它（在 runWorker 中）。

这个run方法主要是启动主运行循环，以此从队列中取出task执行。

Spring MVC注解Controller源码流程解析---请求匹配中的容错处理

Spring MVC注解Controller源码流程解析---请求匹配中的容错处理

• 引言
• spring mvc对于请求路径匹配过程中的容错处理
• • 请求匹配过程分析
  • • 溯源和请求前缀设置
• Springboot中如何修改springmvc相关配置
• • 通过代理完成对默认组件修改

---

引言

Spring MVC注解Controller源码流程解析–映射建立

Spring MVC注解Controller源码流程解析–定位HandlerMethod

前面两篇已经对注解版本Controller中映射建立和定位HandlerMethod的过程进行了详细的解析，但是在定位HandlerMethod的过程中，其实有一个小知识没有讲，是关于请求匹配部分细节内容，了解这部分内容可以帮助我们更好弄清楚spring mvc在请求路径匹配问题上的一些优化处理，避免写业务代码过程中犯错。

---

spring mvc对于请求路径匹配过程中的容错处理

在Spring MVC注解Controller源码流程解析–定位HandlerMethod章节讲到过，当一个请求发出来时，首先会被RequestMappingHandlerMapping拦截，然后调用lookupHandlerMethod方法，去寻找能够处理当前请求的HandlerMethod。

而在lookupHandlerMethod方法中，又会在addMatchingMappings方法中，通过间接调用RequestMappingInfo的getMatchingCondition方法，通过RequestMappingInfo自身保存的各类条件信息对当前request请求进行匹配，如果其中有一个条件不满足，那么直接返回null,不会加入matches集合中去。

在众多条件匹配过程中，与本节相关的就是路径条件匹配，如下:

		PatternsRequestCondition patterns = null;
		if (this.patternsCondition != null) 
			patterns = this.patternsCondition.getMatchingCondition(request);
			if (patterns == null) 
				return null;
			
		

所以，关键加在于patternsCondition.getMatchingCondition方法，该方法内部到底为我们的请求路径匹配做了哪些容错处理。

---

请求匹配过程分析

	public PatternsRequestCondition getMatchingCondition(HttpServletRequest request) 
	    //简单的取出request对象属性集合中的PATH_ATTRIBUTE属性
	    //该属性是在AbstractHandlerMethodMapping#getHandlerInternal方法初始解析请求路径完成后,被放入request属性集合中去的
	    //lookuppath默认是去除掉context-path后剩下的路径 
		String lookupPath = UrlPathHelper.getResolvedLookupPath(request);
		//拿着lookuppath与当前patternsCondition内部的patterns属性集合进行匹配
		List<String> matches = getMatchingPatterns(lookupPath);
		//返回的结果也就是匹配上patterns集合中的哪些请求路径
		return !matches.isEmpty() ? new PatternsRequestCondition(new LinkedHashSet<>(matches), this) : null;
	

可以看出来，getMatchingPatterns(lookupPath) 方法才是请求匹配过程中的核心:

	public List<String> getMatchingPatterns(String lookupPath) 
		List<String> matches = null;
		//遍历内部的patterns集合,也就是@RequestMapping注解中我们设置的patterns或者默认value属性值
		//一个@RequestMapping注解中可以写多个请求路径映射
		for (String pattern : this.patterns) 
		     //进行挨个匹配，没匹配上,返回null
			String match = getMatchingPattern(pattern, lookupPath);
			//匹配上了，加入match集合
			if (match != null) 
				matches = (matches != null ? matches : new ArrayList<>());
				matches.add(match);
			
		
		//如果集合为空,返回空集合
		if (matches == null) 
			return Collections.emptyList();
		
		//如果存在多个路径匹配上了，那么需要进行路径排序，让最佳匹配放在最前面
		if (matches.size() > 1) 
			matches.sort(this.pathMatcher.getPatternComparator(lookupPath));
		
		return matches;
	

spring mvc对于路径匹配上提供的容错处理，其实就体现在了getMatchingPattern方法中，我们下面来具体看看:

	@Nullable
	private String getMatchingPattern(String pattern, String lookupPath) 
	   //如果是精确匹配上了,那么直接返回
		if (pattern.equals(lookupPath)) 
			return pattern;
		
		//是否开启后缀匹配---默认是关闭的
		if (this.useSuffixPatternMatch) 
		    //fileExtensions是我们可以设置的后缀集合,例如: .doc ; .html ; .js ; .do等后缀集合
		    //当前请求必须是存在后缀的
			if (!this.fileExtensions.isEmpty() && lookupPath.indexOf('.') != -1) 
				for (String extension : this.fileExtensions) 
				   //如果设置了相关后缀,那么尝试让当前pattern加上后缀后,在于当前请求路径进行模糊匹配
				   //这里采用的是pathMatcher--实际是AntPathMatcher,会进行ant风格路径匹配
					if (this.pathMatcher.match(pattern + extension, lookupPath)) 
						return pattern + extension;
					
				
			
			else 
			//如果我们没有指定后缀集合
			//那么先判断当前请求是否存在后缀
				boolean hasSuffix = pattern.indexOf('.') != -1;
				//利用.*后缀进行ant风格匹配
				if (!hasSuffix && this.pathMatcher.match(pattern + ".*", lookupPath)) 
					return pattern + ".*";
				
			
		
		//进行ant风格路径匹配,例如: *,?等符合
		if (this.pathMatcher.match(pattern, lookupPath)) 
			return pattern;
		
		//useTrailingSlashMatch功能是默认开启的，该功能的可以让我们使用/hello/请求也能匹配上/hello请求
		if (this.useTrailingSlashMatch) 
		     //如果pattern不是以/结尾的,那么尝试加上/之后，再去匹配当前请求路径
			if (!pattern.endsWith("/") && this.pathMatcher.match(pattern + "/", lookupPath)) 
				return pattern + "/";
			
		
		return null;
	

getMatchingPattern中完成了ant风格路径匹配,后缀匹配(默认不开启),useTrailingSlashMatch匹配等容错处理。

---

溯源和请求前缀设置

关于useSuffixPatternMatch和useTrailingSlashMatch属性的提供，其实是在RequestMappingHandlerMapping中提供的:

我们可以看到RequestMappingHandlerMapping中还给我们提供了一个pathPrefixs的设置，那么该属性集合的作用是什么呢？

还记得在映射建立的过程中，我们需要为当前方法生成一个生成一个映射的接口吗？

不清楚，回看: Spring MVC注解Controller源码流程解析–映射建立

	@Override
	@Nullable
	protected RequestMappingInfo getMappingForMethod(Method method, Class<?> handlerType) 
		RequestMappingInfo info = createRequestMappingInfo(method);
		if (info != null) 
			RequestMappingInfo typeInfo = createRequestMappingInfo(handlerType);
			if (typeInfo != null) 
				info = typeInfo.combine(info);
			
			//判断我们是否给当前handler设置了前缀
			String prefix = getPathPrefix(handlerType);
			if (prefix != null) 
			//如果确实设置了前缀,那么:
			//先为当前前缀简单创建一个ReuqestMappingInfo: 
			//RequestMappingInfo.paths(prefix).options(this.config).build()
			//然后再与当前RequestMappingInfo合并
			//这里合并的主要就是请求路径了，会将请求前缀加在当前请求路径的前面
				info = RequestMappingInfo.paths(prefix).options(this.config).build().combine(info);
			
		
		return info;
	

RequestMappingInfo封装的是请求匹配条件，而所谓的combine合并过程，就是将请求匹配条件进行合并。

---

获取请求前缀的过程其实也没有那么直接，也会经过一些处理:

	@Nullable
	String getPathPrefix(Class<?> handlerType) 
	    //遍历请求前缀集合
		for (Map.Entry<String, Predicate<Class<?>>> entry : this.pathPrefixes.entrySet()) 
			//判断当前请求前缀对应的handler类型是否与传入的一致--》由于这里test其实是一个函数式接口
			//因此，我们完全可以将一个请求前缀与多个handler相对应，将匹配逻辑写在函数式接口中即可
		    //只需要确保当前传入的handler类型匹配上我们提供的某个handler时，返回true即可
			if (entry.getValue().test(handlerType)) 
				String prefix = entry.getKey();
				//返回请求前缀时，会经过el解析器解析,因此请求前缀中也可以包含el表达式
				if (this.embeddedValueResolver != null) 
					prefix = this.embeddedValueResolver.resolveStringValue(prefix);
				
				return prefix;
			
		
		return null;
	

---

Springboot中如何修改springmvc相关配置

我们上面讲的那些属性和前缀集合如何在springboot环境下进行修改呢？

我们可以通过继承WebMVCConfigure接口，然后重写其对应的默认方法，完成修改:

@Configuration
@RequiredArgsConstructor
public class MvcConfig implements WebMvcConfigurer
    
    @Override
    public void configurePathMatch(PathMatchConfigurer configurer) 
        configurer.setUseSuffixPatternMatch(true);
        configurer.addPathPrefix("/back",handlerType ->
           return handlerType.equals(AdminController.class); 
        );
    

不知道，大家有没有想过，为什么我们实现了WebMvcConfigurer接口，然后将该bean注入容器，就可以完成对Spring mvc想过组件的修改呢?

这里我简单带领大家过一下源码，看看其中的原理大概是什么样的:

---

通过代理完成对默认组件修改

• WebMvcConfigurerComposite： 内部通过一个List集合管理多个WebMvcConfigurer，实现了WebMvcConfigurer接口，并重写了该接口内部的所有方法，每个重写方法的实现逻辑一致，如下:
  

	@Override
	public void configurePathMatch(PathMatchConfigurer configurer) 
		for (WebMvcConfigurer delegate : this.delegates) 
			delegate.configurePathMatch(configurer);
		
	

就是将方法，代理给内部集合中每一个WebMvcConfigurer进行处理。

• DelegatingWebMvcConfiguration：内部维护了一个WebMvcConfigurerComposite，会搜集所有注入到容器中的WebMvcConfigurer实现类，然后都加入到WebMvcConfigurerComposite的集合中去
  

DelegatingWebMvcConfiguration继承了WebMvcConfigurationSupport类，该类是完成SpringBoot中完成SpringMVC相关组件默认配置的核心，该类内部对RequestMappingHandlerMapping 的配置代码如下:

	@Bean
	@SuppressWarnings("deprecation")
	public RequestMappingHandlerMapping requestMappingHandlerMapping(
			@Qualifier("mvcContentNegotiationManager") ContentNegotiationManager contentNegotiationManager,
			@Qualifier("mvcConversionService") FormattingConversionService conversionService,
			@Qualifier("mvcResourceUrlProvider") ResourceUrlProvider resourceUrlProvider) 

		RequestMappingHandlerMapping mapping = createRequestMappingHandlerMapping();
		mapping.setOrder(0);
		//其他配置不看，就以拦截器配置为例，我们看看具体是如何完成拦截器配置的，以及如何暴露给用户自定义添加拦截器的接口的
		mapping.setInterceptors(getInterceptors(conversionService, resourceUrlProvider));
        ...         
		return mapping;
	

	protected final Object[] getInterceptors(
			FormattingConversionService mvcConversionService,
			ResourceUrlProvider mvcResourceUrlProvider) 

		if (this.interceptors == null) 
			InterceptorRegistry registry = new InterceptorRegistry();
			//该方法是暴露给用户增加拦截器的钩子函数
			addInterceptors(registry);
			registry.addInterceptor(new ConversionServiceExposingInterceptor(mvcConversionService));
			registry.addInterceptor(new ResourceUrlProviderExposingInterceptor(mvcResourceUrlProvider));
			this.interceptors = registry.getInterceptors();
		
		return this.interceptors.toArray();
	

addInterceptors钩子函数在WebMvcConfigurationSupport中是空实现，子类DelegatingWebMvcConfiguration实现了该钩子方法。

	@Override
	protected void addInterceptors(InterceptorRegistry registry) 
		this.configurers.addInterceptors(registry);
	

到这里，我相信各位应该都基本明白了，我们为什么能够通过实现WebMvcConfigurer接口修改springmvc的配置了吧。

---