Lookup注解可能平时开发中大家接触的少,但是又确实挺有用的,比如我们一个单例Bean注入了一个原型Bean,原型Bean的效果其实是会失效的,因为单例Bean一开始就实例化好了,后面也不会再变化,但我们可能需要的就是原型Bean呀,那么怎么解决呢,如果注入的是一个动态的就好了,于是我们马上就会想到代理对象,spring中@Lookup就可以帮助我们实现该效果,原理就是生成了一个代理对象
Lookup还有一个功能就是可以放在抽象类上,如果一个类是一个抽象类,一般是不能生成Bean对象的,但是里面有方法加了@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
以上定义了一个抽象类,加了Component注解,通过扫描注册Bean,但是报错了,报错原因是spring并没有这么一个Bean
我们修改一下在test方法上面加上一个@Lookup注解
再次运行
输出
com.shura.lookup.AbstractLookup$$EnhancerBySpringCGLIB$$fb5a4910@25618e91
从输出的结果可以看出,其实也是一个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()))));
}
上面讲到了,单例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 {
}
启动类
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
从上面结果看出确实没有原型的效果
修改为Lookup注解方式
@Component(ConfigurableBeanFactory.SCOPE_SINGLETON)
public class A {
public void test() {
System.out.println(b());
}
@Lookup
public B b() {
return null;
}
}
再次执行启动类
com.shura.lookup.B@17d99928
com.shura.lookup.B@3834d63f
从结果来看大家也了解了其作用。
效果有了,就来看下源码如何做到的,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);
}
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);
}
}
上面看出如果是有@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());
}
}
主要看关键逻辑是通过BeanFactory.getBean()获取的原型Bean,那么自然每次的Bean对象都是不一样的
以上就是@Lookup注解的源码分析了,下一篇介绍推断构造方法扩展点
欢迎关注,学习不迷路!