https://www.cnblogs.com/daihang2366/p/15125874.html
1、现象
众所周知,Spring中配置类是用来代替配置文件的,在老一些的日子里面我们使用XML配置,而如今大多使用JavaBean的方式配置。
一个简单的配置类如下:
@Configuration | |
@ComponentScan("com.dh") | |
public class AppConfig { | |
@Bean | |
public Entity1 entity1(){ | |
return new Entity1(); | |
} | |
@Bean | |
public Entity2 entity2(){ | |
return new Entity2(); | |
} | |
} |
这是一个简单的配置类,没啥特殊的.
那么现在开始我们的示例代码:
Entity1.java:
public class Entity1 { | |
public Entity1() { | |
System.out.println("Entity1 is initing...."); | |
} | |
} |
Entity2.java:
public class Entity2 { | |
public Entity2() { | |
System.out.println("Entity2 is initing...."); | |
} | |
} |
AppConfig.java:
@Configuration | |
@ComponentScan("com.dh") | |
public class AppConfig { | |
@Bean | |
public Entity1 entity1(){ | |
return new Entity1(); | |
} | |
@Bean | |
public Entity2 entity2(){ | |
entity1(); | |
return new Entity2(); | |
} | |
} |
这个时候运行项目后打印结果为:
Entity1 is initing.... | |
Entity2 is initing.... |
当我把AppConfig.java中@Configuration注解删除掉,那么打印结果为下:
Entity1 is initing.... | |
Entity1 is initing.... | |
Entity2 is initing.... |
你可能会想,我们没删除Configuration注解的时候为什么"Entity1 is initing...."不是打印两次而只打印一次,为什么去掉Configuration注解后就恢复了我们认知当中的情况?
这个就是设置到Spring中配置类的full和lite,进而涉及到Spring中使用的Cglib代理.
2、解析
这里直接对其原因进行解析,下面会进行源码解析.
首先在我们Spring当中配置类有两种类型:
* 1、full(带有@Configuration注解的,全配置类) | |
* 2、lite(不带有@Configuration注解,但带有其他配置注解,例如Import、ComponentScan,部分配置类) |
如果配置类是lite的,那么Spring则不会去代理其配置类,只会单纯的实现这些配置类该有的功能.
如果配置类是full的,那么则会代理配置类,在配置类中调用其方法去获取Bean的时候,首先去BeanFactory中getBean(返回值类型.class),如果容器中存在则不会去实际调用真实的方法,直接就return了
代理配置类的伪代码:
// Cglib学过的都知道这个 | |
Enhancer enhancer = new Enhancer(); | |
/* 代理类继承于被代理类(也就是我们的配置类) */ | |
enhancer.setSuperclass(需要被代理的配置类.class); | |
enhancer.setNamingPolicy(SpringNamingPolicy.INSTANCE); | |
/* 方法拦截,在执行方法前会回调其这里给的方法 */ | |
enhancer.setCallback(new MethodInterceptor() { | |
@Override | |
public Object intercept(Object o, Method method, Object[] objects, MethodProxy methodProxy) throws Throwable { | |
// method.getReturnType():获取配置类当前调用的方法的配置返回值类型Class,这里如果容器中存在,则直接不需要调用配置类的实际方法了,直接return | |
if(Objects.nonNull(工厂对象.getBean(method.getReturnType()))){ | |
return 工厂对象.getBean(method.getReturnType()); | |
} | |
// 容器中不存在的时候才会去调用配置类的方法 | |
return methodProxy.invokeSuper(o,objects) | |
} | |
}); | |
代理类对象 对象 = enhancer.create(); |
3、源码
这里我们关心几点:
1、配置类是在哪里解析的? | |
2、配置类在哪里判断其是否为全配置类的?full/lite | |
3、在哪里对配置类进行代理的 |
启动类:
public static void main(String[]args){ | |
AnnotationConfigApplicationContext applicationContext = new AnnotationConfigApplicationContext(); | |
applicationContext.register(AppConfig.class); | |
applicationContext.refresh(); | |
} |
首先我们要知道Spring容器做实际功能的代码是在refresh中的,而本次聊的这个在refresh代码中的"invokeBeanFactoryPostProcessors(beanFactory);"这一行代码中.
protected void invokeBeanFactoryPostProcessors(ConfigurableListableBeanFactory beanFactory) { | |
// 进入这行代码中 | |
PostProcessorRegistrationDelegate.invokeBeanFactoryPostProcessors(beanFactory, getBeanFactoryPostProcessors()); | |
...... | |
} |
注意在这里面涉及到Spring的BeanFactoryPostProcessor,BeanFactoryPostProcessor是Spring在还未初始化Bean的时候给我们提供的回调,当然Spring自己也写了BeanFactoryPostProcessor回调来实现配置类解析,这个类叫做ConfigurationClassPostProcessor,但是我们看了这个类以后发现,ConfigurationClassPostProcessor这个类直接实现接口为:
BeanDefinitionRegistryPostProcessor,这个BeanDefinitionRegistryPostProcessor继承于BeanFactoryPostProcessor,那么就说明我们的ConfigurationClassPostProcessor
同时做了两个接口的接口实现,在其实现接口中postProcessBeanDefinitionRegistry用来做配置类功能解析,例如扫描包,引入类、配置等,postProcessBeanFactory用来做代理.
那么我们回到上面的代码流程中,进入其invokeBeanFactoryPostProcessors方法.
找到其第一个invokeBeanDefinitionRegistryPostProcessors(currentRegistryProcessors, registry);代码,这里是进行配置类配置解析的.进入这行代码
private static void invokeBeanDefinitionRegistryPostProcessors(Collection<? extends BeanDefinitionRegistryPostProcessor> postProcessors, BeanDefinitionRegistry registry) { | |
for (BeanDefinitionRegistryPostProcessor postProcessor : postProcessors) { | |
postProcessor.postProcessBeanDefinitionRegistry(registry); | |
} | |
} |
此时postProcessors只有一条数据[ConfigurationClassPostProcessor],进入ConfigurationClassPostProcessor的postProcessBeanDefinitionRegistry方法.
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); | |
} |
进入其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)) { | |
.....很多代码 | |
} | |
// 判断是不是配置类 | |
else if (ConfigurationClassUtils.checkConfigurationClassCandidate(beanDef, this.metadataReaderFactory)) { // line1 | |
configCandidates.add(new BeanDefinitionHolder(beanDef, beanName)); | |
} | |
} | |
.......很多代码 | |
} |
注意这里Spring将容器中所有的BeanDefinition的名称拿出来,然后遍历,这里注意能拿到出我们的AppConfig,因为我们前面register进去了,然后第一个if就是判断是否已经解析过了,如果是则不操作,否则
就判断当前的这个类是否为配置类,那么我们进入ConfigurationClassUtils.checkConfigurationClassCandidate里面去:
public static boolean checkConfigurationClassCandidate(BeanDefinition beanDef, MetadataReaderFactory metadataReaderFactory) { | |
String className = beanDef.getBeanClassName(); | |
if (className == null || beanDef.getFactoryMethodName() != null) { | |
return false; | |
} | |
AnnotationMetadata metadata;/* 此处需要拿到该BeanDefinition的metadata信息,但由于注解BeanDefinition、XML的BeanDefinition获取metadata的方式不一样,所以需要分别判断其类型后再获取*/ | |
if (beanDef instanceof AnnotatedBeanDefinition && | |
className.equals(((AnnotatedBeanDefinition) beanDef).getMetadata().getClassName())) { | |
// Can reuse the pre-parsed metadata from the given BeanDefinition... | |
metadata = ((AnnotatedBeanDefinition) beanDef).getMetadata(); | |
} | |
else if (beanDef instanceof AbstractBeanDefinition && ((AbstractBeanDefinition) beanDef).hasBeanClass()) { | |
// Check already loaded Class if present... | |
// since we possibly can't even load the class file for this Class. | |
Class<?> beanClass = ((AbstractBeanDefinition) beanDef).getBeanClass(); | |
metadata = new StandardAnnotationMetadata(beanClass, true); | |
} | |
else { | |
try { | |
MetadataReader metadataReader = metadataReaderFactory.getMetadataReader(className); | |
metadata = metadataReader.getAnnotationMetadata(); | |
} | |
catch (IOException ex) { | |
if (logger.isDebugEnabled()) { | |
logger.debug("Could not find class file for introspecting configuration annotations: " + className, ex); | |
} | |
return false; | |
} | |
} | |
if (isFullConfigurationCandidate(metadata)) { | |
beanDef.setAttribute(CONFIGURATION_CLASS_ATTRIBUTE, CONFIGURATION_CLASS_FULL);/*设置标志位*/ | |
} | |
else if (isLiteConfigurationCandidate(metadata)) { | |
beanDef.setAttribute(CONFIGURATION_CLASS_ATTRIBUTE, CONFIGURATION_CLASS_LITE);/*设置标志位*/ | |
} | |
else { | |
return false; | |
} | |
return true; | |
} |
这个方法来总结一下:
- metadata是当前类的元信息,包括注解等
- 根据这个当前BeanDefinition不同的类型,使用不同的方法去获取其元信息metadata
- 在if (isFullConfigurationCandidate(metadata))这行代码中会去判断当前元信息中是否包含@Configuration注解,如果有则认为其是一个完全的配置类,则设置标注位值为full
- 在else if中判断是否为接口,如果为接口,则返回false,那么整个代码就return false了,如果元信息中包含以下注解:Component、ComponentScan、Import、ImportResource、方法中包含@Bean,那么则认为其是一个配置类,但不完全是,return一个true,设置标志位为lite
我们来验证看看,进入isFullConfigurationCandidate方法:
public static boolean isFullConfigurationCandidate(AnnotationMetadata metadata) { | |
return metadata.isAnnotated(Configuration.class.getName()); | |
} |
这就不过多解释了,我们再来看isLiteConfigurationCandidate:
public static boolean isLiteConfigurationCandidate(AnnotationMetadata metadata) { | |
// Do not consider an interface or an annotation... | |
if (metadata.isInterface()) { | |
return false; | |
} | |
// Any of the typical annotations found? | |
for (String indicator : candidateIndicators) { | |
if (metadata.isAnnotated(indicator)) { | |
return true; | |
} | |
} | |
// Finally, let's look for @Bean methods... | |
try { | |
return metadata.hasAnnotatedMethods(Bean.class.getName()); | |
} | |
catch (Throwable ex) { | |
if (logger.isDebugEnabled()) { | |
logger.debug("Failed to introspect @Bean methods on class [" + metadata.getClassName() + "]: " + ex); | |
} | |
return false; | |
} | |
} |
重要的是for遍历判断的地方,candidateIndicators是一个集合,里面有四个元素,就是上面我们说的,然后在try中判断类中的方法里面是否包含@Bean,如果包含了也认为是一个配置类, 只是不完全是哈.
至此,我们解释了第1和第2点.
下面我们来看在哪里做的代理:
我们回到invokeBeanFactoryPostProcessors方法去,在我们前面说的Spring是去处理BeanDefinitionRegistryPostProcessor回调,我们翻到这个invokeBeanFactoryPostProcessors方法的最底下去
我们进入到这个方法里面去:
private static void invokeBeanFactoryPostProcessors( | |
Collection<? extends BeanFactoryPostProcessor> postProcessors, ConfigurableListableBeanFactory beanFactory) { | |
for (BeanFactoryPostProcessor postProcessor : postProcessors) { | |
postProcessor.postProcessBeanFactory(beanFactory); | |
} | |
} |
注意这里的回调的方法和我们上面的回调是不一样的,虽然是同样的类,但是实现了两个接口,我们这里进入ConfigurationClassPostProcessor中postProcessBeanFactory方法.
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)); | |
} |
进入其enhanceConfigurationClasses方法.
public void enhanceConfigurationClasses(ConfigurableListableBeanFactory beanFactory) { | |
Map<String, AbstractBeanDefinition> configBeanDefs = new LinkedHashMap<>(); | |
for (String beanName : beanFactory.getBeanDefinitionNames()) { | |
BeanDefinition beanDef = beanFactory.getBeanDefinition(beanName); | |
if (ConfigurationClassUtils.isFullConfigurationClass(beanDef)) { // 代码行1---->line1 | |
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); | |
if (configClass != null) { | |
Class<?> enhancedClass = enhancer.enhance(configClass, this.beanClassLoader); // 代码行2---->line2 | |
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())); | |
} | |
beanDef.setBeanClass(enhancedClass); | |
} | |
} | |
} | |
catch (Throwable ex) { | |
throw new IllegalStateException("Cannot load configuration class: " + beanDef.getBeanClassName(), ex); | |
} | |
} | |
} |
注意看我们的代码行1---->line1:
这个代码里面做了这件事情
public static boolean isFullConfigurationClass(BeanDefinition beanDef) { | |
return CONFIGURATION_CLASS_FULL.equals(beanDef.getAttribute(CONFIGURATION_CLASS_ATTRIBUTE)); | |
} | |
// CONFIGURATION_CLASS_FULL的值=full |
判断其是否为full的,如果是full的那么则会存储到configBeanDefs这个map集合中.
然后在代码行2----->line2:Class<?> enhancedClass = enhancer.enhance(configClass, this.beanClassLoader);这串代码就是获取当前类(配置类)的代理类,我们进入enhancer.enhance方法中
public Class<?> enhance(Class<?> configClass, @Nullable ClassLoader classLoader) { | |
if (EnhancedConfiguration.class.isAssignableFrom(configClass)) { | |
if (logger.isDebugEnabled()) { | |
logger.debug(String.format("Ignoring request to enhance %s as it has " + | |
"already been enhanced. This usually indicates that more than one " + | |
"ConfigurationClassPostProcessor has been registered (e.g. via " + | |
"<context:annotation-config>). This is harmless, but you may " + | |
"want check your configuration and remove one CCPP if possible", | |
configClass.getName())); | |
} | |
return configClass; | |
} | |
Class<?> enhancedClass = createClass(newEnhancer(configClass, classLoader)); // line1 | |
if (logger.isDebugEnabled()) { | |
logger.debug(String.format("Successfully enhanced %s; enhanced class name is: %s", | |
configClass.getName(), enhancedClass.getName())); | |
} | |
return enhancedClass; | |
} |
再进入这里的line1处的newEnhancer方法中,点进去:
private Enhancer newEnhancer(Class<?> configSuperClass, @Nullable ClassLoader classLoader) { | |
Enhancer enhancer = new Enhancer(); | |
/* Cglib代理中,代理类继承于被代理类 */ | |
enhancer.setSuperclass(configSuperClass); // line1 | |
/* 设置接口,注意此接口中可以回调拿到BeanFactory */ | |
enhancer.setInterfaces(new Class<?>[] {EnhancedConfiguration.class}); // line2 | |
enhancer.setUseFactory(false); | |
enhancer.setNamingPolicy(SpringNamingPolicy.INSTANCE); // line3 | |
enhancer.setStrategy(new BeanFactoryAwareGeneratorStrategy(classLoader)); // line4 | |
enhancer.setCallbackFilter(CALLBACK_FILTER); // line5 | |
enhancer.setCallbackTypes(CALLBACK_FILTER.getCallbackTypes()); // 拦截器类型 | |
return enhancer; | |
} |
line1处设置目标类为代理类,因为cglib是基于继承的.
line2处时设置一些实现接口,注意我们想一下我们在解析的地方已经说了调用方法之前getBean判断是否工厂中存在,那么肯定就需要有工厂,
此时我们需要先知道在Spring当中有各种XXXXAware接口回调,Spring会回调各种对象过来,例如当我们实现了BeanFactoryAware的时候,
那么就会回调setBeanFactory方法传递给BeanFactory工厂,然后我我们看看EnhancedConfiguration这个接口,其继承了BeanFactoryAware:
public interface EnhancedConfiguration extends BeanFactoryAware { | |
} |
那么就说明我们的代理类可以拿到Bean工厂,那么这就说明我们前面解析的从工厂中getBean后判断是否存在这个是成立的.
line3处设置Bean名字生成策略
line4设置字节码生成器,这里Spring使用的是BeanFactoryAwareGeneratorStrategy,其继承与DefaultGeneratorStrategy类,我们看其BeanFactoryAwareGeneratorStrategy的transform方法
protected ClassGenerator transform(ClassGenerator cg) throws Exception { | |
ClassEmitterTransformer transformer = new ClassEmitterTransformer() { | |
@Override | |
public void end_class() { | |
declare_field(Constants.ACC_PUBLIC, BEAN_FACTORY_FIELD, Type.getType(BeanFactory.class), null); | |
super.end_class(); | |
} | |
}; | |
return new TransformingClassGenerator(cg, transformer); | |
} |
注意看其end_class方法,其设置了一个字段,名称为$$beanFactory,类型为BeanFactory,这个字段用来存储BeanFactory.
line5设置拦截器类型.
至此,我们解释了其第3点:在哪里对配置类进行代理的
此解析只做导读,切勿当作唯一依据