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來裝載就好。