Spring中@Configuration和@Component注解的區(qū)別及原理
1.背景
隨著Spring Boot的盛行,注解配置式開發(fā)受到了大家的青睞,從此告別了基于Spring開發(fā)的繁瑣XML配置。
這里先來提綱挈領(lǐng)的了解一下Spring內(nèi)部對于配置注解的定義,如@Component、@Configuration、@Bean、@Import等注解
從功能上來講,這些注解所負(fù)責(zé)的功能的確不相同,但是從本質(zhì)上來講,Spring內(nèi)部都將其作為配置注解進(jìn)行處理。
對于一個成熟的框架來講,簡單及多樣化的配置是至關(guān)重要的,那么Spring也是如此,從Spring的配置發(fā)展過程來看,整體的配置方式從最初比較“原始”的階段到現(xiàn)在非常“智能”的階段,這期間Spring做出的努力是非常巨大的,從XML到自動裝配,從Spring到Spring Boot,從@Component到@Configuration以及@Conditional,Spring發(fā)展到今日,在越來越好用的同時,也為我們隱藏了諸多的細(xì)節(jié),那么今天讓我們一起探秘@Component與@Configuration。
我們平時在Spring的開發(fā)工作中,基本都會使用配置注解,尤其以@Component及@Configuration為主,當(dāng)然在Spring中還可以使用其他的注解來標(biāo)注一個類為配置類,這是廣義上的配置類概念,但是這里我們只討論@Component和@Configuration,因?yàn)榕c我們的開發(fā)工作關(guān)聯(lián)比較緊密,那么接下來我們先討論下一個問題,就是 @Component與@Configuration有什么區(qū)別?
2.@Component與@Configuration使用
2.1注解定義
在討論兩者區(qū)別之前,先來看看兩個注解的定義:
@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Indexed
public @interface Component {
?
/**
* The value may indicate a suggestion for a logical component name,
* to be turned into a Spring bean in case of an autodetected component.
* @return the suggested component name, if any (or empty String otherwise)
*/
String value() default "";
?
}@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Component
public @interface Configuration {
?
@AliasFor(annotation = Component.class)
String value() default "";
?
boolean proxyBeanMethods() default true;
?
}從定義來看, @Configuration 注解本質(zhì)上還是 @Component,因此 @ComponentScan 能掃描到@Configuration 注解的類。
2.2注解使用
接下來看看兩者在我們?nèi)粘i_發(fā)中的使用:以這兩種注解來標(biāo)注一個類為配置類
@Configuration
public class AppConfig {
}
?
@Component
public class AppConfig {
}
上面的程序,Spring會將其認(rèn)為配置類來做處理,但是這里有一個概念需要明確一下,就是在Spring中,對于配置類來講,其實(shí)是有分類的,大體可以分為兩類,一類稱為LITE模式,另一類稱為FULL模式,那么對應(yīng)上面的注解,@Component就是LITE類型,@Configuration就是FULL類型,如何理解這兩種配置類型呢?我們先來看這個程序。
當(dāng)我們使用@Component實(shí)現(xiàn)配置類時:
@Component
public class AppConfig {
@Bean
public Foo foo() {
System.out.println("foo() invoked...");
Foo foo = new Foo();
System.out.println("foo() 方法的 foo hashcode: " + foo.hashCode());
return foo;
}
?
@Bean
public Eoo eoo() {
System.out.println("eoo() invoked...");
Foo foo = foo();
System.out.println("eoo() 方法的 foo hashcode: "+ foo.hashCode());
return new Eoo();
}
?
public static void main(String[] args) {
AnnotationConfigApplicationContext context =
new AnnotationConfigApplicationContext(AppConfig.class);
}
}執(zhí)行結(jié)果如下:
foo() invoked...
foo() 方法的 foo hashcode: 815992954
eoo() invoked...
foo() invoked...
foo() 方法的 foo hashcode: 868737467
eoo() 方法的 foo hashcode: 868737467
從結(jié)果可知,foo()方法執(zhí)行了兩次,一次是bean方法執(zhí)行的,一次是eoo()調(diào)用執(zhí)行的,所以兩次生成的foo對象是不一樣的。很符合大家的預(yù)期,但是當(dāng)我們使用@Configuration標(biāo)注配置類時,執(zhí)行結(jié)果如下:
foo() invoked...
foo() 方法的 foo hashcode: 849373393
eoo() invoked...
eoo() 方法的 foo hashcode: 849373393
這里可以看到foo()方法只執(zhí)行了一次,同時eoo()方法調(diào)用foo()生成的foo對象是同一個。這也就是@Component和@Configuration的區(qū)別現(xiàn)象展示,那么為什么會有這樣的一個現(xiàn)象?我們來考慮一個問題,就是eoo()方法中調(diào)用了foo()方法,很明顯這個foo()這個方法就是會形成一個新對象,假設(shè)我們調(diào)用的foo()方法不是原來的foo()方法,是不是就可能不會形成新對象?如果我們在調(diào)用foo()方法的時候去容器中獲取一下foo這個Bean,是不是就可以達(dá)到這樣的效果?那如何才能達(dá)到這樣的效果呢?有一個方法,代理!換句話說,我們調(diào)用的eoo()和foo()方法,包括AppConfig都被Spring代理了,那么這里我們明白了@Component與@Configuration最根本的區(qū)別,那就是@Configuration標(biāo)注的類會被Spring代理,其實(shí)這樣描述不是非常嚴(yán)謹(jǐn),更加準(zhǔn)確的來說應(yīng)該是如果一個類的BeanDefinition的Attribute中有Full配置屬性,那么這個類就會被Spring代理
3.Spring如何實(shí)現(xiàn)FULL配置的代理
如果要明白這一點(diǎn),那么還需要明確一個前提,就是Spring在什么時間將這些配置類轉(zhuǎn)變成FULL模式或者LITE模式的,接下來我們就要介紹個人認(rèn)為在Spring中非常重要的一個類,ConfigurationClassPostProcessor。
3.1ConfigurationClassPostProcessor是什么
首先來簡單的看一下這個類的定義:
public class ConfigurationClassPostProcessor implements
BeanDefinitionRegistryPostProcessor,
PriorityOrdered,
ResourceLoaderAware,
BeanClassLoaderAware,
EnvironmentAware {}由這個類定義可知這個類的類型為BeanDefinitionRegistryPostProcessor,以及實(shí)現(xiàn)了眾多Spring內(nèi)置的Aware接口,如果了解Beanfactory的后置處理器,那應(yīng)該清楚ConfigurationClassPostProcessor的執(zhí)行時機(jī),當(dāng)然不了解也沒有問題,我們會在后面將整個流程闡述清楚,現(xiàn)在需要知道的是ConfigurationClassPostProcessor這個類是在什么時間被實(shí)例化的?
3.2ConfigurationClassPostProcessor在什么時間被實(shí)例化
要回答這個問題,需要先明確一個前提,那就是ConfigurationClassPostProcessor這個類對應(yīng)的BeanDefinition在什么時間注冊到Spring的容器中的,因?yàn)镾pring的實(shí)例化比較特殊,主要是基于BeanDefinition來處理的,那么現(xiàn)在這個問題就可以轉(zhuǎn)變?yōu)镃onfigurationClassPostProcessor這個類是在什么時間被注冊為一個Beandefinition的?這個可以在源代碼中找到答案,具體其實(shí)就是在初始化這個Spring容器的時候。
new AnnotationConfigApplicationContext(ConfigClass.class)
-> new AnnotatedBeanDefinitionReader(this);
-> AnnotationConfigUtils.registerAnnotationConfigProcessors(this.registry);
-> new RootBeanDefinition(ConfigurationClassPostProcessor.class);
-> registerPostProcessor(BeanDefinitionRegistry registry, RootBeanDefinition definition, String beanName)從這里可以看出,ConfigurationClassPostProcessor已經(jīng)被注冊為了一個BeanDefinition,上面我們講了Spring是通過對BeanDefinition進(jìn)行解析,處理,實(shí)例化,填充,初始化以及眾多回調(diào)等等步驟才會形成一個Bean,那么現(xiàn)在ConfigurationClassPostProcessor既然已經(jīng)形成了一個BeanDefinition。
3.3 @Component與@Configuration的實(shí)現(xiàn)區(qū)別
上面ConfigurationClassPostProcessor已經(jīng)注冊到BeanDefinition注冊中心了,說明Spring會在某個時間點(diǎn)將其處理成一個Bean,那么具體的時間點(diǎn)就是在BeanFactory所有的后置處理器的處理過程。
AbstractApplicationContext
-> refresh()
-> invokeBeanFactoryPostProcessors(beanFactory);
-> PostProcessorRegistrationDelegate.invokeBeanFactoryPostProcessors(beanFactory, getBeanFactoryPostProcessors());這個處理BeanFactory的后置處理器的方法比較復(fù)雜,簡單說來就是主要處理所有實(shí)現(xiàn)了BeanFactoryPostProcessor及BeanDefinitionRegistryPostProcessor的類,當(dāng)然ConfigurationClassPostProcessor就是其中的一個,那么接下來我們看看實(shí)現(xiàn)的方法:
@Override
public void postProcessBeanDefinitionRegistry(BeanDefinitionRegistry registry) {
int registryId = System.identityHashCode(registry);
if (this.registriesPostProcessed.contains(registryId)) {
throw new IllegalStateException(
"postProcessBeanDefinitionRegistry already called on this post-processor against " + registry);
}
if (this.factoriesPostProcessed.contains(registryId)) {
throw new IllegalStateException(
"postProcessBeanFactory already called on this post-processor against " + registry);
}
this.registriesPostProcessed.add(registryId);
?
processConfigBeanDefinitions(registry);
}
@Override
public void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) {
int factoryId = System.identityHashCode(beanFactory);
if (this.factoriesPostProcessed.contains(factoryId)) {
throw new IllegalStateException(
"postProcessBeanFactory already called on this post-processor against " + beanFactory);
}
this.factoriesPostProcessed.add(factoryId);
if (!this.registriesPostProcessed.contains(factoryId)) {
// BeanDefinitionRegistryPostProcessor hook apparently not supported...
// Simply call processConfigurationClasses lazily at this point then.
processConfigBeanDefinitions((BeanDefinitionRegistry) beanFactory);
}
?
enhanceConfigurationClasses(beanFactory);
beanFactory.addBeanPostProcessor(new ImportAwareBeanPostProcessor(beanFactory));
}這兩個方法應(yīng)該就是ConfigurationClassPostProcessor最為關(guān)鍵的了,我們在這里先簡單的總結(jié)一下,第一個方法主要完成了內(nèi)部類,@Component,@ComponentScan,@Bean,@Configuration,@Import等等注解的處理,然后生成對應(yīng)的BeanDefinition,另一個方法就是對@Configuration使用CGLIB進(jìn)行增強(qiáng),那我們先來看Spring是在哪里區(qū)分配置的LITE模式和FULL模式?在第一個方法中有一個checkConfigurationClassCandidate方法:
public static boolean checkConfigurationClassCandidate(
BeanDefinition beanDef, MetadataReaderFactory metadataReaderFactory) {
// ...
Map<String, Object> config = metadata.getAnnotationAttributes(Configuration.class.getName());
if (config != null && !Boolean.FALSE.equals(config.get("proxyBeanMethods"))) {
beanDef.setAttribute(CONFIGURATION_CLASS_ATTRIBUTE, CONFIGURATION_CLASS_FULL);
}
else if (config != null || isConfigurationCandidate(metadata)) {
beanDef.setAttribute(CONFIGURATION_CLASS_ATTRIBUTE, CONFIGURATION_CLASS_LITE);
}
else {
return false;
}
// ...
}根據(jù)程序的判斷可知,如果一個類被@Configuration標(biāo)注且代理模式為true,那么這個類對應(yīng)的BeanDefinition將會被Spring添加一個FULL配置模式的屬性,有些同學(xué)可能對這個”屬性“不太理解,這里可以簡單說一下,其實(shí)這個”屬性“在Spring中有一個特定的接口就是AttributeAccessor,BeanDefinition就是繼承了這個接口,如何理解這個AttributeAccessor呢?其實(shí)也很簡單,想想看,BeanDefinition主要是做什么的?這個主要是用來描述Class對象的,例如這個Class是不是抽象的,作用域是什么,是不是懶加載等等信息,那如果一個Class對象有一個“屬性”是BeanDefinition描述不了的,那這個要如何處理呢?那這個接口AttributeAccessor又派上用場了,你可以向其中存放任何你定義的數(shù)據(jù),可以理解為一個map,現(xiàn)在了解BeanDefinition的屬性的含義了么?
在這里也能看到@Configuration(proxyBeanMethods = false)和@Component一樣效果,都是LITE模式
在這里第一步先判斷出這個類是FULL模式還是LITE模式,那么下一步就需要開始執(zhí)行對配置類的注解的解析了,在ConfigurationClassParser這個類有一個processConfigurationClass方法,里面有一個doProcessConfigurationClass方法,這里就是解析前文所列舉的@Component等等注解的過程,解析完成之后,在ConfigurationClassPostProcessor類的方法processConfigBeanDefinitions,有一個loadBeanDefinitions方法,這個方法就是將前文解析成功的注解數(shù)據(jù)全都注冊成BeanDefinition,這就是ConfigurationClassPostProcessor這個類的第一個方法所完成的任務(wù),另外這個方法在這里是非常簡單的描述了一下,實(shí)際上這個方法非常的復(fù)雜,需要慢慢的研究。
接下來再說ConfigurationClassPostProcessor類的enhanceConfigurationClasses方法,這個方法主要完成了對@Configuration注解標(biāo)注的類的增強(qiáng),進(jìn)行CGLIB代理,代碼如下:
public void enhanceConfigurationClasses(ConfigurableListableBeanFactory beanFactory) {
Map<String, AbstractBeanDefinition> configBeanDefs = new LinkedHashMap<String, AbstractBeanDefinition>();
for (String beanName : beanFactory.getBeanDefinitionNames()) {
BeanDefinition beanDef = beanFactory.getBeanDefinition(beanName);
if (ConfigurationClassUtils.isFullConfigurationClass(beanDef)) {//判斷是否被@Configuration標(biāo)注
if (!(beanDef instanceof AbstractBeanDefinition)) {
throw new BeanDefinitionStoreException("Cannot enhance @Configuration bean definition '" +
beanName + "' since it is not stored in an AbstractBeanDefinition subclass");
}
else if (logger.isWarnEnabled() && beanFactory.containsSingleton(beanName)) {
logger.warn("Cannot enhance @Configuration bean definition '" + beanName +
"' since its singleton instance has been created too early. The typical cause " +
"is a non-static @Bean method with a BeanDefinitionRegistryPostProcessor " +
"return type: Consider declaring such methods as 'static'.");
}
configBeanDefs.put(beanName, (AbstractBeanDefinition) beanDef);
}
}
if (configBeanDefs.isEmpty()) {
// nothing to enhance -> return immediately
return;
}
ConfigurationClassEnhancer enhancer = new ConfigurationClassEnhancer();
for (Map.Entry<String, AbstractBeanDefinition> entry : configBeanDefs.entrySet()) {
AbstractBeanDefinition beanDef = entry.getValue();
// If a @Configuration class gets proxied, always proxy the target class
beanDef.setAttribute(AutoProxyUtils.PRESERVE_TARGET_CLASS_ATTRIBUTE, Boolean.TRUE);
try {
// Set enhanced subclass of the user-specified bean class
Class<?> configClass = beanDef.resolveBeanClass(this.beanClassLoader);
Class<?> enhancedClass = enhancer.enhance(configClass, this.beanClassLoader);//生成代理的class
if (configClass != enhancedClass) {
if (logger.isDebugEnabled()) {
logger.debug(String.format("Replacing bean definition '%s' existing class '%s' with " +
"enhanced class '%s'", entry.getKey(), configClass.getName(), enhancedClass.getName()));
}
//替換class,將原來的替換為CGLIB代理的class
beanDef.setBeanClass(enhancedClass);
}
}
catch (Throwable ex) {
throw new IllegalStateException("Cannot load configuration class: " + beanDef.getBeanClassName(), ex);
}
}
}這里需要CGLIB的一些知識,我就簡單的在這里總結(jié)一下,這個方法從所有的BeanDefinition中找到屬性為FULL模式的BeanDefinition,然后對其進(jìn)行代理增強(qiáng),設(shè)置BeanDefinition的beanClass。然后在增強(qiáng)時有一些細(xì)節(jié)稍微需要明確一下,就是我們這個普通類中的方法,比如eoo(),foo()等方法,將會被MethodInterceptor所攔截,這個方法的調(diào)用將會被BeanMethodInterceptor所代理,到這里我們大家應(yīng)該稍微明確了ConfigurationClassPostProcessor是在什么時間被實(shí)例化,什么時間解析注解配置,什么時間進(jìn)行配置增強(qiáng)。如果看到這里不太明白,那歡迎與我來討論。
4.總結(jié)
@Component在Spring中是代表LITE模式的配置注解,這種模式下的注解不會被Spring所代理,就是一個標(biāo)準(zhǔn)類,如果在這個類中有@Bean標(biāo)注的方法,那么方法間的相互調(diào)用,其實(shí)就是普通Java類的方法的調(diào)用。
@Configuration在Spring中是代表FULL模式的配置注解,這種模式下的類會被Spring所代理,那么在這個類中的@Bean方法的相互調(diào)用,就相當(dāng)于調(diào)用了代理方法,那么在代理方法中會判斷,是否調(diào)用getBean方法還是invokeSuper方法,這里就是這兩個注解的最根本的區(qū)別。
一句話概括就是 @Configuration 中所有帶 @Bean 注解的方法都會被動態(tài)代理,因此調(diào)用該方法返回的都是同一個實(shí)例。
到此這篇關(guān)于Spring中@Configuration和@Component注解的區(qū)別及原理的文章就介紹到這了,更多相關(guān)@Configuration和@Component注解內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
- SpringBoot中@Configuration和@Bean和@Component相同點(diǎn)詳解
- Spring解讀@Component和@Configuration的區(qū)別以及源碼分析
- Spring中@Configuration注解和@Component注解的區(qū)別詳解
- 詳解Spring中@Component和@Configuration的區(qū)別
- Spring注解@Configuration和@Component區(qū)別詳解
- Spring注解中@Configuration和@Component到底有啥區(qū)別
- Spring @Configuration和@Component的區(qū)別
- 揭秘Spring核心注解@Configuration與@Component的本質(zhì)區(qū)別
相關(guān)文章
java使用FFmpeg提取音頻的實(shí)現(xiàn)示例
在Java開發(fā)中,我們經(jīng)常會遇到需要使用FFmpeg來處理音視頻文件的情況,本文主要介紹了java使用FFmpeg提取音頻的實(shí)現(xiàn)示例,具有一定的參考價值,感興趣的可以了解一下2024-01-01
利用java+mysql遞歸實(shí)現(xiàn)拼接樹形JSON列表的方法示例
這篇文章主要給大家介紹了關(guān)于利用java+mysql遞歸實(shí)現(xiàn)拼接樹形JSON列表的方法,文中通過示例代碼介紹的非常詳細(xì),對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值,需要的朋友們下面跟著小編來一起看看吧。2017-08-08
Java Dubbo協(xié)議下的服務(wù)端線程使用詳解
Dubbo是阿里開源項目,國內(nèi)很多互聯(lián)網(wǎng)公司都在用,已經(jīng)經(jīng)過很多線上考驗(yàn)。Dubbo內(nèi)部使用了Netty、Zookeeper,保證了高性能高可用性,使用Dubbo可以將核心業(yè)務(wù)抽取出來,作為獨(dú)立的服務(wù),逐漸形成穩(wěn)定的服務(wù)中心2023-03-03
基于Maven骨架創(chuàng)建JavaWeb項目過程解析
這篇文章主要介紹了基于Maven骨架創(chuàng)建JavaWeb項目過程解析,文中通過示例代碼介紹的非常詳細(xì),對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值,需要的朋友可以參考下2020-08-08

