封面:学校篮球场上的云
纸上得来终觉浅,绝知此事要躬行
注意
: 本文 SpringBoot 版本为 2.5.2; JDK 版本 为 jdk 11.
后续文章👉 从浏览器发送请求给SpringBoot后端时,是如何准确找到哪个接口的?(下篇)
在写文章的时候,我都会习惯性的记录下,是什么因素促使我去写的这篇文章。并竟对于感兴趣的东西,写起来也上心,也更得心应手,文章质量相应也更高。当然更多的是想和更多人分享自己的看法,与更多的人一起交流。“三人行,必有我师焉” ,欢迎大家留言评论交流。
写这篇文章的原因是在于昨天一个学 Go 语言的后端小伙伴,问了我一个问题。
问题大致如下:
为什么浏览器向后端发起请求时,就知道要找的是哪一个接口?采用了什么样的匹配规则呢? SpringBoot 后端是如何存储 API 接口信息的?又是拿什么数据结构存储的呢?
@ResponseBody
@GetMapping("/test")
public String test(){
return "test";
}
说实话,听他问完,我感觉我又不够卷了,简直灵魂拷问,我一个答不出来。我们一起去看看吧。
我对于SpringBoot的框架源码阅读经验可能就一篇👉SpringBoot自动装配原理算是吧,所以在一定程度上我个人对于SpringBoot 框架理解的还是非常浅显的。
如果文章中有不足之处,请你一定要及时批正!在此郑重感谢。
在java体系中,类是可以被继承,接口可以被实现。但是注解没有这些概念,而是有一个派生的概念。举例,注解A。被标记了在注解B头上,那么我们可以说注解B就是注解A的派生。
如:
就像 注解 @GetMapping
上就还有一个 @RequestMapping(method = RequestMethod.GET)
,所以我们本质上也是使用了 @RequestMapping
注解。
@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@RequestMapping(method = RequestMethod.GET)
public @interface GetMapping {
}
还有 @Controller 和 @RestController 也是如此。
@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Controller
@ResponseBody
public @interface RestController {
}
废话不多说,直接肝啦。
更前面的不去做探究了,我们直接到这个入口处。
做了一个大致的分析流程图给大家做参考,也是我个人探究的路线。
/** HandlerMapping实现的抽象基类,定义了请求和HandlerMethod之间的映射。
对于每个注册的处理程序方法,一个唯一的映射由定义映射类型<T>细节的子类维护
*/
public abstract class AbstractHandlerMethodMapping<T> extends AbstractHandlerMapping implements InitializingBean {
// ...
/**在初始化时检测处理程序方法。 可以说是入口处啦*/
@Override
public void afterPropertiesSet() {
initHandlerMethods();
}
/**扫描 ApplicationContext 中的 bean,检测和注册处理程序方法。 */
protected void initHandlerMethods() {
//getCandidateBeanNames() :确定应用程序上下文中候选 bean 的名称。
for (String beanName : getCandidateBeanNames()) {
if (!beanName.startsWith(SCOPED_TARGET_NAME_PREFIX)) {
//确定指定候选 bean 的类型,如果标识为处理程序类型,则调用detectHandlerMethods
// 这里的处理程序 就为我们在controller 中书写的那些接口方法
processCandidateBean(beanName);
}
}
// 这里的逻辑不做讨论啦
handlerMethodsInitialized(getHandlerMethods());
}
// ...
}
只有当扫描到 是由@RestController 或@RequestMapping 注解修饰时,进入 processCandidateBean
方法,这个时候才是我们要找的东西。其他的bean我们不是我们讨论的点,不做讨论。
我们来接着看看 processCandidateBean
的处理逻辑,它做了一些什么事情。
/** 确定指定候选 bean 的类型,如果标识为处理程序类型,则调用detectHandlerMethods 。 */
protected void processCandidateBean(String beanName) {
Class<?> beanType = null;
try {
// 确定注入的bean 类型
beanType = obtainApplicationContext().getType(beanName);
}
catch (Throwable ex) {
// 无法解析的bean
if (logger.isTraceEnabled()) {
logger.trace("Could not resolve type for bean '" + beanName + "'", ex);
}
}
//isHandler 方法判断是否是web资源类。
if (beanType != null && isHandler(beanType)) {
// 算是这条线路上重点啦
detectHandlerMethods(beanName);
}
}
isHandler 方法判断是否是web资源类。当一个类被标记了 @Controller 或者@RequestMapping。 注意 @RestController 是@Controller的派生类。所以这里只用判断 @Controller 或者@RequestMapping就行了。
另外 isHandler 定义在 AbstractHandlerMethodMapping< T > ,实现在 RequestMappingHandlerMapping
/**
给定类型是否是具有处理程序方法的处理程序。处理程序就是我们写的 Controller 类中的接口方法
期望处理程序具有类型级别的Controller注释或类型级别的RequestMapping注释。
*/
@Override
protected boolean isHandler(Class<?> beanType) {
return (AnnotatedElementUtils.hasAnnotation(beanType, Controller.class) ||
AnnotatedElementUtils.hasAnnotation(beanType, RequestMapping.class));
}
继续往下:
这个方法detectHandlerMethods(beanName);
它是做什么的呢?
它的方法注释为:在指定的处理程序 bean 中查找处理程序方法。
其实 detectHandlerMethods
方法就是真正开始解析Method的逻辑。通过解析Method上的@RequestMapping
或者其他派生的注解。生成请求信息。
/** 在指定的处理程序 bean 中查找处理程序方法。*/
protected void detectHandlerMethods(Object handler) {
Class<?> handlerType = (handler instanceof String ?
obtainApplicationContext().getType((String) handler) : handler.getClass());
if (handlerType != null) {
//返回给定类的用户定义类:通常只是给定的类,但如果是 CGLIB 生成的子类,则返回原始类。
Class<?> userType = ClassUtils.getUserClass(handlerType);
//selectMethods:
//根据相关元数据的查找,选择给定目标类型的方法。
// 调用者通过MethodIntrospector.MetadataLookup参数定义感兴趣的方法,允许将关联的元数据收集到结果映射中
// 简单理解 :解析RequestMapping信息
Map<Method, T> methods = MethodIntrospector.selectMethods(userType,
(MethodIntrospector.MetadataLookup<T>) method -> {
try {
//为处理程序方法提供映射。 不能为其提供映射的方法不是处理程序方法
return getMappingForMethod(method, userType);
}
catch (Throwable ex) {
throw new IllegalStateException("Invalid mapping on handler class [" +
userType.getName() + "]: " + method, ex);
}
});
if (logger.isTraceEnabled()) {
logger.trace(formatMappings(userType, methods));
}
else if (mappingsLogger.isDebugEnabled()) {
mappingsLogger.debug(formatMappings(userType, methods));
}
// 这里将解析的信息,循环进行注册
methods.forEach((method, mapping) -> {
Method invocableMethod = AopUtils.selectInvocableMethod(method, userType);
registerHandlerMethod(handler, invocableMethod, mapping);
});
}
}
getMappingForMethod定义在 AbstractHandlerMethodMapping< T > ,实现在 RequestMappingHandlerMapping 类下
这里简单说就是 将类层次的RequestMapping和方法级别的RequestMapping结合 (createRequestMappingInfo)
/** 使用方法和类型级别的RequestMapping注解来创建RequestMappingInfo。 */
@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);
}
//获取类上
String prefix = getPathPrefix(handlerType);
if (prefix != null) {
info = RequestMappingInfo.paths(prefix).options(this.config).build().combine(info);
}
}
return info;
}
createRequestMappingInfo:
/**
委托createRequestMappingInfo(RequestMapping, RequestCondition) ,根据提供的annotatedElement是类还是方法提供适当的自定义RequestCondition 。
*/
@Nullable
private RequestMappingInfo createRequestMappingInfo(AnnotatedElement element) {
//主要是 解析 Method 上的 @RequestMapping 信息
RequestMapping requestMapping = AnnotatedElementUtils.findMergedAnnotation(element, RequestMapping.class);
RequestCondition<?> condition = (element instanceof Class ?
getCustomTypeCondition((Class<?>) element) : getCustomMethodCondition((Method) element));
return (requestMapping != null ? createRequestMappingInfo(requestMapping, condition) : null);
}
根据相关元数据的查找,选择给定目标类型的方法。
很多杂七杂八的东西在里面,很难说清楚,这里只简单说了一下。
public static <T> Map<Method, T> selectMethods(Class<?> targetType, final MetadataLookup<T> metadataLookup) {
final Map<Method, T> methodMap = new LinkedHashMap<>();
Set<Class<?>> handlerTypes = new LinkedHashSet<>();
Class<?> specificHandlerType = null;
if (!Proxy.isProxyClass(targetType)) {
specificHandlerType = ClassUtils.getUserClass(targetType);
handlerTypes.add(specificHandlerType);
}
handlerTypes.addAll(ClassUtils.getAllInterfacesForClassAsSet(targetType));
for (Class<?> currentHandlerType : handlerTypes) {
final Class<?> targetClass = (specificHandlerType != null ? specificHandlerType : currentHandlerType);
//对给定类和超类(或给定接口和超接口)的所有匹配方法执行给定的回调操作。
ReflectionUtils.doWithMethods(currentHandlerType, method -> {
Method specificMethod = ClassUtils.getMostSpecificMethod(method, targetClass);
T result = metadataLookup.inspect(specificMethod);
if (result != null) {
// BridgeMethodResolver :给定一个合成bridge Method返回被桥接的Method 。
//当扩展其方法具有参数化参数的参数化类型时,编译器可能会创建桥接方法。 在运行时调用期间,可以通过反射调用和/或使用桥接Method
//findBridgedMethod : 找到提供的bridge Method的原始方法。
Method bridgedMethod = BridgeMethodResolver.findBridgedMethod(specificMethod);
if (bridgedMethod == specificMethod || metadataLookup.inspect(bridgedMethod) == null) {
methodMap.put(specificMethod, result);
}
}
}, ReflectionUtils.USER_DECLARED_METHODS);
}
return methodMap;
}
方法上的doc注释:
根据相关元数据的查找,选择给定目标类型的方法。 调用者通过MethodIntrospector.MetadataLookup参数定义感兴趣的方法,允许将关联的元数据收集到结果映射中
一眼两言说不清楚,直接贴一张debug 的图片给大家看一下。
这一段代码其本质就是 这里将解析出来的信息,循环进行注册
methods.forEach((method, mapping) -> {
//选择目标类型上的可调用方法:如果实际公开在目标类型上,则给定方法本身,或者目标类型的接口之一或目标类型本身上的相应方法。
// 简单理解返回个方法吧
Method invocableMethod = AopUtils.selectInvocableMethod(method, userType);
registerHandlerMethod(handler, invocableMethod, mapping);
});
protected void registerHandlerMethod(Object handler, Method method, T mapping) {
this.mappingRegistry.register(mapping, handler, method);
}
这里的 this.mappingRegistry
是 AbstractHandlerMethodMapping<T>
的一个内部类。
MappingRegistry
: doc注释:一个注册表,它维护到处理程序方法的所有映射,公开执行查找的方法并提供并发访问。
对于它的结构,在这里不做探讨啦。感兴趣,可以点进去继续看看。
我们继续探究我们 register
方法做了什么
public void register(T mapping, Object handler, Method method) {
this.readWriteLock.writeLock().lock();
try {
//创建 HandlerMethod 实例。
HandlerMethod handlerMethod = createHandlerMethod(handler, method);
//验证方法映射
validateMethodMapping(handlerMethod, mapping);
//这里就是直接获取路径 mapping 的值是 GET[/login]
// 获取出来后 就是 /login
Set<String> directPaths = AbstractHandlerMethodMapping.this.getDirectPaths(mapping);
for (String path : directPaths) {
//this.pathLookup 它的定义如下:
// private final MultiValueMap<String, T> pathLookup = new LinkedMultiValueMap<>();
// 其实new 就是一个 new LinkedHashMap<>();
// 这里就是将 path 作为key ,mapping作为value 存起来
this.pathLookup.add(path, mapping);
}
String name = null;
// 这里的意思可以归纳为:
if (getNamingStrategy() != null) {
///确定给定 HandlerMethod 和映射的名称。
name = getNamingStrategy().getName(handlerMethod, mapping);
addMappingName(name, handlerMethod);
}
// 下面几行是处理跨域问题的,不是我们本章讨论的。大家感兴趣可以去看看。
CorsConfiguration corsConfig = initCorsConfiguration(handler, method, mapping);
if (corsConfig != null) {
corsConfig.validateAllowCredentials();
this.corsLookup.put(handlerMethod, corsConfig);
}
this.registry.put(mapping,
new MappingRegistration<>(mapping, handlerMethod, directPaths, name, corsConfig != null));
}
finally {
this.readWriteLock.writeLock().unlock();
}
}
this.registry.put(mapping,
new MappingRegistration<>(mapping, handlerMethod, directPaths, name, corsConfig != null));
这里的 this.registry
的定义如下:private final Map<T, MappingRegistration<T>> registry = new HashMap<>();
不同的方法走到这,其实差别不是很大
其实看完这个启动流程,对于我们刚开始的三个问题,我们大概率可以找到其中两个答案了。
你们 SpringBoot 后端框架是如何存储API接口的信息的?是拿什么数据结构存储的呢?
第一个答案:大致就是和MappingRegistry
这个注册表类相关.
第二个答案:我们之前看到存储信息时,都是 HashMap
相关的类来存储的,那么我们可以知道它底层的数据结构就是 数组+链表+红黑树
注意
: 本文 SpringBoot 版本为 2.5.2;JDK 版本 为 jdk 11.
并未针对多个版本进行比较,但是推测下来,多半都是如此.
那么我们的下一步就是去查看 SpringBoot 请求时,是如何找到 对应的 接口的。哪里才又是我们的一个重点。
后续文章👉从浏览器发送请求给SpringBoot后端时,是如何准确找到哪个接口的?
若不是小伙伴提起那三问,我想我也不会有如此兴致,去一步一步Debug阅读相关源码,此文多半可能会胎死腹中了。
在此非常感谢 @小宇。不瞒大家,他又邀请我一起去读 ORM 框架源码了。不过得好好等上一段时间了。
个人所谈
: 阅读源码的过程中,其实真的是充满有趣和枯燥的。 读懂了一些关键东西,就开心的不得了;而像“又忘记debug到哪了,思路又凉了",就会开始满心抱怨(我常常想骂上一两句)。然后就继续苦逼的去看。 大家好,我是博主宁在春
:主页 一名喜欢文艺却踏上编程这条道路的小青年。 希望:我们,待别日相见时,都已有所成
。
另外就只能说是在此提供一份个人见解。因文字功底不足、知识缺乏,写不出十分术语化的文章。
如果觉得本文让你有所收获,希望能够点个赞,给予一份鼓励。
也希望大家能够积极交流。如有不足之处,请大家及时批正,在此感谢大家。