SpringMVC常用注解载入与处理方式详解-Java开发

这篇文章主要介绍了SpringMVC常用注解载入的方式和处理的方式，文中示例代码介绍的非常详细，具有一定的参考价值，感兴趣的小伙伴们可以参考一下

一 . 前言

这一篇来看一下SpringMVC 中各个注解载入的方式和处理的时机

二 . RestController 部分

RestController 注解主要的作用是Bean的加载 , 值得关注的注解包括 : @Controller 和 @ResponseBody

而 Contoller 注解携带 @Component , 所以主要执行的位置是 Bean 处理 .

在 Bean 处理过程中 , 主要是在 RequestMappingHandlerMapping 中对 @RequestMapping 进行扫描处理

//C- AbstractHandlerMethodMapping # initHandlerMethods :  一切的起点 , 开始对所有需要扫描的 Bean 进行处理
protected void initHandlerMethods() {
   for (String beanName : getCandidateBeanNames()) {
      if (!beanName.startsWith(SCOPED_TARGET_NAME_PREFIX)) {
         // 后续会进行 Registry 对 Mapping 进行注册 
         processCandidateBean(beanName);
      }
   }
   // 主要是 log 处理 , 可以重写
   handlerMethodsInitialized(getHandlerMethods());
}

总结 : RestController 主要用于把Bean注入到 Spring 体系中 , 触发 Mapping 扫描

三 . RequestMapping 部分

上面触发了 Mapping 的加载后 , 就会通过 Registry 把 Mapping 注册到集合中 , 先大概过一下流程

// S1 : AbstractHandlerMethodMapping # detectHandlerMethods : 逐一对Bean进行扫描处理
- MethodIntrospector.selectMethods 扫描所有的 Method , 获取 Map<Method, T>
- methods.forEach 调用 registerHandlerMethod 对 Method 进行注册
// S2 : AbstractHandlerMethodMapping # register : 注册 Handler 和 Method 到各个集合中
- 这里之前说过 , 有多个 Mapping 用来保存 Handler 的映射关系
- this.mappingLookup.put(mapping, handlerMethod);
- this.urlLookup.add(url, mapping);
- this.corsLookup.put(handlerMethod, corsConfig);
// S3 : AbstractHandlerMethodMapping # lookupHandlerMethod : 对 URL 进行解析 , 寻找对应的 Mapping
- this.mappingRegistry.getMappingsByUrl(lookupPath);

S1 : @RequestMapping 注解的载入

注解在上文S1阶段就已经被载入了 , 在扫描所有的Mapping的时候进行了 RequestMapping 的解析

// S1-1 : 获取到 Mathod 之上的注解
RequestMapping requestMapping = AnnotatedElementUtils.findMergedAnnotation(element, RequestMapping.class);
// S1-2 : 通过 Mapping 创建 MappingInfo
createRequestMappingInfo(requestMapping, condition)
RequestMappingInfo.Builder builder = RequestMappingInfo
    .paths(resolveEmbeddedValuesInPatterns(requestMapping.path()))
    .methods(requestMapping.method())
    .params(requestMapping.params())
    .headers(requestMapping.headers())
    .consumes(requestMapping.consumes())
    .produces(requestMapping.produces())
    .mappingName(requestMapping.name());
    // 此处对注解上的参数进行解析
builder.options(this.config).build()
// S3 : 构建 AbstractRequestCondition 
细节就不看了 , 主要是构建 ParamsRequestCondition , ConsumesRequestCondition 等 放入 RequestMappingInfo 对象中

S3 : RequestMapping 的使用

// S3-1 : AbstractHandlerMethodMapping # lookupHandlerMethod : 通过 path 查询 Mapping
List<T> directPathMatches = this.mappingRegistry.getMappingsByUrl(lookupPath);
// S3-2 : addMatchingMappings 添加 HandlerMethod
addMatchingMappings(this.mappingRegistry.getMappings().keySet(), matches, request);

以下2个图分别是请求的匹配Condition和HandlerMethod中描述的处理类 , 这样的集合在 S2 环节注入>>

private final Map<T, MappingRegistration<T>> registry = new HashMap<>();
private final Map<T, HandlerMethod> mappingLookup = new LinkedHashMap<>();
private final MultiValueMap<String, T> urlLookup = new LinkedMultiValueMap<>();
private final Map<String, List<HandlerMethod>> nameLookup = new ConcurrentHashMap<>();
private final Map<HandlerMethod, CorsConfiguration> corsLookup = new ConcurrentHashMap<>();
private final ReentrantReadWriteLock readWriteLock = new ReentrantReadWriteLock();

总结:RequestMapping 主要在Bean扫描时触发 >>>

当获取到 Bean 中 Mehtod 时 , 会创建对应的 RequestMappingInfo , 存入多个集合中
当请求进来后 , 会在 lookupHandlerMethod 中获取对应Method 处理类**

四 . RequestParam和PathVariable

这是最常用的2个参数传递方式 , 主要的加载类为 : RequestParamMethodArgumentResolver

RequestParam 处理流程

// S1 : RequestMappingHandlerAdapter # invokeAndHandle : 发起方法的调用
- 此处为参数处理的入口 , 当请求进来时 , 会代理到对应的方法 , 在代理的过程中进行处理
// S2 : InvocableHandlerMethod # getMethodArgumentValues : 循环方法中所有的参数
- getMethodArgumentValues 中会对 Bean 加载时即生成的 HandMethod 进行处理
// S3 : HandlerMethodArgumentResolverComposite # getArgumentResolver : 对所有解析类进行处理
- for 循环进行的处理
- 解析类用来解析参数上面的注解 , 判断是否符合某种注解的解析条件
- 包括 PathVariable 等多种注解的解析
// S4 : RequestParamMethodArgumentResolver # supportsParameter : 判断是否包含 RequestParam 注解
- 如果符合解析条件 , 把 MethodParameter 和 resolver 都放在缓存中
// S5 : RequestParamMethodArgumentResolver # resolveArgument : 对参数进行解析

PathVariable 处理流程

PathVariable 和上面的流程一样 , 主要在 S3 进行处理

总结 :RequestParam 和 PathVariable 主要还是在实际调用 Invoke 方法时解析处理

调用代理方法时会对所有的参数进行解析 >> S1
解析通过 support + resolve 两步完成 , 也就是策略
解析完成后放入 Object[] 再调用具体的 Method

五 . RequestBody 和 ResponseBody

核心加载类 : RequestResponseBodyMethodProcessor , 其实主要流程和上文比较类似 , 只不过该类在调用和返回时都有相关的调用

RequestBody

// S1 : 判断是否需要解析
public boolean supportsParameter(MethodParameter parameter) {
    return parameter.hasParameterAnnotation(RequestBody.class);
}
// S2 : 解析数据 resolveArgument
// 这里就不细说了 , 就是一个 Converters

ResponseBody

public void handleReturnValue(@Nullable Object returnValue, MethodParameter returnType,
			ModelAndViewContainer mavContainer, NativeWebRequest webRequest){}
//- 返回值 , 返回类型 , Model 上下文等

开关的处理

// 问题一 : 加了 ResponseBody 后为什么可以不用跳 View
- 过去前后不分离的场景 , 通常会通过一个 View 来接收跳转地址到对应的 HTML 页面
- 但是加了 ResponseBody 后则可以直接返回出去
? 如何处理的 :
handleReturnValue 中 mavContainer.setRequestHandled(true) :
> 当设置了 ResponseBody 后 , view resolution is not argument
> 当后文 getModelAndView 时会根据这个参数直接返回 null