Spring:lookup-method方法注入

一.Spring中Bean的状态

无状态Bean:bean一旦实例化就被加进会话池中，各个用户都可以共用。即使用户已经消亡，bean 的生命期也不一定结束，它可能依然存在于会话池中，供其他用户调用。
有状态Bean: 每个用户有自己特有的一个实例，在用户的生存期内，bean保持了用户的信息,即“有状态”；一旦用户灭亡（调用结束或实例结束），bean的生命期也告结束。即每个用户最初都会得到一个初始的bean。
也就是说，一次会话结束，Bean的生命周期就结束的，就是有状态的Bean。
Spring中无状态Bean 一般配置成sigleton 单例模式.

二.问题的引出

假设一个单例的Bean A需要引用一个非单例模式的Bean B,那么在每次引用B的时候都想拿到一个新的B,该怎么做?要知道,Bean A是单例模式的,只会被创建一次,注入一次属性,也就是说，即使B是property模式，那也是只会一个相同的B,因为A只会被注入一次。

Spring官方文档:
When a bean has dependency on another bean, we inject the bean using the setter property or through the constructor.
The getter method will return us the reference that is been set but suppose you want a new instance of the dependent bean each time you invoke the getter method, then you will probably have to follow a different approach.
In this article, we will see an example of method injection using lookup-method attribute.

三.解决办法

1.让bean A通过实现ApplicationContextAware来感知applicationContext（即可以获得容器上下文），从而能在运行时通过ApplicationContext.getBean(String beanName)的方法来获取最新的bean B。但是如果用ApplicationContextAware接口，就让我们与Spring代码耦合了，违背了反转控制原则（IoC，即bean完全由Spring容器管理，我们自己的代码只需要用bean就可以了）。
所以Spring为我们提供了方法注入的方式来实现以上的场景。方法注入方式主要是通过标签。

2.lookup-method方法注入
下面我们用一个例子来说明lookup-method的用法。
假设有一个果盘，果盘里放了一些水果，比如苹果，香蕉等，我们希望我们每次在果盘里拿到的都是最新鲜的水果。

 - // 定义一个水果类 public class Fruit {
       public Fruit() {
           System.out.println("I got Fruit");
       } }
   
   // 苹果 public class Apple extends Fruit {
       public Apple() {
           System.out.println("I got a fresh apple");
       } }
   
   // 香蕉 public class Banana extends Fruit {
       public Bananer () {
           System.out.println("I got a  fresh banana");
       } }
   
   // 水果盘，可以拿到水果 public abstract class FruitPlate{
       // 抽象方法获取新鲜水果
       protected abstract Fruit getFruit(); }

spring配置：

<!-- 这是2个非单例模式的bean -->
<bean id="apple" class="cn.com.willchen.test.di.Apple" scope="prototype"/>
<bean id="bananer" class="cn.com.willchen.test.di.Bananer " scope="prototype"/>

<bean id="fruitPlate1" class="cn.com.willchen.test.di.FruitPlate">
    <lookup-method name="getFruit" bean="apple"/>
</bean>
<bean id="fruitPlate2" class="cn.com.willchen.test.di.FruitPlate">
    <lookup-method name="getFruit" bean="banana"/>
</bean>

测试代码：

public static void main(String[] args) {
    ApplicationContext app = new ClassPathXmlApplicationContext("classpath:resource/applicationContext.xml");

    FruitPlate fp1= (FruitPlate)app.getBean("fruitPlate1");
    FruitPlate fp2 = (FruitPlate)app.getBean("fruitPlate2");

    fp1.getFruit();
    fp2.getFruit();
}
测试结果: 
I got Fruit 
I got a fresh apple 
I got Fruit 
I got a fresh banana

从上面例子我们可以看到，在代码中，我们没有用到Spring的任何类和接口，实现了与Spring代码的解耦。其中，最为核心的部分就是lookup-method的配置和FruitPlate.getFruit()方法。上面代码中，我们可以看到getFruit()方法是个抽象方法，我们并没有实现它啊，那它是怎么拿到水果的呢。这里的奥妙就是Srping应用了CGLIB（动态代理）类库。Spring在初始化容器的时候对配置的bean做了特殊处理，Spring会对bean指定的class做动态代理，代理标签中name属性所指定的方法，返回bean属性指定的bean实例对象。每次我们调用fruitPlate1或者fruitPlate2这2个bean的getFruit()方法时，其实是调用了CGLIB生成的动态代理类的方法。关于CGLIB大家可自行在网上查阅。

lookup-method实现方式说明：

<bean class="beanClass">
    <lookup-method name="method" bean="non-singleton-bean"/>
</bean>

method是beanClass中的一个方法，beanClass和method是不是抽象都无所谓，不会影响CGLIB的动态代理，根据项目实际需求去定义。non-singleton-bean指的是lookup-method中bean属性指向的必须是一个非单例模式的bean，当然如果不是也不会报错，只是每次得到的都是相同引用的bean（同一个实例），这样用lookup-method就没有意义了。

另外对于method在代码中的签名有下面的标准：
<public|protected> [abstract] theMethodName(no-arguments);
public|protected要求方法必须是可以被子类重写和调用的；
abstract可选，如果是抽象方法，CGLIB的动态代理类就会实现这个方法，如果不是抽象方法，就会覆盖这个方法，所以没什么影响；
return-type就是non-singleton-bean的类型咯，当然可以是它的父类或者接口。
no-arguments不允许有参数。

3.使用@Lookup注解

@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface Lookup {

    /**
     * This annotation attribute may suggest a target bean name to look up.
     * If not specified, the target bean will be resolved based on the
     * annotated method's return type declaration.
     */
    String value() default "";

}

相关参考链接:https://www.jianshu.com/p/5254e1947d77
https://stackoverflow.com/questions/26028341/how-to-use-spring-lookup-annotation
https://blog.csdn.net/G0_hw/article/details/82149000