原型 Bean 被固定

原型 Bean 被固定

我们再来看另外一个关于 Bean 定义不生效的案例。在定义 Bean 时，有时候我们会使用原型 Bean，例如定义如下：

package com.zou.service.impl;

import org.springframework.beans.factory.config.ConfigurableBeanFactory;
import org.springframework.context.annotation.Scope;
import org.springframework.stereotype.Service;

/**
 * @author: 邹祥发
 * @date: 2022/6/21 19:14
 */
@Service
@Scope(ConfigurableBeanFactory.SCOPE_PROTOTYPE)
public class ServiceImpl {
}

然后我们按照下面的方式去使用它：

package com.zou.controller;

import com.zou.service.impl.ServiceImpl;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RequestMethod;
import org.springframework.web.bind.annotation.RestController;

/**
 * @author: 邹祥发
 * @date: 2022/6/20 20:40
 */
@RestController
public class HelloWorldController {
    @Autowired
    private ServiceImpl serviceImpl;

    @RequestMapping(path = "hi", method = RequestMethod.GET)
    public String hi() {
        return "helloworld,service is : " + serviceImpl;
    }
}

结果，我们会发现，启动就已经报错了，如下：

很明显，这很可能和我们定义 ServiceImpl 为原型 Bean 的初衷背道而驰，如何理解这个现象呢？

解析

当一个属性成员 serviceImpl 声明为 @Autowired 后，那么在创建HelloWorldController 这个 Bean 时，会先使用构造器反射出实例，然后来装配各个标记为 @Autowired 的属性成员（装配方法参考AbstractAutowireCapableBeanFactory#populateBean）。具体到执行过程，它会使用很多 BeanPostProcessor 来做完成工作，其中一种是AutowiredAnnotationBeanPostProcessor，它会通过DefaultListableBeanFactory#findAutowireCandidates 寻找到 ServiceImpl 类型的Bean，然后设置给对应的属性（即 serviceImpl 成员）。关键执行步骤可参考AutowiredAnnotationBeanPostProcessor.AutowiredFieldElement#inject：

protected void inject(Object bean, @Nullable String beanName, @Nullable PropertyValues pvs) throws Throwable {
    Field field = (Field) this.member;
    // 寻找"bean"
    Object value;
    if (this.cached) {
        try {
            value = resolvedCachedArgument(beanName, this.cachedFieldValue);
        }
        catch (NoSuchBeanDefinitionException ex) {
            // 省略其他非关键代码
        }
    }
    else {
        // 省略其他非关键代码
        value = resolveFieldValue(field, bean, beanName);
    }
    if (value != null) {
        // 将bean设置给成员字段
        ReflectionUtils.makeAccessible(field);
        field.set(bean, value);
    }
}

待我们寻找到要自动注入的 Bean 后，即可通过反射设置给对应的 field。这个 field 的执行只发生了一次，所以后续就固定起来了，它并不会因为 ServiceImpl 标记了SCOPE_PROTOTYPE 而改变。所以，当一个单例的 Bean，使用 autowired 注解标记其属性时，你一定要注意这个属性值会被固定下来。

解决方案

通过上述源码分析，我们可以知道要修正这个问题，肯定是不能将 ServiceImpl 的 Bean固定到属性上的，而应该是每次使用时都会重新获取一次。所以这里我提供了两种修正方式：

自动注入 Context

即自动注入 ApplicationContext，然后定义 getServiceImpl() 方法，在方法中获取一个新的 ServiceImpl 类型实例。修正代码如下：

package com.zou.controller;

import com.zou.service.impl.ServiceImpl;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.context.ApplicationContext;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RequestMethod;
import org.springframework.web.bind.annotation.RestController;

/**
 * @author: 邹祥发
 * @date: 2022/6/20 20:40
 */
@RestController
public class HelloWorldController {

    @Autowired
    private ApplicationContext applicationContext;

    @RequestMapping(path = "hi", method = RequestMethod.GET)
    public String hi() {
        return "helloworld,service is : " + getServiceImpl();
    }

    public ServiceImpl getServiceImpl() {
        return applicationContext.getBean(ServiceImpl.class);
    }

}

使用 Lookup 注解

类似修正方法 1，也添加一个 getServiceImpl 方法，不过这个方法是被 Lookup 标记的。修正代码如下：

package com.zou.controller;

import com.zou.service.impl.ServiceImpl;
import org.springframework.beans.factory.annotation.Lookup;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RequestMethod;
import org.springframework.web.bind.annotation.RestController;

/**
 * @author: 邹祥发
 * @date: 2022/6/20 20:40
 */
@RestController
public class HelloWorldController {

    @RequestMapping(path = "hi", method = RequestMethod.GET)
    public String hi() {
        return "helloworld,service is : " + getServiceImpl();
    }

    @Lookup
    public ServiceImpl getServiceImpl() {
        return null;
    }

}

通过这两种修正方式，再次测试程序，我们会发现结果已经符合预期（每次访问这个接口，都会创建新的 Bean）。这里我们不妨再拓展下，讨论下 Lookup 是如何生效的。毕竟在修正代码中，我们看到getServiceImpl 方法的实现返回值是 null，这或许很难说服自己。首先，我们可以通过调试方式看下方法的执行，参考下图：

从上图我们可以看出，我们最终的执行因为标记了 Lookup 而走入了
CglibSubclassingInstantiationStrategy.LookupOverrideMethodInterceptor，这个方法的关键实现参考 LookupOverrideMethodInterceptor#intercept：

private final BeanFactory owner;

public Object intercept(Object obj, Method method, Object[] args, MethodProxy mp) throws Throwable {
    // Cast is safe, as CallbackFilter filters are used selectively.
    LookupOverride lo = (LookupOverride) getBeanDefinition().getMethodOverrides().getOverride(method);
    Assert.state(lo != null, "LookupOverride not found");
    Object[] argsToUse = (args.length > 0 ? args : null);  // if no-arg, don't insist on args at all
    if (StringUtils.hasText(lo.getBeanName())) {
        // 根据@Lookup注解配置的beanName去BeanFactory中获取Bean对象，（没有执行有@Lookup注解的方法）
        return (argsToUse != null ? this.owner.getBean(lo.getBeanName(), argsToUse) :
                this.owner.getBean(lo.getBeanName()));
    }
    else {
        return (argsToUse != null ? this.owner.getBean(method.getReturnType(), argsToUse) :
                this.owner.getBean(method.getReturnType()));
    }
}

我们的方法调用最终并没有走入案例代码实现的 return null 语句，而是通过 BeanFactory来获取 Bean。所以从这点也可以看出，其实在我们的 getServiceImpl 方法实现中，随便怎么写都行，这不太重要。

例如，我们可以使用下面的实现来测试下这个结论：

package com.zou.controller;

import com.zou.service.impl.ServiceImpl;
import lombok.extern.slf4j.Slf4j;
import org.springframework.beans.factory.annotation.Lookup;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RequestMethod;
import org.springframework.web.bind.annotation.RestController;

/**
 * @author: 邹祥发
 * @date: 2022/6/20 20:40
 */
@RestController
@Slf4j
public class HelloWorldController {

    @RequestMapping(path = "hi", method = RequestMethod.GET)
    public String hi() {
        return "helloworld,service is : " + getServiceImpl();
    }

    @Lookup
    public ServiceImpl getServiceImpl() {
        //下面的日志会输出么？
        log.info("executing this method");
        return null;
    }

}

以上代码，添加了一行代码输出日志。测试后，我们会发现并没有日志输出。这也验证了，当使用 Lookup 注解一个方法时，这个方法的具体实现已并不重要。再回溯下前面的分析，为什么我们走入了 CGLIB 搞出的类，这是因为我们有方法标记了Lookup。我们可以从下面的这段代码得到验证，参考SimpleInstantiationStrategy#instantiate：

@Override
public Object instantiate(RootBeanDefinition bd, @Nullable String beanName, BeanFactory owner) {
    // Don't override the class with CGLIB if no overrides.
    if (!bd.hasMethodOverrides()) {
        return BeanUtils.instantiateClass(constructorToUse);
    } else {
        // Must generate CGLIB subclass.
        return instantiateWithMethodInjection(bd, beanName, owner);
    }
}

在上述代码中，当 hasMethodOverrides 为 true 时，则使用 CGLIB。而在本案例中，这个条件的成立在于解析 HelloWorldController 这个 Bean 时，我们会发现有方法标记了Lookup，此时就会添加相应方法到属性 methodOverrides 里面去（此过程由
AutowiredAnnotationBeanPostProcessor#determineCandidateConstructors 完成）。添加后效果图如下：

以上即为 Lookup 的一些关键实现思路。

回顾

不难发现，要使用好 Spring，就一定要了解它的一些潜规则，例如默认扫描 Bean 的范围、自动装配构造器等等。如果我们不了解这些规则，大多情况下虽然也能工作，但是稍微变化，则可能完全失效，例如在隐式扫描不到 Bean 的定义中，我们也只是把 Controller 从一个包移动到另外一个包，接口就失效了。另外，通过这三个案例的分析，我们也能感受到 Spring 的很多实现是通过反射来完成的，了解了这点，对于理解它的源码实现会大有帮助。例如在定义的 Bean 缺少隐式依赖 中，为什么定义了多个构造器就可能报错，因为使用反射方式来创建实例必须要明确使用的是哪一个构造器。最后，我想说，在 Spring 框架中，解决问题的方式往往有多种，不要拘泥于套路。就像本案例 ，使用 ApplicationContext 和 Lookup 注解，都能解决原型 Bean 被固定的问题一样。

本项目代码链接：https://github.com/Zou2021/springboot

本站文章除注明转载/出处外，均为本站原创或翻译，转载前请务必署名，转载请...
最后编辑时间为: 2022/06/21 20:57:00