@Component和@Configuration作为配置类的差别

àì夳堔傛蜴生んèń 2024-02-24 01:15 34阅读 0赞

@[Component][]和@Configuration是有区别的，错误的使用可能会导致严重的后果。

请看下面一段代码：

1.  `@Configuration`
2.  `public class MyTestConfig {`
3.  
4.  `@Bean`
5.  `public Driver driver(){`
6.  `Driver driver = new Driver();`
7.  `driver.setId(1);`
8.  `driver.setName("driver");`
9.  `driver.setCar(car());`
10. `return driver;`
11. `}`
12. 
13. `@Bean`
14. `public Car car(){`
15. `Car car = new Car();`
16. `car.setId(1);`
17. `car.setName("car");`
18. `return car;`
19. `}`
20. `}`

测试代码如下：

1.  `@RunWith(SpringRunner.class)`
2.  `@SpringBootTest`
3.  `public class TestApplicationTests {`
4.  
5.  `@Autowired`
6.  `private Car car;`
7.  
8.  `@Autowired`
9.  `private Driver driver;`
10. 
11. `@Test`
12. `public void contextLoads() {`
13. `boolean result = driver.getCar() == car;`
14. `System.out.println(result ? "同一个car" : "不同的car");`
15. `}`
16. 
17. `}`

打印结果如下： 同一个car

替换为Component后的打印结果：

不同的car

从上面的结果可以发现使用[Configuration][]时在driver和spring容器之中的是同一个对象，而使用Component时是不同的对象。

造成不同结果的原因在ConfigurationClassPostProcessor类之中，通过调用enhanceConfigurationClasses方法，为被注解@Configuration的类进行CGLIB代理，代码如下：

1.  `public void enhanceConfigurationClasses(ConfigurableListableBeanFactory beanFactory) {`
2.  `Map<String, AbstractBeanDefinition> configBeanDefs = new LinkedHashMap<String, AbstractBeanDefinition>();`
3.  `for (String beanName : beanFactory.getBeanDefinitionNames()) {`
4.  `BeanDefinition beanDef = beanFactory.getBeanDefinition(beanName);`
5.  `if (ConfigurationClassUtils.isFullConfigurationClass(beanDef)) {//判断是否被@Configuration标注`
6.  `if (!(beanDef instanceof AbstractBeanDefinition)) {`
7.  `throw new BeanDefinitionStoreException("Cannot enhance @Configuration bean definition '" +`
8.  `beanName + "' since it is not stored in an AbstractBeanDefinition subclass");`
9.  `}`
10. `else if (logger.isWarnEnabled() && beanFactory.containsSingleton(beanName)) {`
11. `logger.warn("Cannot enhance @Configuration bean definition '" + beanName +`
12. `"' since its singleton instance has been created too early. The typical cause " +`
13. `"is a non-static @Bean method with a BeanDefinitionRegistryPostProcessor " +`
14. `"return type: Consider declaring such methods as 'static'.");`
15. `}`
16. `configBeanDefs.put(beanName, (AbstractBeanDefinition) beanDef);`
17. `}`
18. `}`
19. `if (configBeanDefs.isEmpty()) {`
20. `// nothing to enhance -> return immediately`
21. `return;`
22. `}`
23. `ConfigurationClassEnhancer enhancer = new ConfigurationClassEnhancer();`
24. `for (Map.Entry<String, AbstractBeanDefinition> entry : configBeanDefs.entrySet()) {`
25. `AbstractBeanDefinition beanDef = entry.getValue();`
26. `// If a @Configuration class gets proxied, always proxy the target class`
27. `beanDef.setAttribute(AutoProxyUtils.PRESERVE_TARGET_CLASS_ATTRIBUTE, Boolean.TRUE);`
28. `try {`
29. `// Set enhanced subclass of the user-specified bean class`
30. `Class<?> configClass = beanDef.resolveBeanClass(this.beanClassLoader);`
31. `Class<?> enhancedClass = enhancer.enhance(configClass, this.beanClassLoader);//生成代理的class`
32. `if (configClass != enhancedClass) {`
33. `if (logger.isDebugEnabled()) {`
34. `logger.debug(String.format("Replacing bean definition '%s' existing class '%s' with " +`
35. `"enhanced class '%s'", entry.getKey(), configClass.getName(), enhancedClass.getName()));`
36. `}`
37. `//替换class，将原来的替换为CGLIB代理的class`
38. `beanDef.setBeanClass(enhancedClass);`
39. `}`
40. `}`
41. `catch (Throwable ex) {`
42. `throw new IllegalStateException("Cannot load configuration class: " + beanDef.getBeanClassName(), ex);`
43. `}`
44. `}`
45. `}`

判断是否为配置类的代码如下：

1.  `//是否为配置类`
2.  `public static boolean isConfigurationCandidate(AnnotationMetadata metadata) {`
3.  `return (isFullConfigurationCandidate(metadata) || isLiteConfigurationCandidate(metadata));`
4.  `}`
5.  
6.  `//是否为完整配置类`
7.  `public static boolean isFullConfigurationCandidate(AnnotationMetadata metadata) {`
8.  `return metadata.isAnnotated(Configuration.class.getName());`
9.  `}`
10. `//是否为精简配置类`
11. `public static boolean isLiteConfigurationCandidate(AnnotationMetadata metadata) {`
12. `// Do not consider an interface or an annotation...`
13. `if (metadata.isInterface()) {`
14. `return false;`
15. `}`
16. 
17. `// Any of the typical annotations found?`
18. `for (String indicator : candidateIndicators) {`
19. `if (metadata.isAnnotated(indicator)) {`
20. `return true;`
21. `}`
22. `}`
23. 
24. `// Finally, let's look for @Bean methods...`
25. `try {`
26. `return metadata.hasAnnotatedMethods(Bean.class.getName());`
27. `}`
28. `catch (Throwable ex) {`
29. `if (logger.isDebugEnabled()) {`
30. `logger.debug("Failed to introspect @Bean methods on class [" + metadata.getClassName() + "]: " + ex);`
31. `}`
32. `return false;`
33. `}`
34. `}`
35. `//精简配置类包含的注解`
36. `static {`
37. `candidateIndicators.add(Component.class.getName());`
38. `candidateIndicators.add(ComponentScan.class.getName());`
39. `candidateIndicators.add(Import.class.getName());`
40. `candidateIndicators.add(ImportResource.class.getName());`
41. `}`

从上面可以看到，虽然Component注解也会当做配置类，但是并不会为其生成CGLIB代理Class，所以在生成Driver对象时和生成Car对象时调用car()方法执行了两次new操作，所以是不同的对象。当时Configuration注解时，生成当前对象的子类Class，并对方法拦截，第二次调用car()方法时直接从BeanFactory之中获取对象，所以得到的是同一个对象。

至于产生CGLIB代理的流程，可以看一下下面链接，其中含有详细介绍：[透过现象看原理：详解Spring中Bean的this调用导致AOP失效的原因 - 光闪的个人空间 - OSCHINA - 中文开源技术交流社区在我们使用Spring时，可能有前辈教导过我们，在bean中不要使用this来调用被@Async、@Transactional、@Cacheable等注解标注的方法，this下注解是不生效的。这是为什么呢？本文将代理遨游在源码的海洋中，寻找到这个问题的真相编辑https://my.oschina.net/guangshan/blog/1807721][Spring_Bean_this_AOP_ - _ - OSCHINA - _Spring_bean_this_Async_Transactional_Cacheable_this_https_my.oschina.net_guangshan_blog_1807721]

[Component]: https://so.csdn.net/so/search?q=Component&spm=1001.2101.3001.7020
[Configuration]: https://so.csdn.net/so/search?q=Configuration&spm=1001.2101.3001.7020
[Spring_Bean_this_AOP_ - _ - OSCHINA - _Spring_bean_this_Async_Transactional_Cacheable_this_https_my.oschina.net_guangshan_blog_1807721]: https://my.oschina.net/guangshan/blog/1807721