一、自定義標簽是什么？

上一篇我們講了默認標簽-bean標簽的解析，今天我們講一下自定義標簽的解析。

1. 自定義標簽的定義

這個問題其實上一篇有講過，這邊再復述一遍，在spring的xml配置文件中，我們可以把所有的標簽分為兩類：自定義標簽和默認標簽，區別如下

復制代碼

需要注意的是，自定義標簽的概念，并不完全只指我們開發時自己定義的標簽，而是spring的開發者為之后拓展預留的拓展點，這個拓展點我們可以用，spring的開發人員在為spring添加新功能時，也可以使用。

2. 關于spring內置的自定義標簽context:component-scan

我們現在的開發中，更多的情況下，其實是使用@Configuration、@Component、@Service 等注解來進行bean的聲明而不是使用xml的bean 標簽了。

那么為什么一個類加上了這些注解之后，就能被spring管理了呢？

實際上這些拓展功能是spring通過自己預留的自定義標簽的拓展點進行拓展的，對于上述的功能，具體是使用的context:component-scan標簽。

我們今天就通過對自定義標簽context:component-scan的解析來跟蹤一下相應的源碼，理解spring自定義標簽解析的流程，同時也對context:component-scan實現的功能做一個講解，看一下@Component等標簽的實現原理。

二、源碼解析

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); }}@Nullablepublic 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 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 getHandlerMappings() { Map 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.ContextNamespaceHandlerhttp://www.springframework.org/schema/jee=org.springframework.ejb.config.JeeNamespaceHandlerhttp://www.springframework.org/schema/lang=org.springframework.scripting.config.LangNamespaceHandlerhttp://www.springframework.org/schema/task=org.springframework.scheduling.config.TaskNamespaceHandlerhttp://www.springframework.org/schema/cache=org.springframework.cache.config.CacheNamespaceHandler復制代碼

我們在回憶一下自定義標簽的定義：

復制代碼

可以看到我們的META-INF/spring.handlers文件中key就是自定義標簽的namespaceUri，value則是對應的NamespaceHandler的全限定名。

那么簡單總結一下，我們的自定義標簽解析的流程就是：

加載所有jar中META-INF/spring.handlers文件中的namespaceUri和NamespaceHandler的全限定名的映射關系到handlerMappings

根據namespaceUri從handlerMappings獲取對象 如果從handlerMappings獲取到的對象為空，直接返回 如果獲取到的是NamespaceHandler對象，直接使用 如果獲取到的對象是string類型，則實例化這個string對應的全限定名的NamespaceHandler對象，并調用init()方法，然后將 namespaceUri-NamespaceHandler對象關系放回handlerMappings

將自定義標簽委托給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 parsers = new HashMap<>(); // 保存標簽名-裝飾器對應關系的容器 private final Map decorators = new HashMap<>(); // 保存屬性名-裝飾器對應關系的容器 private final Map 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 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)) { // 如果是標簽則創建一個Filter并加入includeFilters TypeFilter typeFilter = createTypeFilter((Element) node, classLoader, parserContext); scanner.addIncludeFilter(typeFilter); } else if (EXCLUDE_FILTER_ELEMENT.equals(localName)) { // 如果是標簽則創建一個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) 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 doScan(String... basePackages) { for (String basePackage : basePackages) { // 找到所以掃描到的beanDefinition Set 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 scanCandidateComponents(String basePackage) { Set 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 beanDefinitions = scanner.doScan(basePackages); // 注冊一些組件 registerComponents(parserContext.getReaderContext(), beanDefinitions, element); return null;}復制代碼

我們看一下registerComponents方法：

protected void registerComponents( XmlReaderContext readerContext, Set 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 processorDefinitions = // 注冊一些支撐注解功能的Processors AnnotationConfigUtils.registerAnnotationConfigProcessors(readerContext.getRegistry(), source); // ... } // ...}復制代碼

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

public static Set registerAnnotationConfigProcessors( BeanDefinitionRegistry registry, @Nullable Object source) { // ... Set 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是在哪里注冊的。

三、實踐

都說實踐出真知，我們跟著源碼分析了這么一大波，但是事實是不是如我們分析的那樣呢？為了證實一下，這邊我簡單使用一下spring預留的拓展點。

1. 使用context:component-scan掃描自定義注解

我們首先需要自定義一個注解：

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

然后配置一下context:component-scan標簽：

復制代碼

為我們的業務類打上注解：

@Data@MyServicepublic 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配置中使用：

復制代碼

目標類：

@Data// @MyServicepublic 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的配置引入了工作空間)像這樣：

復制代碼

然后發現還是不行：

java.net.UnknownHostException: www.xiaoxize.comorg.xml.sax.SAXParseException: schema_reference.4: 無法讀取方案文檔 'http://www.xiaoxize.com/schema/simple.xsd', 原因為 1) 無法找到文檔; 2) 無法讀取文檔; 3) 文檔的根元素不是 。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)復制代碼

大功告成，所以自定義標簽還是蠻簡單的嘛(認真臉！

四、總結

1. 自定義標簽解析過程

第一個自定義標簽開始解析時，將會從所有jar包的META-INF/spring.handlers文件加載 自定義標簽命名空間-對應NamespaceHandler全限定名到內存中的DefaultNamespaceHandlerResolver.handlerMappings

同樣前綴的自定義標簽第一次解析時，將會實例化對應的NamespaceHandler，并調用其init()方法，然后把自定義標簽命名空間-對應NamespaceHandler實例放入handlerMappings，下次再有同樣的標簽過來解析，就直接能拿到對應的NamespaceHandler實例了

使用找到的NamespaceHandler實例的parse方法解析自定義標簽

spring貼心的為我們準備了NamespaceHandler相關的模版類NamespaceHandlerSupport，如果我們自定義的處理器繼承了這個模版，那只需要在init方法中為具體的標簽注入相應的BeanDefinitionParser或者BeanDefinitionDecorator就可以實現功能了

2. context:component-scan做了什么

自定義標簽context:component-scan對應的解析器是ComponentScanBeanDefinitionParser(找的過程我們不贅述了)。

解析器的parse方法中，我們通過標簽配置的屬性創建了一個掃描器ClassPathBeanDefinitionScanner

默認情況下， 我們會注冊一個@Component注解的AnnotationTypeFilter，并且注冊到掃描器的includeFilters中

然后掃描器開始掃描basePackage下所有的java類，并且找到所有不需要排除(excludeFilters)的候選類(includeFilters)，然后為其生成一個beanDefinition，如果該類是一個合法的beanDefinition(非接口那些判斷)，那么就會將這些beanDefinition收集起來并返回

對于所有的候選beanDefinition，掃描器還會進一步掃描類上的@Lazy、@Primary、@DependsOn等屬性，然后設值到beanDefinition的對應屬性中

最后一步，把我們所有掃描到的所有合法的beanDefinition注冊到IOC容器

由于@Component是@Service、@Controller等注解的源注解，所以@Service這些注解標記的類也會被includeFilters掃描到

注冊一系列對@Configuration、@Autowired、@Resource等注解進行支撐的Processor

五、其他

實踐中使用的的簡單的XSD文件

<?xml version="1.0" encoding="UTF-8"?>復制代碼

多多支持，即可免費獲取以上所有資料--轉發+評論，關注我，私信口令 “Java” ，(承諾100%免費)

希望大家將此篇文章分享，轉載，讓更多需要的朋友看到，這樣不僅幫助了自己，也幫助了他人，謝謝！！

總結

以上是生活随笔為你收集整理的component是什么接口_逐行解读Spring（二）什么，自定义标签没听说过？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。