Spring中不同生命周期Bean的依賴管理

在使用Spring時，可能會遇到這種情況：一個單例的Bean依賴另一個非單例的Bean。如果簡單的使用自動裝配來注入依賴，就可能會出現一些問題，如下所示：

單例的Class A

@Component
public class ClassA {
    @Autowired
    private ClassB classB;

    public void printClass() {
        System.out.println("This is Class A: " + this);
        classB.printClass();
    }
}

非單例的Class B

@Component
@Scope(value = SCOPE_PROTOTYPE)
public class ClassB {
    public void printClass() {
        System.out.println("This is Class B: " + this);
    }
}

這里Class A采用了默認的單例scope，並依賴於Class B, 而Class B的scope是prototype，因此不是單例的，這時候跑個測試就看出這樣寫的問題：

@RunWith(SpringRunner.class)
@ContextConfiguration(classes = {ClassA.class, ClassB.class})
public class MyTest {
    @Autowired
    private ClassA classA;

    @Test
    public void simpleTest() {
        for (int i = 0; i < 3; i++) {
            classA.printClass();
        }
    }
}

輸出的結果是：

This is Class A: ClassA@282003e1
This is Class B: ClassB@7fad8c79
This is Class A: ClassA@282003e1
This is Class B: ClassB@7fad8c79
This is Class A: ClassA@282003e1
This is Class B: ClassB@7fad8c79

可以看到，兩個類的Hash Code在三次輸出中都是一樣。Class A的值不變是可以理解的，因為它是單例的，但是Class B的scope是prototype卻也保持Hash Code不變，似乎也成了單例？

產生這種的情況的原因是，Class A的scope是默認的singleton，因此Context只會創建Class A的bean一次，所以也就只有一次注入依賴的機會，容器也就無法每次給Class A提供一個新的Class B。

不那么好的解決方案

要解決上述問題，可以對Class A做一些修改，讓它實現ApplicationContextAware。

@Component
public class ClassA implements ApplicationContextAware {
    private ApplicationContext applicationContext;

    public void printClass() {
        System.out.println("This is Class A: " + this);
        getClassB().printClass();
    }

    public ClassB getClassB() {
        return applicationContext.getBean(ClassB.class);
    }

    public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
        this.applicationContext = applicationContext;
    }
}

這樣就能夠在每次需要到Class B的時候手動去Context里找到新的bean。再跑一次測試后得到了以下輸出：

This is Class A: com.devhao.ClassA@4df828d7
This is Class B: com.devhao.ClassB@31206beb
This is Class A: com.devhao.ClassA@4df828d7
This is Class B: com.devhao.ClassB@3e77a1ed
This is Class A: com.devhao.ClassA@4df828d7
This is Class B: com.devhao.ClassB@3ffcd140

可以看到Class A的Hash Code在三次輸出中保持不變，而Class B的卻每次都不同，說明問題得到了解決，每次調用時用到的都是新的實例。

但是這樣的寫法就和Spring強耦合在一起了，Spring提供了另外兩種方法來降低侵入性。

@Lookup

Spring提供了一個名為@Lookup的注解，這是一個作用在方法上的注解，被其標注的方法會被重寫，然后根據其返回值的類型，容器調用BeanFactory的getBean()方法來返回一個bean。

@Component
public class ClassA {
    public void printClass() {
        System.out.println("This is Class A: " + this);
        getClassB().printClass();
    }

    @Lookup
    public ClassB getClassB() {
        return null;
    }
}

可以發現簡潔了很多，而且不再和Spring強耦合，再次運行測試依然可以得到正確的輸出。
被標注的方法的返回值不再重要，因為容器會動態生成一個子類然后將這個被注解的方法重寫/實現，最終調用的是子類的方法。

使用的@Lookup的方法需要符合如下的簽名：

<public|protected> [abstract] <return-type> theMethodName(no-arguments);

作用域代理

Spring還提供了另外一種方法來解決這個問題。簡單來說就是如果一個bean A對另外一個作用域更短的bean B有依賴，那么在實例化bean A並注入依賴時，注入的不是bean B本身，而是一個AOP代理，這個代理可以找到實際的bean。

@Component
public class ClassA {
    @Autowired
    private ClassB classB;

    public void printClass() {
        System.out.println("This is Class A: " + this);
        classB.printClass();
    }
}

@Component
@Scope(value = SCOPE_PROTOTYPE, proxyMode = ScopedProxyMode.TARGET_CLASS)
public class ClassB {
    public void printClass() {
        System.out.println("This is Class B: " + this);
    }
}

可以看出，使用這種方法的好處是僅需對bean B進行簡單的配置，並且bean A根本不用意識到代理的存在，將bean B當做一個正常的bean來裝載就好。