@Enable驱动逻辑

这个系列分为5篇

 

1. @Component,@Service等注解是如何被解析的

2. @Enable驱动原理

3. @EnableAutoConfiguration处理逻辑

4. spring,springBoot事件

5.仅需四步,写一个springboot starter

前言

工作中经常用到,如下注解:

@EnableEurekaClient

@EnableFeignClients

@EnableCircuitBreaker

@EnableHystrix

他们都是@Enable开头,各自实现不同的功能,解析这种@Enable的逻辑是什么呢?

@Enable驱动逻辑

找入口

@Enable的模块驱动,依赖于@Import实现。

@Import作用是装载导入类,主要包括@Configuration class,ImportSelector实现类,ImportBeanDefinitionRegistrar实现类。

XML时代,经常是@Import,<context:component-scan>,<context:annotation-config>.一起使用。

<context:annotation-config>(注解配置)中大概率有我们需要找的逻辑。

根据 Spring Framework2.0引入的可扩展的XML编程机制,XML Schema命名空间需要与Handler建立映射关系。

该关系配置在相对于classpath下的/META-INF/spring.handlers中。

 

查看ContextNamespaceHandler 源码

public class ContextNamespaceHandler extends NamespaceHandlerSupport {
   @Override
   public void init() {
       //省略其他代码
    registerBeanDefinitionParser("annotation-config", 
                    new AnnotationConfigBeanDefinitionParser());
  }
}

<context:annotation-config> 对应AnnotationConfigBeanDefinitionParser这个就是要找的入口

 

找核心类

从AnnotationConfigBeanDefinitionParser的parse方法开始一路向下,找到

AnnotationConfigUtils.registerAnnotationConfigProcessors中注册了ConfigurationClassPostProcessor。

 

ConfigurationClassPostProcessor类注释说明

1. 用于的引导处理@Configuration类

2. <context:annotation-config/>或 <context:component-scan/>时会注册

否则需要手工编程

3. ConfigurationClassPostProcessor第一优先级,保证

@Configuration}类中声明@Bean,在其他 BeanFactoryPostProcessor执行之前被注册

扩展

AnnotationConfigApplicationContext中new AnnotationBeanDefinitionReader也调用了 AnnotationConfigUtils . registerAnnotationConfigProcessors

从类注释中,可以看出ConfigurationClassPostProcessor就是要找的核心类

找核心方法

查看 ConfigurationClassPostProcessor 的层级关系为

Aware系列注入相应资源,Ordered设置优先级,值得关注的就是

postProcessBeanDefinitionRegistry了。

postProcessBeanDefinitionRegistry其内部有2个方法

  1. postProcessBeanDefinitionRegistry在BeanDefinition注册之后,BeanFactoryPostProcessor执行之前,修改或重写BeanDefinition
  2. 继承自BeanFactoryPostProcessor的postProcessBeanFactory,BeanDefinition加载之后,Bean实例化之前,重写或添加BeanDefinition,修改BeanFactory

浏览2个方法,都有processConfigBeanDefinitions,从名称可以看出是处理配置类Bean定义

ConfigurationClassPostProcessor#processConfigBeanDefinitions就是要找的核心方法

 

梳理流程

public void processConfigBeanDefinitions(BeanDefinitionRegistry registry) {
   List<BeanDefinitionHolder> configCandidates = new ArrayList<>();
   String[] candidateNames = registry.getBeanDefinitionNames();

   for (String beanName : candidateNames) {
      BeanDefinition beanDef = registry.getBeanDefinition(beanName);
      if (ConfigurationClassUtils.isFullConfigurationClass(beanDef) ||
            ConfigurationClassUtils.isLiteConfigurationClass(beanDef)) {
         if (logger.isDebugEnabled()) {
            logger.debug("Bean definition has already been processed as a configuration class: " + beanDef);
         }
      }
      else if (ConfigurationClassUtils.checkConfigurationClassCandidate(beanDef, this.metadataReaderFactory)) {
         configCandidates.add(new BeanDefinitionHolder(beanDef, beanName));
      }
   }

   // 没有找到 @Configuration classes 立即返回
   if (configCandidates.isEmpty()) {
      return;
   }
   //根据@Order 值进行排序
   configCandidates.sort((bd1, bd2) -> {
      int i1 = ConfigurationClassUtils.getOrder(bd1.getBeanDefinition());
      int i2 = ConfigurationClassUtils.getOrder(bd2.getBeanDefinition());
      return Integer.compare(i1, i2);
   });
   //通过封闭的应用程序上下文, 检测任何自定义bean名称生成策略
   supplied through the enclosing application context
   SingletonBeanRegistry sbr = null;
   if (registry instanceof SingletonBeanRegistry) {
      sbr = (SingletonBeanRegistry) registry;
      if (!this.localBeanNameGeneratorSet) {
         BeanNameGenerator generator = (BeanNameGenerator) sbr.getSingleton(CONFIGURATION_BEAN_NAME_GENERATOR);
         if (generator != null) {
            this.componentScanBeanNameGenerator = generator;
            this.importBeanNameGenerator = generator;
         }
      }
   }
   if (this.environment == null) {
      this.environment = new StandardEnvironment();
   }
   // 解析@Configuration class
   ConfigurationClassParser parser = new ConfigurationClassParser(
         this.metadataReaderFactory, this.problemReporter, this.environment,
         this.resourceLoader, this.componentScanBeanNameGenerator, registry);

   Set<BeanDefinitionHolder> candidates = new LinkedHashSet<>(configCandidates);
   Set<ConfigurationClass> alreadyParsed = new HashSet<>(configCandidates.size());
   do {
      parser.parse(candidates);
      parser.validate();

      Set<ConfigurationClass> configClasses = new LinkedHashSet<>(parser.getConfigurationClasses());
      configClasses.removeAll(alreadyParsed);
      // 读ConfigurationClass的信息,创建BeanDefinition
      if (this.reader == null) {
         this.reader = new ConfigurationClassBeanDefinitionReader(
               registry, this.sourceExtractor, this.resourceLoader, this.environment,
               this.importBeanNameGenerator, parser.getImportRegistry());
      }
      this.reader.loadBeanDefinitions(configClasses);
      alreadyParsed.addAll(configClasses);

      candidates.clear();
      if (registry.getBeanDefinitionCount() > candidateNames.length) {
         String[] newCandidateNames = registry.getBeanDefinitionNames();
         Set<String> oldCandidateNames = new HashSet<>(Arrays.asList(candidateNames));
         Set<String> alreadyParsedClasses = new HashSet<>();
         for (ConfigurationClass configurationClass : alreadyParsed) {
            alreadyParsedClasses.add(configurationClass.getMetadata().getClassName());
         }
         for (String candidateName : newCandidateNames) {
            if (!oldCandidateNames.contains(candidateName)) {
               BeanDefinition bd = registry.getBeanDefinition(candidateName);
               if (ConfigurationClassUtils.checkConfigurationClassCandidate(bd, this.metadataReaderFactory) &&
                     !alreadyParsedClasses.contains(bd.getBeanClassName())) {
                  candidates.add(new BeanDefinitionHolder(bd, candidateName));
               }
            }
         }
         candidateNames = newCandidateNames;
      }
   }
   while (!candidates.isEmpty());

   // 将ImportRegistry注册为bean以支持importware@Configuration类
   if (sbr != null && !sbr.containsSingleton(IMPORT_REGISTRY_BEAN_NAME)) {
      sbr.registerSingleton(IMPORT_REGISTRY_BEAN_NAME, parser.getImportRegistry());
   }
   if (this.metadataReaderFactory instanceof CachingMetadataReaderFactory) {
      // Clear cache in externally provided MetadataReaderFactory; this is a no-op
      // for a shared cache since it'll be cleared by the ApplicationContext.
      ((CachingMetadataReaderFactory) this.metadataReaderFactory).clearCache();
   }
}

ConfigurationClassPostProcessor#processConfigBeanDefinitions核心如下:

  1. 根据@Order 值进行排序
  2. 解析@Configuration class 为ConfigurationClass对象
  3. 读ConfigurationClass的信息,创建BeanDefinition
  4. 将ImportRegistry注册为bean以支持importware@Configuration类

重点关注解析方法

ConfigurationClassParser#parse方法负责解析@Configuration class 为ConfigurationClass对象

查阅其源码如下:

ConfigurationClassParser#doProcessConfigurationClass代码如下:

protected final SourceClass doProcessConfigurationClass(ConfigurationClass configClass, SourceClass sourceClass)
      throws IOException {

   if (configClass.getMetadata().isAnnotated(Component.class.getName())) {
      // Recursively process any member (nested) classes first
      processMemberClasses(configClass, sourceClass);
   }

   // Process any @PropertySource annotations
   for (AnnotationAttributes propertySource : AnnotationConfigUtils.attributesForRepeatable(
         sourceClass.getMetadata(), PropertySources.class,
         org.springframework.context.annotation.PropertySource.class)) {
      if (this.environment instanceof ConfigurableEnvironment) {
         processPropertySource(propertySource);
      }
      else {
         logger.info("Ignoring @PropertySource annotation on [" + sourceClass.getMetadata().getClassName() +
               "]. Reason: Environment must implement ConfigurableEnvironment");
      }
   }

   // Process any @ComponentScan annotations
   Set<AnnotationAttributes> componentScans = AnnotationConfigUtils.attributesForRepeatable(
         sourceClass.getMetadata(), ComponentScans.class, ComponentScan.class);
   if (!componentScans.isEmpty() &&
         !this.conditionEvaluator.shouldSkip(sourceClass.getMetadata(), ConfigurationPhase.REGISTER_BEAN)) {
      for (AnnotationAttributes componentScan : componentScans) {
         // The config class is annotated with @ComponentScan -> perform the scan immediately
         Set<BeanDefinitionHolder> scannedBeanDefinitions =
               this.componentScanParser.parse(componentScan, sourceClass.getMetadata().getClassName());
         // Check the set of scanned definitions for any further config classes and parse recursively if needed
         for (BeanDefinitionHolder holder : scannedBeanDefinitions) {
            BeanDefinition bdCand = holder.getBeanDefinition().getOriginatingBeanDefinition();
            if (bdCand == null) {
               bdCand = holder.getBeanDefinition();
            }
            if (ConfigurationClassUtils.checkConfigurationClassCandidate(bdCand, this.metadataReaderFactory)) {
               parse(bdCand.getBeanClassName(), holder.getBeanName());
            }
         }
      }
   }

   // Process any @Import annotations
   processImports(configClass, sourceClass, getImports(sourceClass), true);

   // Process any @ImportResource annotations
   AnnotationAttributes importResource =
         AnnotationConfigUtils.attributesFor(sourceClass.getMetadata(), ImportResource.class);
   if (importResource != null) {
      String[] resources = importResource.getStringArray("locations");
      Class<? extends BeanDefinitionReader> readerClass = importResource.getClass("reader");
      for (String resource : resources) {
         String resolvedResource = this.environment.resolveRequiredPlaceholders(resource);
         configClass.addImportedResource(resolvedResource, readerClass);
      }
   }

   // Process individual @Bean methods
   Set<MethodMetadata> beanMethods = retrieveBeanMethodMetadata(sourceClass);
   for (MethodMetadata methodMetadata : beanMethods) {
      configClass.addBeanMethod(new BeanMethod(methodMetadata, configClass));
   }

   // Process default methods on interfaces
   processInterfaces(configClass, sourceClass);

   // Process superclass, if any
   if (sourceClass.getMetadata().hasSuperClass()) {
      String superclass = sourceClass.getMetadata().getSuperClassName();
      if (superclass != null && !superclass.startsWith("java") &&
            !this.knownSuperclasses.containsKey(superclass)) {
         this.knownSuperclasses.put(superclass, configClass);
         // Superclass found, return its annotation metadata and recurse
         return sourceClass.getSuperClass();
      }
   }

   // No superclass -> processing is complete
   return null;
}

ConfigurationClassParser#doProcessConfigurationClass(ConfigurationClass,AnnatationMetatdata)将@PropertySource @ComponentScan@Import,@ImportResource,@Bean等一起处理了。

看到这里基本逻辑已经理清 了,但是有一个疑问

@Configuration中的@Bean没有其他特殊处理吗?

 

浏览代码解决疑问

从上边浏览的代码可以看到完全模式,会被AOP增强

那什么是完全模式呢? 在ConfigurationClassUtils找到如下方法:

public class ConfigurationClassUtils{
//省略其他方法
public static boolean isFullConfigurationCandidate(AnnotationMetadata metadata) {
   return metadata.isAnnotated(Configuration.class.getName());
}
}

@Configuration class是完全模式,@Component,@Bean是轻量级模式

那AOP增强了作用是什么呢?查看 ConfigurationClassEnhancer 的类注释如下:

 

/**

* Enhances {@link Configuration } classes by generating a CGLIB subclass which

* interacts with the Spring container to respect bean scoping semantics for

* {@code @Bean} methods. Each such {@code @Bean} method will be overridden in

* the generated subclass, only delegating to the actual {@code @Bean} method

* implementation if the container actually requests the construction of a new

* instance. Otherwise, a call to such an {@code @Bean} method serves as a

* reference back to the container, obtaining the corresponding bean by name.

*

* @author Chris Beams

* @author Juergen Hoeller

* @since 3.0

* @see #enhance

* @see ConfigurationClassPostProcessor

*/

class ConfigurationClassEnhancer {

 

大概意思如下:

通过CGLIB增强@Configuration class。

每个@Bean方法会生成子类。

首次被调用时,@Bean方法会被执行用于创建bean实例;

再次被调用时,不会再执行创建bean实例,而是根据bean名称返回首次该方法被执行时创建的bean实例。

 

总结

1.ConfigurationClassPostProcessor负责筛选@Component Class、@Configuration Class以及@Bean定义的Bean,**

2.ConfigurationClassParser从候选的Bean定义中解析出ConfigurationClass集合,随后被3.ConfigurationClassBeanDefinitionReader转换为BeanDefinition

4.ConfigurationClassParser的解析顺序,

@PropertySource->@ComponentScan->@Import->@ImportResource->@Bean->接口的默认方法->处理父类

5.@Configuration class是完全模式,@Component,@Bean是轻量级模式

6.CGLIB增强@Configuration class。每个@Bean方法会生成子类。

首次被调用时,@Bean方法会被执行用于创建bean实例;

再次被调用时,不会再执行创建bean实例,而是根据bean名称返回首次该方法被执行时创建的bean实例。

<think>嗯,用户问的是所有@Enable开头的Spring注解是否必须标注在配置类上。这个问题涉及到Spring框架中配置类的核心机制,需要结合系统提供的三个引用内容来分析。 从引用[3]可以明确看到,@Configuration注解用于定义配置类,它能替代传统的XML配置文件。这类配置类的关键特性是被@Bean注解的方法会被Spring容器扫描处理。而引用[2]详细说明了@EnableXXX注解的工作原理,它们本质上是通过@Import机制来导入特定配置,比如@EnableScheduling导入定时任务相关的bean定义。 用户的核心疑问在于使用位置限制。这里需要区分两个概念:配置类和普通类。根据Spring的设计原则,@EnableXXX注解通常应该用在配置类上,因为: - 配置类(@Configuration)是Spring容器初始化的入口点 - @EnableXXX需要与@Configuration配合才能完整定义bean - 某些@Enable注解内部就包含@Configuration元注解 不过也存在例外情况,比如在Spring Boot应用中,@SpringBootApplication注解(内含@Configuration)通常作为主配置类,其他@Enable注解可以直接标注在启动类上。这说明严格来说,重点不在于物理位置,而在于被注解的类是否会被Spring识别为配置源。 用户可能正在学习Spring配置方式,或者遇到了某些@Enable注解不生效的问题。需要强调虽然技术上可以直接标注在普通类,但最佳实践仍是统一使用配置类,这样能保证bean定义被正确处理,避免因类未被扫描而导致的配置失效问题。 最后想到可以补充说明Spring的注解驱动原理:通过AnnotationConfigApplicationContext加载配置类时,它会递归处理所有相关注解,包括@Import引入的配置。这也是为什么嵌套配置类必须声明为static——保证在不实例化外部类的情况下就能处理内部配置。 </think>关于`@EnableXXX`系列注解的使用位置,**并非所有都必须标注在配置类上**,但最佳实践强烈推荐标注在配置类(`@Configuration`类)上。具体分析如下: --- ### 一、核心规则与最佳实践 1. **`@EnableXXX`本质依赖`@Import`** 如引用[2]所述,`@EnableScheduling`、`@EnableCaching`等注解通过`@Import`导入特定配置类(如`SchedulingConfiguration`),这些配置类包含`@Bean`方法。**`@Import`的目标类必须是配置逻辑的载体**,通常需被Spring容器识别为配置源[^2]。 2. **配置类是标准载体** `@Configuration`类(如引用[3])是Spring官方定义的配置单元,其内部的`@Bean`方法会被容器自动代理(CGLIB增强),确保Bean单例语义。若`@EnableXXX`标注在普通类(非`@Configuration`),可能因代理缺失导致Bean重复创建或依赖注入异常[^3]。 3. **直接标注在普通类的风险** * **场景1**:标注在`@Component`类 容器能扫描到注解并激活功能,但导入的配置类可能因未被代理而产生副作用(如`@Bean`方法多次调用)。 * **场景2**:标注在未被扫描的类 功能完全失效,因容器无法发现该注解。 --- ### 二、典型示例分析 | **注解类型** | **是否强制要求配置类** | **说明** | |--------------------------|------------------------|--------------------------------------------------------------------------| | `@EnableScheduling` | 否(但推荐) | 标注在普通类可激活定时任务,但若导入的Bean需代理则可能出错[^2]。 | | `@EnableAsync` | **是** | 依赖AOP代理,若标注在非配置类,异步方法拦截可能失效。 | | `@EnableTransactionManagement` | **强烈推荐** | 事务管理依赖AOP,必须由配置类加载以确保代理生效。 | | `@EnableWebMvc` | **是** | Spring MVC要求必须在配置类上,否则导致Web组件注册失败。 | > ✅ **结论**: > 虽然部分`@EnableXXX`在普通类上能“勉强工作”,但**Spring官方设计意图是将其用于配置类**。理由有三: > 1. 保证`@Import`的配置类被正确代理; > 2. 集中管理配置逻辑,避免分散; > 3. 与`@Configuration`的嵌套、外部化配置等特性兼容(引用[1][3])。 --- ### 三、正确用法演示 ```java // 主配置类(必须为@Configuration) @Configuration @EnableCaching // ✅ 推荐:激活缓存 @EnableAsync // ✅ 必须:激活异步方法 public class AppConfig { @Bean public CacheManager cacheManager() {...} } // 辅助配置类(嵌套静态类) @Configuration public class DatabaseConfig { @Configuration // ✅ 静态嵌套配置类(引用[1]) public static class JpaConfig { @EnableJpaRepositories // ✅ 激活JPA仓库 public static class RepoConfig {...} } } ``` --- ### 相关问题 1. `@EnableXXX`注解在Spring Boot自动配置中如何被加载? 2. 如果在非配置类上使用`@EnableTransactionManagement`,事务为何可能失效? 3. Spring如何通过`@Import`实现模块化配置(如`@EnableScheduling`导入定时任务Bean)? 4. `@Configuration`与`@Component`作为配置载体的核心区别是什么? [^1]: 配置类嵌套需静态类,且用于组织关联Bean定义。 [^2]: `@EnableXXX`本质是模块化配置的入口,通过`@Import`聚合功能组件。 [^3]: `@Configuration`的CGLIB代理保障了`@Bean`方法的单例语义。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值