逐行解讀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教程