逐行解读Spring（二） - 什么，自定义标签没据说过？回去等通知吧！

时间  2021-08-14
标签 java node 正则表达式 spring shell express json 设计模式 数组 服务器 栏目 Spring 繁體版
原文   原文链接

创做不易，转载请篇首注明 做者：掘金@小希子 + 来源连接~java

若是想了解更多Spring源码知识，点击前往其他逐行解析Spring系列node

1、自定义标签是什么？

上一篇咱们讲了默认标签-bean标签的解析，今天咱们讲一下自定义标签的解析。正则表达式

1. 自定义标签的定义

这个问题其实上一篇有讲过，这边再复述一遍，在spring的xml配置文件中，咱们能够把全部的标签分为两类：自定义标签和默认标签，区别以下spring

<!-- 标签前面有 xxx:便是spring的自定义标签，咱们也能够本身定义一个xiaozize:的标签-以后会讲到 -->
<context:component-scan base-package="com.xiaoxizi.spring"/>
<!-- 该标签对应的命名空间在xml文件头部beans标签中声明 -->
<beans xmlns:context="http://www.springframework.org/schema/context" ... />

<!-- 默认标签没有 xx: 前缀 -->
<bean class="com.xiaoxizi.spring.service.AccountServiceImpl" id="accountService" scope="singleton" primary="true"/>
<!-- 对应的命名空间也在xml文件头部beans标签中声明 -->
<beans xmlns="http://www.springframework.org/schema/beans" ... />
复制代码

须要注意的是，自定义标签的概念，并不彻底只指咱们开发时本身定义的标签，而是spring的开发者为以后拓展预留的拓展点，这个拓展点咱们能够用，spring的开发人员在为spring添加新功能时，也可使用。shell

2. 关于spring内置的自定义标签context:component-scan

咱们如今的开发中，更多的状况下，实际上是使用@Configuration、@Component、@Service 等注解来进行bean的声明而不是使用xml的bean 标签了。express

那么为何一个类加上了这些注解以后，就能被spring管理了呢？json

实际上这些拓展功能是spring经过本身预留的自定义标签的拓展点进行拓展的，对于上述的功能，具体是使用的context:component-scan标签。设计模式

咱们今天就经过对自定义标签context:component-scan的解析来跟踪一下相应的源码，理解spring自定义标签解析的流程，同时也对context:component-scan实现的功能作一个讲解，看一下@Component等标签的实现原理。数组

2、源码解析

1. 自定义标签解析过程

因为上一篇对xml的源码跟过了，这期咱们之间定位到相应代码org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader#parseBeanDefinitions服务器

protected void parseBeanDefinitions(Element root, BeanDefinitionParserDelegate delegate) {
    // 判断是不是默认的命名空间
    if (delegate.isDefaultNamespace(root)) {
        NodeList nl = root.getChildNodes();
        for (int i = 0; i < nl.getLength(); i++) {
            Node node = nl.item(i);
            if (node instanceof Element) {
                Element ele = (Element) node;
                if (delegate.isDefaultNamespace(ele)) {
                    // 解析默认标签
                    parseDefaultElement(ele, delegate);
                }
                else {
                   	// 能够看到代理主要进行自定义标签的解析
                    delegate.parseCustomElement(ele);
                }
            }
        }
    }
    else {
        // 能够看到代理主要进行自定义标签的解析
        delegate.parseCustomElement(root);
    }
}

@Nullable
public BeanDefinition parseCustomElement(Element ele, @Nullable BeanDefinition containingBd) {
    // 获取标签对于的namespaceUrl, 即配置文件头部beans标签里面那些xmlns:xxx=www.xxx.com
    String namespaceUri = getNamespaceURI(ele);
    if (namespaceUri == null) {
        return null;
    }
    // 获取自定义标签对应的NamespaceHandler，从这里咱们能够看到，对于每个namespaceUri应该都有惟一一个对应的NamespaceHandler
    NamespaceHandler handler = this.readerContext.getNamespaceHandlerResolver().resolve(namespaceUri);
    if (handler == null) {
        error("Unable to locate Spring NamespaceHandler for XML schema namespace [" + namespaceUri + "]", ele);
        return null;
    }
    // 把自定义标签委托给对应的NamespaceHandler解析
    return handler.parse(ele, new ParserContext(this.readerContext, this, containingBd));
}
复制代码

咱们先看一下NamespaceHandler这个自定义标签的解析接口的结构：

public interface NamespaceHandler {
    // 初始化，咱们能够合理猜想，这个方法将会在NamespaceHandler实例化以后，使用以前调用
	void init();
	// xml解析入口
	@Nullable
	BeanDefinition parse(Element element, ParserContext parserContext);
	// 装饰接口，其实用的比较少，上一篇有稍微带到过一下，默认bean标签解析完以后，能够有一个机会对解析出来的beanDefinition进行装饰，实际开发中不多使用
    // 有兴趣的同窗能够自行看下源码，源码在 org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader#processBeanDefinition
	@Nullable
	BeanDefinitionHolder decorate(Node source, BeanDefinitionHolder definition, ParserContext parserContext);
}
复制代码

接下来固然是须要看一下获取NamespaceHandler的流程：

public NamespaceHandler resolve(String namespaceUri) {
    // 获取到了一个handlerMapping，具体逻辑咱们以后再看
    Map<String, Object> handlerMappings = getHandlerMappings();
    // 经过namespaceUri获取到一个对象
    Object handlerOrClassName = handlerMappings.get(namespaceUri);
    if (handlerOrClassName == null) {
        return null;
    }
    // 若是handlerOrClassName是一个NamespaceHandler对象，则直接返回 - 拿到对应的handler了
    else if (handlerOrClassName instanceof NamespaceHandler) {
        return (NamespaceHandler) handlerOrClassName;
    }
    else {
        // 若是handlerOrClassName不是NamespaceHandler对象，则是String对象
        String className = (String) handlerOrClassName;
        // 经过String获取到一个Class对象，那么这个String对象确定是一个类的全限定名啦
        Class<?> handlerClass = ClassUtils.forName(className, this.classLoader);
        // handlerClass必须继承自NamespaceHandler，很好理解，毕竟是spring提供的拓展点，天然须要符合它定义的规则
        if (!NamespaceHandler.class.isAssignableFrom(handlerClass)) {
            throw new FatalBeanException("...");
        }
        // 直接经过反射构造一个实例，点进去看会发现是调用的无参构造器，咱们就不看了
        NamespaceHandler namespaceHandler = (NamespaceHandler) BeanUtils.instantiateClass(handlerClass);
        // !!! 调用了init()方法，和咱们以前的推测一致
        namespaceHandler.init();
        // !!! 把handler对象塞回了handlerMappings，因此咱们下次再经过namespaceUri获取时，会直接拿到一个NamespaceHandler对象
        // 也即每一个namespaceUri对应的NamespaceHandler对象是单例的，而init()方法也只会调用一次
        handlerMappings.put(namespaceUri, namespaceHandler);
        return namespaceHandler;
        // 去除掉了异常处理
    }
}
复制代码

由上述源码其实咱们已经得知了NamespaceHandler的一个初始化过程，但其实还有一个疑问，就是这个handlerMappings中最初的那些namespaceUri对应的handler的类名是哪来的呢？这个时候咱们就须要去看一下getHandlerMappings()的过程啦

private Map<String, Object> getHandlerMappings() {
    Map<String, Object> handlerMappings = this.handlerMappings;
    if (handlerMappings == null) {
        synchronized (this) {
            handlerMappings = this.handlerMappings;
            // 双重检查加锁，看来咱们的handlerMappings以后加载一次
            if (handlerMappings == null) {
                // 能够看到这边是去加载了文件
                // 文件加载的过程咱们就不去跟了，跟主流程关系不大，咱们主要看一下这个文件位置
                // this.handlerMappingsLocation是哪里
                Properties mappings =
                    PropertiesLoaderUtils.loadAllProperties(this.handlerMappingsLocation, this.classLoader);
                handlerMappings = new ConcurrentHashMap<>(mappings.size());
                // 而后把文件中的kev-value属性都合并到了一个map里
                CollectionUtils.mergePropertiesIntoMap(mappings, handlerMappings);
                this.handlerMappings = handlerMappings;
                // 干掉了异常处理代码
            }
        }
    }
    return handlerMappings;
}
// 字段的定义， 须要说一下当前类是DefaultNamespaceHandlerResolver，喜欢本身探索的同窗能够直接空降
/** Resource location to search for. */
private final String handlerMappingsLocation;
// 能够看到这个值是Resolver的构造器中设值的
public DefaultNamespaceHandlerResolver(@Nullable ClassLoader classLoader, String handlerMappingsLocation) {
    this.classLoader = (classLoader != null ? classLoader : ClassUtils.getDefaultClassLoader());
    this.handlerMappingsLocation = handlerMappingsLocation;
}
// 默认是取的DEFAULT_HANDLER_MAPPINGS_LOCATION这个常量
public DefaultNamespaceHandlerResolver() {
    this(null, DEFAULT_HANDLER_MAPPINGS_LOCATION);
}
// 咱们看一下这个常量的值
public static final String DEFAULT_HANDLER_MAPPINGS_LOCATION = "META-INF/spring.handlers";
复制代码

若是对SPI比较熟悉的同窗，应该已经知道这是个什么套路了，而且对META-INF这个目录也比较熟悉，那么如今，咱们看一下这个META-INF/spring.handlers文件中到底写了一些什么东西，以context:component-scan标签为例，咱们知道这个标签是spring-context包里面提供的，直接去找这个jar包的对应文件，看一下里面的内容：

## 咱们能够很明显的看到一个key=value结构
http\://www.springframework.org/schema/context=org.springframework.context.config.ContextNamespaceHandler
http\://www.springframework.org/schema/jee=org.springframework.ejb.config.JeeNamespaceHandler
http\://www.springframework.org/schema/lang=org.springframework.scripting.config.LangNamespaceHandler
http\://www.springframework.org/schema/task=org.springframework.scheduling.config.TaskNamespaceHandler
http\://www.springframework.org/schema/cache=org.springframework.cache.config.CacheNamespaceHandler
复制代码

咱们在回忆一下自定义标签的定义：

<!-- 标签前面有 xxx:便是spring的自定义标签，咱们也能够本身定义一个xiaozize:的标签-以后会讲到 -->
<context:component-scan base-package="com.xiaoxizi.spring"/>
<!-- 该标签对应的命名空间在xml文件头部beans标签中声明 -->
<beans xmlns:context="http://www.springframework.org/schema/context" ... />
复制代码

能够看到咱们的META-INF/spring.handlers文件中key就是自定义标签的namespaceUri，value则是对应的NamespaceHandler的全限定名。

那么简单总结一下，咱们的自定义标签解析的流程就是：

  1. 加载全部jar中META-INF/spring.handlers文件中的namespaceUri和NamespaceHandler的全限定名的映射关系到handlerMappings

  2. 根据namespaceUri从handlerMappings获取对象

    • 若是从handlerMappings获取到的对象为空，直接返回

    • 若是获取到的是NamespaceHandler对象，直接使用

    • 若是获取到的对象是string类型，则实例化这个string对应的全限定名的NamespaceHandler对象，并调用init()方法，而后将 namespaceUri-NamespaceHandler对象关系放回handlerMappings

  3. 将自定义标签委托给2获取到的NamespaceHandler对象解析-调用parse方法（若是2未获取到对应的NamespaceHandler对象，则此自定义标签没法解析，直接跳过）

2. context:component-scan标签工做原理

接下来咱们来看一下 context:component-scan标签的工做原理，从spring-context包的META-INF/spring.handlers文件咱们能够找到该标签对应的处理器：

http\://www.springframework.org/schema/context=org.springframework.context.config.ContextNamespaceHandler
复制代码

直接找到这个类：

public class ContextNamespaceHandler extends NamespaceHandlerSupport {
    @Override
    public void init() {
        // 删掉了一些咱们不关注的标签的Parser的注入代码...
        // 咱们能够看到这里注册了一个BeanDefinitionParser，并且这个注册方法的第一个参数明显是
        // `context:component-scan` 标签中删掉前缀的部分，咱们先记下来
        registerBeanDefinitionParser("component-scan", new ComponentScanBeanDefinitionParser());
        // 删掉了一些咱们不关注的标签的Parser的注入代码...
    }
}
复制代码

能够看到ContextNamespaceHandler继承自NamespaceHandlerSupport，这是一个典型的模本方法设计模式。这里不作拓展，咱们直接看一下NamespaceHandlerSupport：

// 这里咱们只保存了与解析器相关的代码，而且调整了一下源码顺序
// 装饰相关的代码我去除掉了，并非NamespaceHandlerSupport中没有，不过它的逻辑和解析基本是一致的
// 若是同窗们还记得哪里对beanDefinition进行了装饰，而且感兴趣的话，能够自行了解一下 (*￣︶￣)
public abstract class NamespaceHandlerSupport implements NamespaceHandler {
    // 保存标签名-解析器对应关系的容器
	private final Map<String, BeanDefinitionParser> parsers = new HashMap<>();
    // 保存标签名-装饰器对应关系的容器
	private final Map<String, BeanDefinitionDecorator> decorators = new HashMap<>();
    // 保存属性名-装饰器对应关系的容器
	private final Map<String, BeanDefinitionDecorator> attributeDecorators = new HashMap<>();
    // 能够看到咱们init()方法中的register其实就只是把对应elementName-Parser放入map而已
	protected final void registerBeanDefinitionParser(String elementName, BeanDefinitionParser parser) {
		this.parsers.put(elementName, parser);
	}
	public BeanDefinition parse(Element element, ParserContext parserContext) {
        // 获取 Parser
		BeanDefinitionParser parser = findParserForElement(element, parserContext);
        // 委托给 Parser解析
		return (parser != null ? parser.parse(element, parserContext) : null);
	}
	private BeanDefinitionParser findParserForElement(Element element, ParserContext parserContext) {
        // 这里是获取了去掉标签中去掉前缀后的名称 context:component-scan --> component-scan
		String localName = parserContext.getDelegate().getLocalName(element);
        // 从map中获取到对应的Parser
		return this.parsers.get(localName);
	}
}
复制代码

到此为止其实仍是蛮简单的嘛，咱们又把标签委托给了对应的Parser来处理，那么咱们如今来看一下component-scan对应的ComponentScanBeanDefinitionParser的逻辑，咱们先看parse方法，也是咱们的入口方法：

public BeanDefinition parse(Element element, ParserContext parserContext) {
    // 获取标签上配置并处理的base-package属性
    String basePackage = element.getAttribute(BASE_PACKAGE_ATTRIBUTE);
    // 处理占位符
    basePackage = parserContext.getReaderContext().getEnvironment().resolvePlaceholders(basePackage);
    // 最终获取到的是一个数组 - 由于咱们配置的时候是能够配置多个的
    String[] basePackages = StringUtils.tokenizeToStringArray(basePackage,
                                                ConfigurableApplicationContext.CONFIG_LOCATION_DELIMITERS);

    // 获取一个扫描器 - 这个东西很重要，咱们之后还会看到
    ClassPathBeanDefinitionScanner scanner = configureScanner(parserContext, element);
    // 嗯，扫描器进行扫描，看来就是这个方法会扫描那些注解了
    Set<BeanDefinitionHolder> beanDefinitions = scanner.doScan(basePackages);
    // 注册一些组件
    registerComponents(parserContext.getReaderContext(), beanDefinitions, element);
    return null;
}
复制代码

咱们先看一下扫描器是怎么建立出来的：

// 把一些异常处理都干掉了
protected ClassPathBeanDefinitionScanner configureScanner(ParserContext parserContext, Element element) {
    // 解析一下是否用默认的过滤器 --> 这里解释一下，其实这个过滤器就是指咱们那些注解@Service等。
    // 其实这里就是定义那些注解是咱们扫描到了以后会把它归入IOC管理的，具体代码以后解析的时候会看到
    boolean useDefaultFilters = true;
    if (element.hasAttribute(USE_DEFAULT_FILTERS_ATTRIBUTE)) {
        useDefaultFilters = Boolean.parseBoolean(element.getAttribute(USE_DEFAULT_FILTERS_ATTRIBUTE));
    }
	// 直接建立一个扫描器
    ClassPathBeanDefinitionScanner scanner = createScanner(parserContext.getReaderContext(), useDefaultFilters);
    // 从parserContext获取到的默认的beanDefinition的配置，即以后解析的beanDefinition的缺省配置
    scanner.setBeanDefinitionDefaults(parserContext.getDelegate().getBeanDefinitionDefaults());
    // 从parserContext获取到的默认的自动装配的模式，byType、byName那些
    scanner.setAutowireCandidatePatterns(parserContext.getDelegate().getAutowireCandidatePatterns());
	// 扫描的资源路径，通常咱们也不配置
    if (element.hasAttribute(RESOURCE_PATTERN_ATTRIBUTE)) {
        scanner.setResourcePattern(element.getAttribute(RESOURCE_PATTERN_ATTRIBUTE));
    }
    // 没什么用的...通常也不会去自定义，即便用注解时，生成bean的name的策略也能够自定义
    parseBeanNameGenerator(element, scanner);
    // 基本也不用，scope相关的，大概意思就是这个bean会存在于哪些scope，通常不用
    parseScope(element, scanner);
    // 解析类型过滤器-这个算相对重要，其实就是咱们能够自定义须要扫描哪些注解
    parseTypeFilters(element, scanner, parserContext);

    return scanner;
}
复制代码

咱们先看一下若是useDefaultFilters=true会注册哪些过滤器，createScanner中其实就是直接调用了构造器，那咱们直接看一下构造器逻辑：

public ClassPathBeanDefinitionScanner(BeanDefinitionRegistry registry, boolean useDefaultFilters, Environment environment, @Nullable ResourceLoader resourceLoader) {
    Assert.notNull(registry, "BeanDefinitionRegistry must not be null");
    this.registry = registry;
    if (useDefaultFilters) {
        // 注册默认的过滤器
        registerDefaultFilters();
    }
    setEnvironment(environment);
    setResourceLoader(resourceLoader);
}
protected void registerDefaultFilters() {
    // includeFilters添加了一个AnnotationTypeFilter，过滤器构造器传入了Component的Class对象
    this.includeFilters.add(new AnnotationTypeFilter(Component.class));
    // 省略了两个JSR规范注解的注册代码，咱们通常用不到，@javax.annotation.ManagedBean和@javax.inject.Named
}
复制代码

因为Filter的匹配过程不是主流程，不在这里多写，可是我会写一段源码解析到这一节的末尾，感兴趣的同窗也能够看一下。

咱们解析来看一下类型过滤器标签的解析：

protected void parseTypeFilters(Element element, ClassPathBeanDefinitionScanner scanner, ParserContext parserContext) {
    // ...
    NodeList nodeList = element.getChildNodes();
    for (int i = 0; i < nodeList.getLength(); i++) {
        Node node = nodeList.item(i);
        // 找到每个子节点
        if (node.getNodeType() == Node.ELEMENT_NODE) {
            String localName = parserContext.getDelegate().getLocalName(node);
            if (INCLUDE_FILTER_ELEMENT.equals(localName)) {
                // 若是是<include-filter/>标签则建立一个Filter并加入includeFilters
                TypeFilter typeFilter = createTypeFilter((Element) node, classLoader, parserContext);
                scanner.addIncludeFilter(typeFilter);
            }
            else if (EXCLUDE_FILTER_ELEMENT.equals(localName)) {
                // 若是是<exclude-filter/>标签则建立一个Filter并加入includeFilters
                TypeFilter typeFilter = createTypeFilter((Element) node, classLoader, parserContext);
                scanner.addExcludeFilter(typeFilter);
            }
        }
    }
}
复制代码

那么咱们看一下createTypeFilter究竟作了一些什么：

// 逻辑仍是比较直观的
protected TypeFilter createTypeFilter(Element element, @Nullable ClassLoader classLoader, ParserContext parserContext) {
    String filterType = element.getAttribute(FILTER_TYPE_ATTRIBUTE);
    String expression = element.getAttribute(FILTER_EXPRESSION_ATTRIBUTE);
    expression = parserContext.getReaderContext().getEnvironment().resolvePlaceholders(expression);
    if ("annotation".equals(filterType)) {
        // 若是咱们想扫描自定义的注解，那可使用这个annotation类型，expression填注解全限定名就行了
        return new AnnotationTypeFilter((Class<Annotation>) ClassUtils.forName(expression, classLoader));
    }
    else if ("assignable".equals(filterType)) {
        // 扫描配置的类及其子类，expression填类的全限定名就行了，这个也偶尔用到，主要用来指定扫描一些二方库的bean
        return new AssignableTypeFilter(ClassUtils.forName(expression, classLoader));
    }
    else if ("aspectj".equals(filterType)) {
        // 扫描切面表达式所匹配的类
        return new AspectJTypeFilter(expression, classLoader);
    }
    else if ("regex".equals(filterType)) {
        // 扫描正则表达式所匹配的类
        return new RegexPatternTypeFilter(Pattern.compile(expression));
    }
    else if ("custom".equals(filterType)) {
        // 自定义的过滤器，对应的类须要实现TypeFilter接口
        Class<?> filterClass = ClassUtils.forName(expression, classLoader);
        if (!TypeFilter.class.isAssignableFrom(filterClass)) {
            throw new IllegalArgumentException(
                "Class is not assignable to [" + TypeFilter.class.getName() + "]: " + expression);
        }
        return (TypeFilter) BeanUtils.instantiateClass(filterClass);
    }
    else {
        throw new IllegalArgumentException("Unsupported filter type: " + filterType);
    }
}
复制代码

好了，context:component-scan标签的属性解析就告一段落了，咱们主要记住base-package和Filter相关的就行了，其他的其实也用不太到，毕竟这个扫描的功能主要只须要肯定须要扫描哪些包以及须要关注哪些类就行了。那么咱们接下来再往回看一下，扫描器的扫描逻辑是怎么样的，同窗们能够空降ComponentScanBeanDefinitionParser#parse，而后咱们来看一下获取到scanner以后，scanner.doScan(basePackages)的逻辑：

protected Set<BeanDefinitionHolder> doScan(String... basePackages) {
    for (String basePackage : basePackages) {
        // 找到因此扫描到的beanDefinition
        Set<BeanDefinition> candidates = findCandidateComponents(basePackage);
        for (BeanDefinition candidate : candidates) {
            // 获取beanName，要知道，咱们使用注解的时候，实际上是没有一个像xml标签属性那样的东西来获取name的
            // 这里经过beanNameGenerator来获取了beanName，默认就是经过注解内的对应属性或者类名。感兴趣的同窗能够看下 AnnotationBeanNameGenerator
            String beanName = this.beanNameGenerator.generateBeanName(candidate, this.registry);
            // 删掉了一下不重要的属性的赋值
            if (candidate instanceof AnnotatedBeanDefinition) {
            // 里是处理类上的一些公共注解的地方，好比@Primary，@Lazy等
                AnnotationConfigUtils.processCommonDefinitionAnnotations((AnnotatedBeanDefinition) candidate);
            }
            // 这个判断的大概意思就是，看一下咱们扫描出来的beanDifinition是否是第一次注册
            // 若是不是第一次注册就不会再注册了，是经过beanName来从IOC容器中找有没有同样的
            if (checkCandidate(beanName, candidate)) {
				// ... 
                // 注册bean，这个逻辑咱们第一篇看过了，就不在看了，实际上就是把beanDefinition放入
                // beanDefinitionMap和beanDefinitionNames这两个容器里面
                registerBeanDefinition(definitionHolder, this.registry);
            }
        }
    }
    return beanDefinitions;
}
复制代码

咱们先看一下是怎么AnnotationConfigUtils.processCommonDefinitionAnnotations()中是怎么处理类上的注解的：

static void processCommonDefinitionAnnotations(AnnotatedBeanDefinition abd, AnnotatedTypeMetadata metadata) {
    AnnotationAttributes lazy = attributesFor(metadata, Lazy.class);
    if (lazy != null) {
        abd.setLazyInit(lazy.getBoolean("value"));
    }
    else if (abd.getMetadata() != metadata) {
        lazy = attributesFor(abd.getMetadata(), Lazy.class);
        if (lazy != null) {
            abd.setLazyInit(lazy.getBoolean("value"));
        }
    }
    if (metadata.isAnnotated(Primary.class.getName())) {
        abd.setPrimary(true);
    }
    AnnotationAttributes dependsOn = attributesFor(metadata, DependsOn.class);
    if (dependsOn != null) {
        abd.setDependsOn(dependsOn.getStringArray("value"));
    }

    AnnotationAttributes role = attributesFor(metadata, Role.class);
    if (role != null) {
        abd.setRole(role.getNumber("value").intValue());
    }
    AnnotationAttributes description = attributesFor(metadata, Description.class);
    if (description != null) {
        abd.setDescription(description.getString("value"));
    }
}
复制代码

大聪明们确定已经发现了，其实就是看一下类上面有没有对应的注解，而后把对应的属性塞入beanDefinition对象嘛。这岂不是能够说是跟XML解析获取beanDefinition时的流程如出一辙的？

是的，其实无论是基于注解仍是基于xml，都是把一些描述bean的信息，收集汇总到相应的beanDefinition中而已。而beanDefinition的属性决定了这个bean会怎么实例化，须要注入哪些属性等等等等。

收集信息来注解beanDefinition的途径能够有多种--甚至你本身写一个解析json格式文件的组件也不是不行，可是结果都是异曲同工的。

从这也能够看出spring设计的强大，这种模块化的设计思想和对单一职责原则（比较直观的是各类委托模式，专业的事给专业的类作）和开闭原则（到咱们如今讲到的地方：自定义标签的设计，在不触动原有核心逻辑的状况下，咱们能够很简单的对spring作一些自定义的拓展）的实践，咱们平常开发中是否也能够借鉴借鉴呢？

好了，感慨完了，咱们继续回到源码，接下来咱们具体看下扫描器是怎么扫描到那些被注解标记的类的（其实就是对以前注册的过滤器的应用），findCandidateComponents()中调用了scanCandidateComponents()，咱们之间看scanCandidateComponents()：

// 去除掉了异常处理和日志打印
private Set<BeanDefinition> scanCandidateComponents(String basePackage) {
    Set<BeanDefinition> candidates = new LinkedHashSet<>();
    String packageSearchPath = ResourcePatternResolver.CLASSPATH_ALL_URL_PREFIX +
        resolveBasePackage(basePackage) + '/' + this.resourcePattern;
    // 这一段逻辑极其复杂切对咱们理解主流程没太大帮助，咱们就不看了（主要是涉及到模糊匹配的文件寻找）
    // 大概就是把全部符合的类文件找出来了
    Resource[] resources = getResourcePatternResolver().getResources(packageSearchPath);
    for (Resource resource : resources) {
        // 解析文件信息，加载到内存，这里看下去也贼复杂，都是一些字节码解析技术了
        // 咱们只须要知道这样操做一番后，这个MetadataReader能拿到咱们这个类的全部信息就行了
        MetadataReader metadataReader = getMetadataReaderFactory().getMetadataReader(resource);
        // 这里就是咱们过滤器发挥做用的地方了，符合条件的类才会生成beanDefinition
        if (isCandidateComponent(metadataReader)) {
            ScannedGenericBeanDefinition sbd = new ScannedGenericBeanDefinition(metadataReader);
            sbd.setResource(resource);
            sbd.setSource(resource);
            // 这里主要判断一下，咱们匹配到的类是否是一个符合条件的bean
            // 好比说若是咱们注解打在接口上，这里就不会把这个beanDefinition加入返回的容器了
            if (isCandidateComponent(sbd)) {
                candidates.add(sbd);
            }
        }
    }
	return candidates;
}
// 过滤器判断是不是咱们关注的类，逻辑很直观
protected boolean isCandidateComponent(MetadataReader metadataReader) throws IOException {	
    // 先判断的excludeFilters
    for (TypeFilter tf : this.excludeFilters) {
        if (tf.match(metadataReader, getMetadataReaderFactory())) {
            return false;
        }
    }
    // 再判断的includeFilters
    for (TypeFilter tf : this.includeFilters) {
        if (tf.match(metadataReader, getMetadataReaderFactory())) {
            // 若是是咱们关注的类，还须要处理类上面的@Conditional注解
            // 这里不继续往下拓展了，我简单讲一下逻辑：
            // 1.找到类上面全部的@Conditional簇的注解
            // 2.实例化全部对应的Conditional类，并排序
            // 3.依次调用全部condition.matches()，全部条件所有知足才返回true
            // 具体细节同窗们感兴趣能够本身看下
            return isConditionMatch(metadataReader);
        }
    }
    return false;
}
// 判断是否不是接口那些
protected boolean isCandidateComponent(AnnotatedBeanDefinition beanDefinition) {
    return (metadata.isIndependent() // 不是实例内部类 而且
            && (metadata.isConcrete() // 不是接口或者抽象类 或者
                ||
                                         (metadata.isAbstract() && metadata.hasAnnotatedMethods(Lookup.class.getName())))); 
    // 是抽象类可是有些方法被@Lookup注解标记，这个以前有稍微提过，xml标签里那个lookup-method标签跟这个是一个意思，至关于把这个方法委托/代理给另外一个bean了，因此即便是抽象类也是能够变成一个bean的 -> spring动态代理生成一个子类
}
复制代码

3. Filter匹配流程

原本不想写Filter的匹配流程的，由于其实不是主流程，不过想一想仍是写一下吧，否则有些同窗可能会纠结。

主要讲一下咱们用的比较多的AnnotationTypeFilter，先看一下AnnotationTypeFilter的构造器：

// 咱们简单看一下AnnotationTypeFilter的构造器
public AnnotationTypeFilter(Class<? extends Annotation> annotationType) {
    this(annotationType, true, false);
}
// 能够看到，咱们扫描@Component注解时，是考虑源注解，且不考虑接口上的注解的
public AnnotationTypeFilter( // 注解类型 Class<? extends Annotation> annotationType, // 是否考虑源注解 boolean considerMetaAnnotations, // 是否考虑接口 boolean considerInterfaces) {
    // 第一个参数是是否考虑继承的注解
    super(annotationType.isAnnotationPresent(Inherited.class), considerInterfaces);
    this.annotationType = annotationType;
    this.considerMetaAnnotations = considerMetaAnnotations;
}
复制代码

再看一下核心的match方法，这里也是一个模板方法模式：

// 先看顶层类
public abstract class AbstractTypeHierarchyTraversingFilter implements TypeFilter {
    @Override
    public boolean match(MetadataReader metadataReader, MetadataReaderFactory metadataReaderFactory) throws IOException {
		// 直接看当前类是否匹配 - 模板方法，由子类实现，默认返回了false
        if (matchSelf(metadataReader)) {
            return true;
        }
        // 提供一个经过className判断是否匹配的钩子
        ClassMetadata metadata = metadataReader.getClassMetadata();
        if (matchClassName(metadata.getClassName())) {
            return true;
        }
        if (this.considerInherited) {
            // 若是考虑继承的注解，则找到对应的父类
            String superClassName = metadata.getSuperClassName();
            if (superClassName != null) {
                // 先看下子类有没有 单独判断父类是否匹配 的逻辑
                Boolean superClassMatch = matchSuperClass(superClassName);
                if (superClassMatch != null) {
                    // 有写这个逻辑则直接用这个返回结果了
                    if (superClassMatch.booleanValue()) {
                        return true;
                    }
                }
                else {
                    // 没有 单独判断父类是否匹配 的逻辑 则直接走当前这个匹配逻辑
                    if (match(metadata.getSuperClassName(), metadataReaderFactory)) {
                        return true;
                    }
                }
            }
        }
        if (this.considerInterfaces) {
            // 若是考虑接口的注解，则找到对应的接口，由于接口是多个，因此要循环
            // 逻辑和父类那里相似，很少讲了
            for (String ifc : metadata.getInterfaceNames()) {
                Boolean interfaceMatch = matchInterface(ifc);
                if (interfaceMatch != null) {
                    if (interfaceMatch.booleanValue()) {
                        return true;
                    }
                }
                else {
                    if (match(ifc, metadataReaderFactory)) {
                        return true;
                    }
                }
            }
        }
        return false;
    }
}
复制代码

再看一下AnnotationTypeFilter的几个核心方法：

public class AnnotationTypeFilter extends AbstractTypeHierarchyTraversingFilter {
	protected boolean matchSelf(MetadataReader metadataReader) {
		AnnotationMetadata metadata = metadataReader.getAnnotationMetadata();
        // 类上有目标注解
		return metadata.hasAnnotation(this.annotationType.getName()) ||
            // 若是能够从源注解拿，则找一下类上面有没有源注解是和目标注解同样的
				(this.considerMetaAnnotations && metadata.hasMetaAnnotation(this.annotationType.getName()));
	}
	protected Boolean matchSuperClass(String superClassName) {
		return hasAnnotation(superClassName);
	}
	protected Boolean matchInterface(String interfaceName) {
		return hasAnnotation(interfaceName);
	}

	@Nullable
	protected Boolean hasAnnotation(String typeName) {
		if (Object.class.getName().equals(typeName)) {
			return false;
		}
        // 这个父类和接口的匹配逻辑竟然只能匹配到jdk内置（java开头）的类
        // 看来默认的实现应该是用来支持JSR标准的那些注解的
		else if (typeName.startsWith("java")) {
			// ... 不关注
		}
		return null;
	}
}
复制代码

咱们能够看到，咱们默认的AnnotationTypeFilter是考虑源注解的，那么这个源注解究竟是个什么东西呢？

public @interface Controller {
	@AliasFor(annotation = Component.class)
	String value() default "";
}
public @interface Service {
	@AliasFor(annotation = Component.class)
	String value() default "";
}
public @interface Repository {
	@AliasFor(annotation = Component.class)
	String value() default "";
}
复制代码

常见的就是这个东西啦@AliasFor(annotation = Component.class)，这也是为何咱们默认的includeFilters明明只注册了一个@Component类型的AnnotationTypeFilter，可是咱们@Service等也能被扫描到的缘由啦！咱们构造的AnnotationTypeFilter是考虑源注解的！

4. 注册公共组件

看到这里，咱们已经明白了context:component-scan标签是怎么扫描，怎么支持@Component注解的了，可是细心的同窗们可能已经发现了，如今咱们确实能扫描@Component注解了，可是咱们bean中那些属性是怎么注入的呢？@Autowrite、@Resource这些注解是怎么支持的呢？以及@Configuration、@Bean又是如何支持的呢？

这些功能实际上是在相应的BeanPostProcessor中完成的，而这些BeanPostProcessor的注册，也是在咱们context:component-scan标签的解析过程当中注入的。若是同窗们还有印象的话，应该还记得ComponentScanBeanDefinitionParser的parse方法中，咱们再建立了扫描器而且进行扫描以后，还作了一些公共组件注册的工做：

public BeanDefinition parse(Element element, ParserContext parserContext) {
    // ...
    // 获取一个扫描器 - 这个东西很重要，咱们之后还会看到
    ClassPathBeanDefinitionScanner scanner = configureScanner(parserContext, element);
    // 嗯，扫描器进行扫描，看来就是这个方法会扫描那些注解了
    Set<BeanDefinitionHolder> beanDefinitions = scanner.doScan(basePackages);
    // 注册一些组件
    registerComponents(parserContext.getReaderContext(), beanDefinitions, element);
    return null;
}
复制代码

咱们看一下registerComponents方法：

protected void registerComponents( XmlReaderContext readerContext, Set<BeanDefinitionHolder> beanDefinitions, Element element) {
	// ...
    // Register annotation config processors, if necessary.
    boolean annotationConfig = true;
    if (element.hasAttribute(ANNOTATION_CONFIG_ATTRIBUTE)) {
        annotationConfig = Boolean.parseBoolean(element.getAttribute(ANNOTATION_CONFIG_ATTRIBUTE));
    }
    // 看下annotation-config配置，默认是为true的
    if (annotationConfig) {
        Set<BeanDefinitionHolder> processorDefinitions =
            // 注册一些支撑注解功能的Processors
            AnnotationConfigUtils.registerAnnotationConfigProcessors(readerContext.getRegistry(), source);
		// ...
    }
	// ...
}
复制代码

那么到底注册了哪些Processor呢？

public static Set<BeanDefinitionHolder> registerAnnotationConfigProcessors( BeanDefinitionRegistry registry, @Nullable Object source) {
	// ...
    Set<BeanDefinitionHolder> beanDefs = new LinkedHashSet<>(8);
	
    // 这里注册了一个ConfigurationClassPostProcessor，顾名思义，这个应该是支撑@Configuration相关的注解的
    if (!registry.containsBeanDefinition(CONFIGURATION_ANNOTATION_PROCESSOR_BEAN_NAME)) {
        RootBeanDefinition def = new RootBeanDefinition(ConfigurationClassPostProcessor.class);
        def.setSource(source);
        // 注册逻辑registerPostProcessor
        beanDefs.add(registerPostProcessor(registry, def, CONFIGURATION_ANNOTATION_PROCESSOR_BEAN_NAME));
    }
	// 注册了一个AutowiredAnnotationBeanPostProcessor，用来处理@Autowire，@Value注解的
    if (!registry.containsBeanDefinition(AUTOWIRED_ANNOTATION_PROCESSOR_BEAN_NAME)) {
        RootBeanDefinition def = new RootBeanDefinition(AutowiredAnnotationBeanPostProcessor.class);
        def.setSource(source);
        beanDefs.add(registerPostProcessor(registry, def, AUTOWIRED_ANNOTATION_PROCESSOR_BEAN_NAME));
    }

    // Check for JSR-250 support, and if present add the CommonAnnotationBeanPostProcessor.
    // 这里是支撑JSR-250规范的@Resource、@PostConstruct、@PreDestroy注解的
    if (jsr250Present && !registry.containsBeanDefinition(COMMON_ANNOTATION_PROCESSOR_BEAN_NAME)) {
        RootBeanDefinition def = new RootBeanDefinition(CommonAnnotationBeanPostProcessor.class);
        def.setSource(source);
        beanDefs.add(registerPostProcessor(registry, def, COMMON_ANNOTATION_PROCESSOR_BEAN_NAME));
    }

    // Check for JPA support, and if present add the PersistenceAnnotationBeanPostProcessor.
    // 这里是支持注解形式的jpa的BeanPostProcessor
    if (jpaPresent && !registry.containsBeanDefinition(PERSISTENCE_ANNOTATION_PROCESSOR_BEAN_NAME)) {
        RootBeanDefinition def = new RootBeanDefinition();
        try {
            def.setBeanClass(ClassUtils.forName(PERSISTENCE_ANNOTATION_PROCESSOR_CLASS_NAME,
                                                AnnotationConfigUtils.class.getClassLoader()));
        }
        catch (ClassNotFoundException ex) {
            throw new IllegalStateException(
                "Cannot load optional framework class: " + PERSISTENCE_ANNOTATION_PROCESSOR_CLASS_NAME, ex);
        }
        def.setSource(source);
        beanDefs.add(registerPostProcessor(registry, def, PERSISTENCE_ANNOTATION_PROCESSOR_BEAN_NAME));
    }
	// 支撑spring-event相关注解的processor，对@EventListener的支撑
    if (!registry.containsBeanDefinition(EVENT_LISTENER_PROCESSOR_BEAN_NAME)) {
        RootBeanDefinition def = new RootBeanDefinition(EventListenerMethodProcessor.class);
        def.setSource(source);
        beanDefs.add(registerPostProcessor(registry, def, EVENT_LISTENER_PROCESSOR_BEAN_NAME));
    }
	// 支撑spring-event相关注解的processor，对@EventListener的支撑
    if (!registry.containsBeanDefinition(EVENT_LISTENER_FACTORY_BEAN_NAME)) {
        RootBeanDefinition def = new RootBeanDefinition(DefaultEventListenerFactory.class);
        def.setSource(source);
        beanDefs.add(registerPostProcessor(registry, def, EVENT_LISTENER_FACTORY_BEAN_NAME));
    }
    return beanDefs;
}
复制代码

到此，context:component-scan标签所作的全部事情都作完了。它主要就是建立了一个扫描器来扫描咱们基本的须要注册的bean，以后注册了一些支撑相应注解功能的Processor，对于这些Processor，我这边不会去单独讲解每一个Processor是何时被调用，怎么实现它的功能的，感兴趣的同窗能够自行找到对应的类去看实现逻辑。

而以后讲bean初始化逻辑和生命周期的时候，我会在特定的拓展点，讲到一些Processor的调用以及内部的逻辑，但愿到时候同窗们还能记起来这些Processor是在哪里注册的。

3、实践

都说实践出真知，咱们跟着源码分析了这么一大波，可是事实是否是如咱们分析的那样呢？为了证明一下，这边我简单使用一下spring预留的拓展点。

1. 使用context:component-scan扫描自定义注解

咱们首先须要自定义一个注解：

@Target({ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
public @interface MyService {
}
复制代码

而后配置一下context:component-scan标签：

<context:component-scan base-package="com.xiaoxizi.spring">
        <context:include-filter type="annotation" expression="com.xiaoxizi.spring.annotation.MyService"/>
    </context:component-scan>
复制代码

为咱们的业务类打上注解：

@Data
@MyService
public class MyAnnoClass {
    public String username = "xiaoxizi";
}
复制代码

运行：

public void test1() {
    applicationContext = new ClassPathXmlApplicationContext("spring.xml");
    MyAnnoClass myAnnoClass = applicationContext.getBean(MyAnnoClass.class);
    System.out.println(myAnnoClass);
}
复制代码

输出结果：

MyAnnoClass(username=xiaoxizi)
复制代码

说明咱们的自定义注解扫描到了，而且成功生成了beanDefinition并实例化了bean！

2. 自定义标签

先建立一个具体标签的解析类，咱们这边简单点，直接继承了spring内部的一个类：

public class SimpleBeanDefinitionParse extends AbstractSingleBeanDefinitionParser {
    @Override
    protected String getBeanClassName(final Element element) {
        System.out.println("SimpleBeanDefinitionParse ... getBeanClassName()");
        return element.getAttribute("className");
    }
}
复制代码

而后建立一个SimpleNamespaceHandler：

public class SimpleNamespaceHandler extends NamespaceHandlerSupport {
    @Override
    public void init() {
        System.out.println("SimpleNamespaceHandler ... init()");
        this.registerBeanDefinitionParser("simpleBean", new SimpleBeanDefinitionParse());
    }
}
复制代码

配置写入META-INF/spring.handlers文件：

http\://www.xiaoxize.com/schema/simple=com.xiaoxizi.spring.tag.SimpleNamespaceHandler
复制代码

xml配置中使用：

<xiaoxizi:simple className="com.xiaoxizi.spring.bean.MyAnnoClass"/>
<!-- 该标签对应的命名空间在xml文件头部beans标签中声明 -->
<beans xmlns:xiaoxizi="http://www.xiaoxize.com/schema/simple" ... />
复制代码

目标类：

@Data
// @MyService
public class MyAnnoClass {
    public String username = "xiaoxizi";
}
复制代码

运行：

public void test1() {
    applicationContext = new ClassPathXmlApplicationContext("spring.xml");
    MyAnnoClass myAnnoClass = applicationContext.getBean(MyAnnoClass.class);
    System.out.println(myAnnoClass);
}
复制代码

输出结果-各类报错，哈哈哈：

Caused by: org.xml.sax.SAXParseException; lineNumber: 21; columnNumber: 91; cvc-complex-type.2.4.c: 通配符的匹配很全面, 但没法找到元素 'xiaoxizi:simple' 的声明。
复制代码

emmmm，翻车车啦~这里仍是卡了一会的，主要是对xml规范的不熟悉致使的，原来咱们在声明命名空间的时候，还要声明并定义对应的XSD文件，（这里我本身写了一个xsd文件，并经过idea的配置引入了工做空间）像这样：

<xiaoxizi:simple className="com.xiaoxizi.spring.bean.MyAnnoClass"/>
<!-- 该标签对应的命名空间在xml文件头部beans标签中声明 -->
<beans xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xiaoxizi="http://www.xiaoxize.com/schema/simple" xsi:schemaLocation=" http://www.xiaoxize.com/schema/simple http://www.xiaoxize.com/schema/simple.xsd" ... />
复制代码

而后发现仍是不行：

java.net.UnknownHostException: www.xiaoxize.com
org.xml.sax.SAXParseException: schema_reference.4: 没法读取方案文档 'http://www.xiaoxize.com/schema/simple.xsd', 缘由为 1) 没法找到文档; 2) 没法读取文档; 3) 文档的根元素不是 <xsd:schema>。
Caused by: org.xml.sax.SAXParseException; lineNumber: 21; columnNumber: 91; cvc-complex-type.2.4.c: 通配符的匹配很全面, 但没法找到元素 'xiaoxizi:simple' 的声明。
复制代码

啊，原来spring解析这个xml的时候，是不归idea管的，他仍是会去对应的域名下找这个xsd文件（而我根本没有xiaoxizi这个域名...），最后我把xsd文件丢到本身服务器上，而且调整了域名那些，终于能够了：

SimpleNamespaceHandler ... init()
SimpleBeanDefinitionParse ... getBeanClassName()
MyAnnoClass(username=xiaoxizi)
复制代码

大功告成，因此自定义标签仍是蛮简单的嘛（认真脸！

4、总结

1. 自定义标签解析过程

  1. 第一个自定义标签开始解析时，将会从全部jar包的META-INF/spring.handlers文件加载 自定义标签命名空间-对应NamespaceHandler全限定名到内存中的DefaultNamespaceHandlerResolver.handlerMappings
  2. 一样前缀的自定义标签第一次解析时，将会实例化对应的NamespaceHandler，并调用其init()方法，而后把自定义标签命名空间-对应NamespaceHandler实例放入handlerMappings，下次再有一样的标签过来解析，就直接能拿到对应的NamespaceHandler实例了
  3. 使用找到的NamespaceHandler实例的parse方法解析自定义标签
  4. spring贴心的为咱们准备了NamespaceHandler相关的模版类NamespaceHandlerSupport，若是咱们自定义的处理器继承了这个模版，那只须要在init方法中为具体的标签注入相应的BeanDefinitionParser或者BeanDefinitionDecorator就能够实现功能了

2. context:component-scan作了什么

  1. 自定义标签context:component-scan对应的解析器是ComponentScanBeanDefinitionParser（找的过程咱们不赘述了）。
  2. 解析器的parse方法中，咱们经过标签配置的属性建立了一个扫描器ClassPathBeanDefinitionScanner
  3. 默认状况下， 咱们会注册一个@Component注解的AnnotationTypeFilter，而且注册到扫描器的includeFilters中
  4. 而后扫描器开始扫描basePackage下全部的java类，而且找到全部不须要排除（excludeFilters）的候选类（includeFilters），而后为其生成一个beanDefinition，若是该类是一个合法的beanDefinition（非接口那些判断），那么就会将这些beanDefinition收集起来并返回
  5. 对于全部的候选beanDefinition，扫描器还会进一步扫描类上的@Lazy、@Primary、@DependsOn等属性，而后设值到beanDefinition的对应属性中
  6. 最后一步，把咱们全部扫描到的全部合法的beanDefinition注册到IOC容器
  7. 因为@Component是@Service、@Controller等注解的源注解，因此@Service这些注解标记的类也会被includeFilters扫描到
  8. 注册一系列对@Configuration、@Autowired、@Resource等注解进行支撑的Processor

5、其余

实践中使用的的简单的XSD文件

<xsd:attribute name="className" type="xsd:string"></xsd:attribute>
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns="http://你的ip或者域名/simple" xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://你的ip或者域名/simple" elementFormDefault="qualified">
    <xsd:element name="simple">
        <xsd:complexType>
            <xsd:attribute name="className" type="xsd:string"></xsd:attribute>
            <xsd:attribute name="id" type="xsd:string"></xsd:attribute>
        </xsd:complexType>
    </xsd:element>
</xsd:schema>
复制代码

这一篇写完感受要把本身榨干了，好难写好多字...并且没有存稿了，以后的更新确定会比较慢了~

创做不易，转载请篇首注明 做者：掘金@小希子 + 来源连接~

若是想了解更多Spring源码知识，点击前往其他逐行解析Spring系列

٩(* ఠO ఠ)=3⁼³₌₃⁼³₌₃⁼³₌₃嘟啦啦啦啦。。。

这里是新人博主小希子，大佬们都看到这了，左上角点个赞再走吧~~

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程