- Spring應用上下文中所有Bean都是使用單例（singleton）模式創建的。
- 在大多數情況下，單例Bean是很理想的方案。初始化和垃圾回收對象實例所帶來的成本都是很低的。在大多數情況下，單例Bean是很理想的方案。初始化和垃圾回收對象實例所帶來的成本都是很低的。
- 但有時候，你可能會發現，所使用的類是易變的（mutable），他們會保持一些狀態，因此重用是不安全的。在這種情況下，將class聲明爲單例的Bean就不是什麼好主意了，因爲對象會被污染，然後重用被污染的對象時會出現意想不到的問題。
- Spring已經給出瞭解決方案。Spring定義了多種作用域，可以基於這些作用域創建bean，如下：
| 作用域名稱 | 描述 |
|---|---|
| 單例（Singleton） | 在整個應用中，只會創建一個bean的實例 |
| 原型（Prototype） | 每次注入或者通過上下文獲取的時候，都會創建一個新的bean實例 |
| 會話（Session） | 在Web應用中，爲每個會話創建一個bean實例 |
| 請求（Request） | 在Web應用中，爲每個請求創建一個bean實例 |
聲明spring bean的作用域需要用到 @Scope註解
下表展示對應上面的各種類型
| value | 描述 |
|---|---|
| ConfigurableBeanFactory.SCOPE_PROTOTYPE | 這個是說在每次注入的時候回自動創建一個新的bean實例 |
| ConfigurableBeanFactory.SCOPE_SINGLETON | 單例模式，在整個應用中只能創建一個實例 |
| WebApplicationContext.SCOPE_GLOBAL_SESSION | 全局session中的,一般不常用 |
| WebApplicationContext.SCOPE_APPLICATION | 在一個web應用中只創建一個實例 |
| WebApplicationContext.SCOPE_REQUEST | 在一個請求中創建一個實例 |
| WebApplicationContext.SCOPE_SESSION | 每次創建一個會話中創建一個實例 |
除了value屬性外，還有個屬性
| proxyMode | 描述 |
|---|---|
| ScopedProxyMode.INTERFACES | 創建一個JDK代理模式 |
| ScopedProxyMode.NO | (默認)不進行代理 |
| ScopedProxyMode.TARGET_CLASS | 基於類的代理模式 |
在使用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 = ConfigurableBeanFactory.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，因此不是單例的，這時候跑個測試就看出這樣寫的問題：
輸出的結果是：
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] theMethodName(no-arguments);
參考鏈接：