揭秘@Configuration的秘密之BeanFactory后置處理器
前序文章 Spring如何掃描作業目錄下的Bean?|圖文并茂講解@Configuration的作業原理
文章目錄
- 揭秘@Configuration的秘密之BeanFactory后置處理器
- 基礎介紹
- 目的
- 流程圖
- 代碼分析
- (1) postProcessBeanFactory()
- (2)enhanceConfigurationClasses()
- (3)ConfigurationClassEnhancer.enhance()
- (4)ConfigurationClassEnhancer.newEnhancer()
- (5)ConfigurationClassEnhancer.createClass()
- 特別分析
- BeanMethodInterceptor.class
- Bean案例
- FactoryBean
- BeanFactoryAwareMethodInterceptor.class
- 謹防入坑
- FactoryBean注入進Spring后，其BeanName真的是&FactoryBean嗎？
- FactoryBean中getObject()物件什么時候注入進Spring中的？
- 如果@Configuration被換成了@Component，@Bean方法還會生成單例嗎？
基礎介紹
前面我們已經探究了@Configuration的原理 Spring如何掃描作業目錄下的Bean?|圖文并茂講解@Configuration的作業原理，實際上是ConfigurationClassPostProcessor.class在背后承擔了重量級的地位，該類繼承了BDR后置處理器，而且BDR后置處理器又繼承了BF后置處理器，本文將探究繼承了BF后置處理器，它實作了怎么樣的邏輯；
目的
@Configuration
public MyConfiguration {
@Bean
public MyBean createMyBean() {
return new MyBean();
}
@Bean
public MySubBean createSubBean() {
// 此時createMyBean()只會new一次
return new MySubBean(createMyBean());
}
}
在配置類中，有許多地方宣告了@Bean方法，Spring中的bean默認情況下都是單例的，那么如果又有方法呼叫了@Bean的方法，例如上面的代碼，createSubBean()方法中又呼叫了createMyBean()方法，如何保證bean只會被new一次呢？
Spring在處理@Configuration的配置類時，實際上是給他增加了一個CGLIB代理，放入SpringBean中的配置類實體實際上是一個被代理的物件，當第一次呼叫createMyBean()方法時，會執行new方法，創建出物件，那么再一次呼叫createMyBean()方法時，就會去bean工廠中的beanMap中去取，因此保證了單例模型；
流程圖
在invokeBeanFactoryPostProcessors()方法中，首先執行:
BeanDefinitionRegistryPostProcessor.postProcessBeanDefinitionRegistry(registry);
然后再執行:
BeanFactoryPostProcessor.postProcessBeanFactory(beanFactory);
前文中，首先執行的是掃描所有的bd，將專案中所有的類都掃描成bd放進beanFactory中；那么接下來就要將所有的bd取出，篩選出上面加了@Configuration的bd，將其通過cglib進行代理；
代碼分析
(1) postProcessBeanFactory()
該類就是bf后置處理器需要實作的方法，在該方法中，就是將配置類進行cglib代理(見方法2)，之后再放入一個Bean的后置處理器ImportAwareBeanPostProcessor.class;
// ConfigurationClassPostProcessor.class
@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);
}
// 將配置類進行cglib代理
enhanceConfigurationClasses(beanFactory);
beanFactory.addBeanPostProcessor(new ImportAwareBeanPostProcessor(beanFactory));
}
(2)enhanceConfigurationClasses()
該方法首先取出所有的bd，依次遍歷，篩選出加了@Configuration的bd；
創建ConfigurationClassEnhancer配置類代理增強器，后面就通過該增強器去給配置類設定代理；
回圈配置類bd，通過配置類代理增強器對bd進行代理enhancer.enhance()，見方法3；
配置類bd設定setBeanClass為代理類class，后續實體化bean的時候，就創建的代理類的物件；
// ConfigurationClassPostProcessor.class
public void enhanceConfigurationClasses(ConfigurableListableBeanFactory beanFactory) {
Map<String, AbstractBeanDefinition> configBeanDefs = new LinkedHashMap<>();
for (String beanName : beanFactory.getBeanDefinitionNames()) {
BeanDefinition beanDef = beanFactory.getBeanDefinition(beanName);
// 將加了@Configuration的配置類放入configBeanDefs
if (ConfigurationClassUtils.isFullConfigurationClass(beanDef)) {
if (!(beanDef instanceof AbstractBeanDefinition)) {
throw new BeanDefinitionStoreException("Cannot enhance @Configuration bean definition '" +
beanName + "' since it is not stored in an AbstractBeanDefinition subclass");
}
// 如果該bd被實體化了則需要將其中@Bean設定為靜態的
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，后面直接進行代理
Class<?> configClass = beanDef.resolveBeanClass(this.beanClassLoader);
if (configClass != null) {
Class<?> enhancedClass = enhancer.enhance(configClass, this.beanClassLoader);
if (configClass != enhancedClass) {
// bd設定最終實體化物件就是這個被代理類
beanDef.setBeanClass(enhancedClass);
}
}
}
catch (Throwable ex) {
throw new IllegalStateException("Cannot load configuration class: " + beanDef.getBeanClassName(), ex);
}
}
}
(3)ConfigurationClassEnhancer.enhance()
配置類增強器的enhance()方法,他判斷該class是否實作了EnhancedConfiguration.class介面，因為如果是被代理的，都會實作這個介面；如果已實作，則表示已經被代理過，直接回傳即可；
給class創建一個代理class見方法4，然后再回傳代理類class見方法5，最終將代理class回傳出去，讓外層方法設定進bd中；
// ConfigurationClassEnhancer.class
public Class<?> enhance(Class<?> configClass, @Nullable ClassLoader classLoader) {
// 如果class的父類是EnhancedConfiguration，則不需要進行代理
if (EnhancedConfiguration.class.isAssignableFrom(configClass)) {
return configClass;
}
// 設定被代理的類class
Class<?> enhancedClass = createClass(newEnhancer(configClass, classLoader));
return enhancedClass;
}
(4)ConfigurationClassEnhancer.newEnhancer()
這個方法就是創建一個cglib代理，我們可以看出，他是通過繼承的方式實作代理，然后需要實作EnhancedConfiguration.class介面去標識他已經被代理；
最關鍵的是他實作了兩個回呼介面BeanMethodInterceptor.class，BeanFactoryAwareMethodInterceptor.class，他們是用來處理@Bean回傳的物件以及factoryBean；
// ConfigurationClassEnhancer.class
private Enhancer newEnhancer(Class<?> configSuperClass, @Nullable ClassLoader classLoader) {
Enhancer enhancer = new Enhancer();
enhancer.setSuperclass(configSuperClass);
// cglib是通過是否實作EnhancedConfiguration介面判斷是否有被代理
enhancer.setInterfaces(new Class<?>[] {EnhancedConfiguration.class});
enhancer.setUseFactory(false);
enhancer.setNamingPolicy(SpringNamingPolicy.INSTANCE);
enhancer.setStrategy(new BeanFactoryAwareGeneratorStrategy(classLoader));
// 設定了兩個關鍵的回呼函式
enhancer.setCallbackFilter(CALLBACK_FILTER);
enhancer.setCallbackTypes(CALLBACK_FILTER.getCallbackTypes());
return enhancer;
}
// 關鍵方法 回呼介面
private static final ConditionalCallbackFilter CALLBACK_FILTER = new ConditionalCallbackFilter(CALLBACKS);
private static final Callback[] CALLBACKS = new Callback[] {
new BeanMethodInterceptor(),
new BeanFactoryAwareMethodInterceptor(),
NoOp.INSTANCE
};
(5)ConfigurationClassEnhancer.createClass()
就是給代理的class設定CALLBACKS；可以看看我代碼中的注釋，
這里附上了被代理類的代碼，需要保存被CGLIB類可以在java代碼中加入該代碼：
System.setProperty(DebuggingClassWriter.DEBUG_LOCATION_PROPERTY, "D:\\cglib");
private Class<?> createClass(Enhancer enhancer) {
// 獲取被代理的類class
Class<?> subclass = enhancer.createClass();
// Registering callbacks statically (as opposed to thread-local)
// is critical for usage in an OSGi environment (SPR-5932)...
// 代理類中包含一個靜態方法
// public static void CGLIB$SET_STATIC_CALLBACKS(Callback[] callback);
// 將CALLBACKS設定其中
Enhancer.registerStaticCallbacks(subclass, CALLBACKS);
return subclass;
}
// 被CGLIB代理后的配置類
public class SpringstudyApplication$$EnhancerBySpringCGLIB$$26a254aa extends SpringstudyApplication implements EnhancedConfiguration {
private boolean CGLIB$BOUND;
public static Object CGLIB$FACTORY_DATA;
private static final ThreadLocal CGLIB$THREAD_CALLBACKS;
private static final Callback[] CGLIB$STATIC_CALLBACKS;
private MethodInterceptor CGLIB$CALLBACK_0;
private MethodInterceptor CGLIB$CALLBACK_1;
private NoOp CGLIB$CALLBACK_2;
private static Object CGLIB$CALLBACK_FILTER;
private static final Method CGLIB$setBeanFactory$4$Method;
private static final MethodProxy CGLIB$setBeanFactory$4$Proxy;
private static final Object[] CGLIB$emptyArgs;
public BeanFactory $$beanFactory;
static void CGLIB$STATICHOOK1() {
CGLIB$THREAD_CALLBACKS = new ThreadLocal();
CGLIB$emptyArgs = new Object[0];
Class var0 = Class.forName("cn.ixp.springstudy.SpringstudyApplication$$EnhancerBySpringCGLIB$$26a254aa");
Class var1;
CGLIB$setBeanFactory$4$Method = ReflectUtils.findMethods(new String[]{"setBeanFactory", "(Lorg/springframework/beans/factory/BeanFactory;)V"}, (var1 = Class.forName("org.springframework.beans.factory.BeanFactoryAware")).getDeclaredMethods())[0];
CGLIB$setBeanFactory$4$Proxy = MethodProxy.create(var1, var0, "(Lorg/springframework/beans/factory/BeanFactory;)V", "setBeanFactory", "CGLIB$setBeanFactory$4");
}
final void CGLIB$setBeanFactory$4(BeanFactory var1) throws BeansException {
super.setBeanFactory(var1);
}
public final void setBeanFactory(BeanFactory var1) throws BeansException {
MethodInterceptor var10000 = this.CGLIB$CALLBACK_1;
if (var10000 == null) {
CGLIB$BIND_CALLBACKS(this);
var10000 = this.CGLIB$CALLBACK_1;
}
if (var10000 != null) {
var10000.intercept(this, CGLIB$setBeanFactory$4$Method, new Object[]{var1}, CGLIB$setBeanFactory$4$Proxy);
} else {
super.setBeanFactory(var1);
}
}
public static MethodProxy CGLIB$findMethodProxy(Signature var0) {
String var10000 = var0.toString();
switch(var10000.hashCode()) {
case 2095635076:
if (var10000.equals("setBeanFactory(Lorg/springframework/beans/factory/BeanFactory;)V")) {
return CGLIB$setBeanFactory$4$Proxy;
}
}
return null;
}
public SpringstudyApplication$$EnhancerBySpringCGLIB$$26a254aa() {
CGLIB$BIND_CALLBACKS(this);
}
public static void CGLIB$SET_THREAD_CALLBACKS(Callback[] var0) {
CGLIB$THREAD_CALLBACKS.set(var0);
}
// 這里設定靜態的callback集合
public static void CGLIB$SET_STATIC_CALLBACKS(Callback[] var0) {
CGLIB$STATIC_CALLBACKS = var0;
}
private static final void CGLIB$BIND_CALLBACKS(Object var0) {
SpringstudyApplication$$EnhancerBySpringCGLIB$$26a254aa var1 = (SpringstudyApplication$$EnhancerBySpringCGLIB$$26a254aa)var0;
if (!var1.CGLIB$BOUND) {
var1.CGLIB$BOUND = true;
Object var10000 = CGLIB$THREAD_CALLBACKS.get();
if (var10000 == null) {
var10000 = CGLIB$STATIC_CALLBACKS;
if (var10000 == null) {
return;
}
}
Callback[] var10001 = (Callback[])var10000;
var1.CGLIB$CALLBACK_2 = (NoOp)((Callback[])var10000)[2];
var1.CGLIB$CALLBACK_1 = (MethodInterceptor)var10001[1];
var1.CGLIB$CALLBACK_0 = (MethodInterceptor)var10001[0];
}
}
static {
CGLIB$STATICHOOK2();
CGLIB$STATICHOOK1();
}
static void CGLIB$STATICHOOK2() {
}
}
特別分析
上面我們分析了postProcessBeanFactory()方法的執行流程，那么在程序中，有兩個特殊的Callbacks需要我們關注，那么我們來分析一下這兩個特別的callbacks；
private static final Callback[] CALLBACKS = new Callback[] {
new BeanMethodInterceptor(),
new BeanFactoryAwareMethodInterceptor(),
NoOp.INSTANCE
};
BeanMethodInterceptor.class
當代理類物件呼叫方法的時候，就會進入intercept()方法，做方法攔截，代碼的具體流程可以看我加的注釋，這個方法的具體流程見后續分析；
@Override
@Nullable
public Object intercept(Object enhancedConfigInstance, Method beanMethod, Object[] beanMethodArgs, MethodProxy cglibMethodProxy) throws Throwable {
// 獲取bean工廠
ConfigurableBeanFactory beanFactory = getBeanFactory(enhancedConfigInstance);
// 如果有獲取@Bean，就獲取bean的名稱——回傳的要不是bean名稱，要么就是方法名
String beanName = BeanAnnotationHelper.determineBeanNameFor(beanMethod);
// Determine whether this bean is a scoped-proxy
// 作用域
Scope scope = AnnotatedElementUtils.findMergedAnnotation(beanMethod, Scope.class);
if (scope != null && scope.proxyMode() != ScopedProxyMode.NO) {
String scopedBeanName = ScopedProxyCreator.getTargetBeanName(beanName);
if (beanFactory.isCurrentlyInCreation(scopedBeanName)) {
beanName = scopedBeanName;
}
}
// To handle the case of an inter-bean method reference, we must explicitly check the
// container for already cached instances.
// First, check to see if the requested bean is a FactoryBean. If so, create a subclass
// proxy that intercepts calls to getObject() and returns any cached bean instance.
// This ensures that the semantics of calling a FactoryBean from within @Bean methods
// is the same as that of referring to a FactoryBean within XML. See SPR-6602.
// 判斷有沒有回圈呼叫回傳factoryBean的方法,如果有的話則對該factoryBean方法創建代理
if (factoryContainsBean(beanFactory, BeanFactory.FACTORY_BEAN_PREFIX + beanName) &&
factoryContainsBean(beanFactory, beanName)) {
Object factoryBean = beanFactory.getBean(BeanFactory.FACTORY_BEAN_PREFIX + beanName);
if (factoryBean instanceof ScopedProxyFactoryBean) {
// Scoped proxy factory beans are a special case and should not be further proxied
}
else {
// It is a candidate FactoryBean - go ahead with enhancement
// 給getObject()方法增加代理
return enhanceFactoryBean(factoryBean, beanMethod.getReturnType(), beanFactory, beanName);
}
}
// 比如代碼 a(){ return new a();} b(){ return a()}
// (1)首先a訪問到這isCurrentlyInvokedFactoryMethod()回傳true，然后就直接執行new a()
// (2)然后b訪問到這isCurrentlyInvokedFactoryMethod()回傳true，然后直接執行a()方法
// (3)這次再呼叫a()方法時，isCurrentlyInvokedFactoryMethod()回傳false，就不執行new a()了
// isCurrentlyInvokedFactoryMethod決議：
// 他會獲取當前呼叫的方法currentlyInvokedMethod 和將要執行的方法 method
// 當currentlyInvokedMethod==method時回傳true
// 因此(3)這塊，currentlyInvokedMethod是b()，而執行的method是a()，因此回傳false
if (isCurrentlyInvokedFactoryMethod(beanMethod)) {
// The factory is calling the bean method in order to instantiate and register the bean
// (i.e. via a getBean() call) -> invoke the super implementation of the method to actually
// create the bean instance.
if (logger.isWarnEnabled() &&
BeanFactoryPostProcessor.class.isAssignableFrom(beanMethod.getReturnType())) {
logger.warn(String.format("@Bean method %s.%s is non-static and returns an object " +"assignable to Spring's BeanFactoryPostProcessor interface. This will " +"result in a failure to process annotations such as @Autowired, " +"@Resource and @PostConstruct within the method's declaring " + "@Configuration class. Add the 'static' modifier to this method to avoid " +"these container lifecycle issues; see @Bean javadoc for complete details.", beanMethod.getDeclaringClass().getSimpleName(), beanMethod.getName()));
}
return cglibMethodProxy.invokeSuper(enhancedConfigInstance, beanMethodArgs);
}
// 直接從bean工廠里取，不再重新new
return resolveBeanReference(beanMethod, beanMethodArgs, beanFactory, beanName);
}
Bean案例
拿文章開頭的demo來分析，
@Configuration
public MyConfiguration {
@Bean
public MyBean createMyBean() {
return new MyBean();
}
@Bean
public MySubBean createSubBean() {
// 此時createMyBean()只會new一次
return new MySubBean(createMyBean());
}
}
當實體化MyBean的bd的時候，我們呼叫的就是MyConfiguration.createMyBean()方法，這時就會被方法攔截，通過isCurrentlyInvokedFactoryMethod()方法來判斷是否是第一次創建MyBean物件，
private boolean isCurrentlyInvokedFactoryMethod(Method method) {
Method currentlyInvoked = SimpleInstantiationStrategy.getCurrentlyInvokedFactoryMethod();
return (currentlyInvoked != null && method.getName().equals(currentlyInvoked.getName()) &&
Arrays.equals(method.getParameterTypes(), currentlyInvoked.getParameterTypes()));
}
這個方法有一個Method是currentlyInvoked，他表示當前呼叫該方法的方法，例如當前是createMyBean();
入口引數Method是method，他表示當前需要執行的方法；執行的是createMyBean();
當呼叫方法=執行方法，回傳true，則可表示當前是第一次執行new物件，否則就不是第一次執行new物件；
因此MyBean的bd實體化走的是new MyBean()創建物件；
而實體化MySubBean的bd時，里面呼叫了createMyBean()，這時進入isCurrentlyInvokedFactoryMethod方法回傳的是false,因為呼叫方法是createSubBean(),執行方法createMyBean(),因此這里是去beanFactory取MyBean的實體化物件;
總結:配置類中的@Bean(單例下)方法,多次呼叫只會實體化一次,后面都會從bean工廠中取已實體化的物件，
FactoryBean
先上demo
@Configuration
public class MyBeanConfig {
// 放入Bean容器中
@Bean
public MyFactoryBean getMyFactoryBean() {
return new MyFactoryBean();
}
@Bean
public MyFactoryBean getMySameFactoryBean() {
return getMyFactoryBean();
}
}
// 定義的FactoryBean
public class MyFactoryBean implements FactoryBean<MyBean> {
@Override
public MyBean getObject() throws Exception {
return new MyBean();
}
@Override
public Class<?> getObjectType() {
return MyBean.class;
}
}
// 定義的Bean
public class MyBean {
public MyBean() {
System.out.println("創建了 MyBean");
}
}
這里的流程是這樣的：
-
執行getMyFactoryBean()方法時，第一次進入時不會走下面的代碼,而是和@Bean的流程一樣，判斷當前呼叫方法和執行方法是否一樣，這里為true，執行new MyFactoryBean();
// 判斷有沒有回圈呼叫回傳factoryBean的方法,如果有的話則對該factoryBean方法創建代理 if (factoryContainsBean(beanFactory, BeanFactory.FACTORY_BEAN_PREFIX + beanName) && factoryContainsBean(beanFactory, beanName)) { Object factoryBean = beanFactory.getBean(BeanFactory.FACTORY_BEAN_PREFIX + beanName); if (factoryBean instanceof ScopedProxyFactoryBean) { // Scoped proxy factory beans are a special case and should not be further proxied } else { // It is a candidate FactoryBean - go ahead with enhancement // 給getObject()方法增加代理 return enhanceFactoryBean(factoryBean, beanMethod.getReturnType(), beanFactory, beanName); } } -
接下來執行getMySameFactoryBean()，這里也是執行到判斷當前呼叫方法和執行方法是否一樣，這里為true，執行getMyFactoryBean();
return cglibMethodProxy.invokeSuper(enhancedConfigInstance, beanMethodArgs); -
由于又去執行getMyFactoryBean();這時再一次進入方法攔截器中，這次會走這塊的代碼了，
factoryContainsBean()判斷的是beanName=getMyFactoryBean是不是FactoryBean，其原理是getMyFactoryBean是不是已經在beanFactory中了，且是FactoryBean；
我們都知道，factoryBean在bean容器中都是以&為前綴的，【但并不是其beanName加了&】，后面會去解釋；
這里第一次判斷factoryContainsBean(beanFactory,“&” + beanName)我還不太明白，因為factoryContainsBean()對于beanName是取了去除&的，然后對于單例已創建的Bean是判斷是否實作了FactoryBean.class介面，這里需要再探究!!!
// 判斷有沒有回圈呼叫回傳factoryBean的方法,如果有的話則對該factoryBean方法創建代理 if (factoryContainsBean(beanFactory, BeanFactory.FACTORY_BEAN_PREFIX + beanName) && factoryContainsBean(beanFactory, beanName)) { Object factoryBean = beanFactory.getBean(BeanFactory.FACTORY_BEAN_PREFIX + beanName); if (factoryBean instanceof ScopedProxyFactoryBean) { // Scoped proxy factory beans are a special case and should not be further proxied } else { // It is a candidate FactoryBean - go ahead with enhancement // 給getObject()方法增加代理 return enhanceFactoryBean(factoryBean, beanMethod.getReturnType(), beanFactory, beanName); } }然后創建了CGLIB代理MyFactoryBean.class并回傳；我們可以看到，代理的方法攔截主要是如果呼叫getObject()方法從工廠里取，其余方法都是反射原代理物件的方法；
((Factory) fbProxy).setCallback(0, (MethodInterceptor) (obj, method, args, proxy) -> { if (method.getName().equals("getObject") && args.length == 0) { return beanFactory.getBean(beanName); } return proxy.invoke(factoryBean, args); });因此，我們從實驗結果上可以看出，
&getMyFactoryBean回傳的物件是MyFactoryBean，而&getMySameFactoryBean回傳的是MyFactoryBean代理物件，且被代理的物件就是MyFactoryBean；
BeanFactoryAwareMethodInterceptor.class
這個方法攔截器只攔截setBeanFactory()方法，它主要是設定了$$beanFactory為args[0]，另外如果該代理類實作了BeanFactoryAware.class則呼叫setBeanFactory(args)方法；
private static class BeanFactoryAwareMethodInterceptor implements MethodInterceptor, ConditionalCallback {
@Override
@Nullable
public Object intercept(Object obj, Method method, Object[] args, MethodProxy proxy) throws Throwable {
// 取出代理類中的$$beanFactory
Field field = ReflectionUtils.findField(obj.getClass(), BEAN_FACTORY_FIELD);
Assert.state(field != null, "Unable to find generated BeanFactory field");
// 設定$$beanFactory
field.set(obj, args[0]);
// Does the actual (non-CGLIB) superclass implement BeanFactoryAware?
// If so, call its setBeanFactory() method. If not, just exit.
// 如果實作了BeanFactoryAware，則呼叫setBeanFactory()方法
if (BeanFactoryAware.class.isAssignableFrom(ClassUtils.getUserClass(obj.getClass().getSuperclass()))) {
return proxy.invokeSuper(obj, args);
}
return null;
}
// 匹配的是setBeanFactory方法
@Override
public boolean isMatch(Method candidateMethod) {
return isSetBeanFactory(candidateMethod);
}
public static boolean isSetBeanFactory(Method candidateMethod) {
return (candidateMethod.getName().equals("setBeanFactory") &&
candidateMethod.getParameterCount() == 1 &&
BeanFactory.class == candidateMethod.getParameterTypes()[0] &&
BeanFactoryAware.class.isAssignableFrom(candidateMethod.getDeclaringClass()));
}
}
謹防入坑
FactoryBean注入進Spring后，其BeanName真的是&FactoryBean嗎？
首先宣告：不是；他只是Spring在代碼中判斷Bean是否為FactoryBean的一個標記，并不是注入進Spring后其BeanName加了&；
上實驗截圖：
我們發現，在beanDefinition中查詢getMyFactoryBean,發現其指向的仍然是MyBeanConfig.class#getMyFactoryBean();
那么我們看下單例池中的資料：
可以發現，其實在單例池中BeanName=getMyFactoryBean，其Value=MyFactoryBean物件，而不是MyBean物件；那MyBean物件是在哪里存盤的呢？請看下一個問題，
因此，我們發現Spring的bd集合和單例池中，不存在FactoryBean注入進去后其BeanName加了"&"號，
FactoryBean中getObject()物件什么時候注入進Spring中的？
從前面的分析看出來，程式已經執行完了，但bd和單例池中都沒有MyBean物件，那么FactoryBean的getObject()物件什么時候被呼叫的呢？
其實，當我們呼叫完applicationContext.refresh();后，我們會把掃描的，手動注冊的bd去實體化對應的Bean放入單例池中，而我們并沒有特殊處理FactoryBean.getObject()方法，所以我們的bd中是沒有FactoryBean.getObject()對應的bd的，因此單例池中也不會有相應的實體化物件；
那當我們呼叫getBean的時候為什么會拿出MyBean物件呢？
Object getMyFactoryBean = applicationContext.getBean("getMyFactoryBean");
這時，doGetBean()會將其MyFactoryBean的實體化物件取出來，如果MyFactoryBean不是FactoryBean就將其回傳，若是FactoryBean，就會呼叫其getObject()方法將MyBean物件創建出來，然后回傳，因此getMyFactoryBean回傳的是MyBean物件；
那么如果我們呼叫兩次getBean呢？
Object getMyFactoryBean = applicationContext.getBean("getMyFactoryBean");
Object getMyFactoryBean1 = applicationContext.getBean("getMyFactoryBean");
這時回傳的getMyFactoryBean和getMyFactoryBean1是同一個MyBean物件，我們會疑問，MyBean物件并沒有放入beanFactory的單例池中，那么第二次呼叫getBean()回傳的物件是存盤在哪里的呢？
原來，我們的beanFactory繼承了FactoryBeanRegistrySupport.class類，它其中有個factoryBeanObjectCache專門存盤factoryBean創建的物件，因此，第二次呼叫不會再次呼叫getObject()方法，而是從快取中直接取，
private final Map<String, Object> factoryBeanObjectCache = new ConcurrentHashMap(16);
總結：factoryBean.getObject()方法最終呼叫是在getBean()的時候，并且有個factoryBeanObjectCacheMap去保存物件，不存放在單例池中；
如果@Configuration被換成了@Component，@Bean方法還會生成單例嗎？
答案：不會！
都沒有CGLIB代理了，肯定不會是單例，每次呼叫都會生成新的物件，
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/349591.html
標籤：java
上一篇：cgb2109-day06