20. Spring源码篇之@Lookup详解

简介

Lookup注解可能平时开发中大家接触的少，但是又确实挺有用的，比如我们一个单例Bean注入了一个原型Bean，原型Bean的效果其实是会失效的，因为单例Bean一开始就实例化好了，后面也不会再变化，但我们可能需要的就是原型Bean呀，那么怎么解决呢，如果注入的是一个动态的就好了，于是我们马上就会想到代理对象，spring中@Lookup就可以帮助我们实现该效果，原理就是生成了一个代理对象

Lookup还有一个功能就是可以放在抽象类上，如果一个类是一个抽象类，一般是不能生成Bean对象的，但是里面有方法加了@Lookup就可以

Lookup放在抽象类上

@Component("abstractLookup")
public abstract class AbstractLookup {
    // @Lookup
	public abstract void test();
}

public static void main(String[] args) {
    AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext();
    context.scan("com.shura.lookup");
    context.refresh();

    System.out.println(context.getBean("abstractLookup"));
}

启动报错

Exception in thread "main" org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 'abstractLookup' available

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

以上定义了一个抽象类，加了Component注解，通过扫描注册Bean，但是报错了，报错原因是spring并没有这么一个Bean

我们修改一下在test方法上面加上一个@Lookup注解

再次运行

输出
com.shura.lookup.AbstractLookup$$EnhancerBySpringCGLIB$$fb5a4910@25618e91
1
2

从输出的结果可以看出，其实也是一个CGLIB的代理对象

如何判断的？

在扫描出Bean生成BeanDefinition之前会做判断，代码如下 ClassPathScanningCandidateComponentProvider#isCandidateComponent

protected boolean isCandidateComponent(AnnotatedBeanDefinition beanDefinition) {
    AnnotationMetadata metadata = beanDefinition.getMetadata();
    /**
     * 是否是独立的类，普通的类，静态的匿名内部类是独立的类，匿名内部类不是独立的类
     * 接口或者抽象类不能作为Bean
     * 但是如果是抽象类却有Lookup注解也是是一个Bean
     */
    return (metadata.isIndependent() && (metadata.isConcrete() ||
            (metadata.isAbstract() && metadata.hasAnnotatedMethods(Lookup.class.getName()))));
}
1
2
3
4
5
6
7
8
9
10

注入原型Bean

上面讲到了，单例Bean注入原型Bean，是没有原型Bean的效果的，代码如下

@Component(ConfigurableBeanFactory.SCOPE_SINGLETON)
public class A {
	@Autowired
	private B b;

	public void test() {
		System.out.println(b);
	}
}

@Component
@Scope(ConfigurableBeanFactory.SCOPE_PROTOTYPE)
class B {

}


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

启动类

public static void main(String[] args) {
    AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext();
    context.scan("com.shura.lookup");
    context.refresh();

    A a = context.getBean(A.class);
    a.test();
    a.test();
}

执行
com.shura.lookup.B@2aafb23c
com.shura.lookup.B@2aafb23c
1
2
3
4
5
6
7
8
9
10
11
12
13

从上面结果看出确实没有原型的效果

修改为Lookup注解方式

@Component(ConfigurableBeanFactory.SCOPE_SINGLETON)
public class A {

	public void test() {
		System.out.println(b());
	}

	@Lookup
	public B b() {
		return null;
	}
}
1
2
3
4
5
6
7
8
9
10
11
12

再次执行启动类

com.shura.lookup.B@17d99928
com.shura.lookup.B@3834d63f
1
2

从结果来看大家也了解了其作用。

源码解析

效果有了，就来看下源码如何做到的，Lookup解析的源码在 AutowiredAnnotationBeanPostProcessor#determineCandidateConstructors
中，这个方法每个Bean实例化都会执行，这个类的详细介绍将在下一篇文章介绍，本文先介绍其中Lookup部分

if (!this.lookupMethodsChecked.contains(beanName)) {
    // 这步判断没什么用，忽略
    if (AnnotationUtils.isCandidateClass(beanClass, Lookup.class)) {
        try {
            Class<?> targetClass = beanClass; // beanClass传入进来的
            do {
                // 遍历targetClass中的method，查看是否写了@Lookup方法
                ReflectionUtils.doWithLocalMethods(targetClass, method -> {
                    Lookup lookup = method.getAnnotation(Lookup.class);
                    if (lookup != null) {
                        Assert.state(this.beanFactory != null, "No BeanFactory available");

                        // 将当前method封装成LookupOverride
                        // lookup.value()表示设置的beanName
                        LookupOverride override = new LookupOverride(method, lookup.value());
                        RootBeanDefinition mbd = (RootBeanDefinition) this.beanFactory.getMergedBeanDefinition(beanName);
                        // 设置到BeanDefinition的methodOverrides中
                        mbd.getMethodOverrides().addOverride(override);
                    }
                });
                
                // 父类有lookup也检查一下
                targetClass = targetClass.getSuperclass();
            }
            while (targetClass != null && targetClass != Object.class);

        }
        catch (IllegalStateException ex) {
            throw new BeanCreationException(beanName, "Lookup method resolution failed", ex);
        }
    }
    
    // 表示该类已经检查过了lookup下次就不用检查了
    this.lookupMethodsChecked.add(beanName);
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

lookup找出来之后，就看实例化是怎么处理的了

下面是实例化的源码逻辑 SimpleInstantiationStrategy#instantiate

public Object instantiate(RootBeanDefinition bd, @Nullable String beanName, BeanFactory owner) {
    // 判断BeanDefinition是否存在@Lookup的方法
    if (!bd.hasMethodOverrides()) {
        // 没有@Lookup
        Constructor<?> constructorToUse;
        synchronized (bd.constructorArgumentLock) {
            constructorToUse = (Constructor<?>) bd.resolvedConstructorOrFactoryMethod;
            if (constructorToUse == null) {
               final Class<?> clazz = bd.getBeanClass();
               constructorToUse = clazz.getDeclaredConstructor();
               // 保存
               bd.resolvedConstructorOrFactoryMethod = constructorToUse;
            }
        }
        // 通过 Constructor#newInstance构造出来
        return BeanUtils.instantiateClass(constructorToUse);
    }
    else {
        // 如果存在@Lookup，生成一个代理对象
        return instantiateWithMethodInjection(bd, beanName, owner);
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

上面看出如果是有@Lookup注解，生成的是一个代理对象，那么代理对象里面又是怎么处理的CglibSubclassingInstantiationStrategy.LookupOverrideMethodInterceptor#intercept

public Object intercept(Object obj, Method method, Object[] args, MethodProxy mp) throws Throwable {
    LookupOverride lo = (LookupOverride) getBeanDefinition().getMethodOverrides().getOverride(method);
    Object[] argsToUse = (args.length > 0 ? args : null);  // if no-arg, don't insist on args at all
    if (StringUtils.hasText(lo.getBeanName())) {
        // owner就是BeanFactory
        Object bean = (argsToUse != null ? this.owner.getBean(lo.getBeanName(), argsToUse) :
                this.owner.getBean(lo.getBeanName()));
        return (bean.equals(null) ? null : bean);
    }
    else {
        ResolvableType genericReturnType = ResolvableType.forMethodReturnType(method);
        return (argsToUse != null ? this.owner.getBeanProvider(genericReturnType).getObject(argsToUse) :
                this.owner.getBeanProvider(genericReturnType).getObject());
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

主要看关键逻辑是通过BeanFactory.getBean()获取的原型Bean，那么自然每次的Bean对象都是不一样的

总结

以上就是@Lookup注解的源码分析了，下一篇介绍推断构造方法扩展点

---

欢迎关注，学习不迷路！