前言
在之前的文章中，我們已經對 bean 的準備工作進行了講解，包括 bean 定義和 FactoryBean 判斷等。在這個基礎上，我們可以更加深入地理解 getBean 方法的實現邏輯，并在后續(xù)的學習中更好地掌握createBean 方法的實現細節(jié)。
getBean用法
講解getBean方法之前，我們先來看看他有幾種常見的用法：
// 創(chuàng)建一個Spring容器
AnnotationConfigApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class);
UserService bean1 = applicationContext.getBean(UserService.class);
UserService bean2 = (UserService)applicationContext.getBean("userService");
UserService bean3 = applicationContext.getBean("userService",UserService.class);
UserService bean4 = (UserService) applicationContext.getBean("userService",new OrderService());
bean1.test();
bean2.test();
bean3.test();
bean4.test();
關于獲取 bean 的方法，前兩種方法應該比較常見，這里就不再贅述。第三種方法實際上是在獲取 bean 的時候，會先判斷是否符合指定的類型，如果符合，則進行類型轉換并返回對應的 bean 實例。第四種方法則是在創(chuàng)建 bean 實例時，通過推斷構造方法的方式來選擇使用帶有參數的構造方法進行實例化。
如果我們想要讓第四種方法生效，可以考慮使用多例的形式，即通過設置 scope 屬性為 prototype 來實現。這樣，每次獲取 bean 時，都會創(chuàng)建新的 bean 實例，從而可以觸發(fā)使用帶有參數的構造方法進行實例化，比如這樣：
@Component
@Scope("prototype")
public class UserService {
public UserService(){
System.out.println(0);
}
public UserService(OrderService orderService){
System.out.println(1);
}
public void test(){
System.out.println(11);
}
}
getBean大體流程
由于方法代碼太多，我就不貼代碼了，我這邊只貼一些主要的偽代碼，方便大家閱讀，然后我在對每個流程細講下：
protected <T> T doGetBean(
String name, @Nullable Class<T> requiredType, @Nullable Object[] args, boolean typeCheckOnly)
throws BeansException {
// name有可能是 &xxx 或者 xxx，如果name是&xxx，那么beanName就是xxx
// name有可能傳入進來的是別名，那么beanName就是id
String beanName = transformedBeanName(name);
Object beanInstance;
// Eagerly check singleton cache for manually registered singletons.
Object sharedInstance = getSingleton(beanName);
if (sharedInstance != null && args == null) {
// 如果sharedInstance是FactoryBean，那么就調用getObject()返回對象
}
else {
//檢查是否本beanfactory沒有當前bean定義，查看有父容器，如果有，則調用父容器的getbean方法
try {
RootBeanDefinition mbd = getMergedLocalBeanDefinition(beanName);
// 檢查BeanDefinition是不是Abstract的
checkMergedBeanDefinition(mbd, beanName, args);
// Guarantee initialization of beans that the current bean depends on.
//查看是否有dependsOn注解，如果存在循環(huán)依賴則報錯
// Create bean instance.
if (mbd.isSingleton()) {
//調用createBean方法
//如果是FactoryBean則調用getObject
}
else if (mbd.isPrototype()) {
//調用createBean方法，與單例只是前后邏輯不一樣
//如果是FactoryBean則調用getObject
}
else {
Scope不同類型有不同實現
//調用createBean方法，與單例只是前后邏輯不一樣
//如果是FactoryBean則調用getObject
}
}catch{
......
}
}
// 檢查通過name所獲得到的beanInstance的類型是否是requiredType
return adaptBeanInstance(name, beanInstance, requiredType);
}
單例緩存池
在 Spring 中，不管傳入的 beanName 是多例的還是單例的，都會先從單例緩存池中獲取。有些人可能會覺得這樣做會浪費一些性能，但實際上 Spring 考慮到了大部分托管的 bean 都是單例的情況，因此忽略了這一點性能。實際上，這樣的性能消耗并不大?？梢詫⑵漕惐扔?Java 的雙親委派機制，都會先查看本加載器是否有緩存，如果沒有再向父加載器去加載。
parentBeanFactory
在分析 bean 定義是如何創(chuàng)建的時，我們可以不考慮單例緩存池中獲取對象的情況，而是逐步分析 bean 定義是如何創(chuàng)建的。在這個過程中，即使存在 parentBeanFactory，我們也可以跳過它，因為我們的啟動容器并沒有設置任何父容器。源碼也很簡單，如果本容器沒有 bean 定義，就直接調用父容器的 getBean 相關方法：
BeanFactory parentBeanFactory = getParentBeanFactory();
if (parentBeanFactory != null && !containsBeanDefinition(beanName)) {
// Not found -> check parent.
// &&&&xxx---->&xxx
String nameToLookup = originalBeanName(name);
if (parentBeanFactory instanceof AbstractBeanFactory) {
return ((AbstractBeanFactory) parentBeanFactory).doGetBean(
nameToLookup, requiredType, args, typeCheckOnly);
}
else if (args != null) {
// Delegation to parent with explicit args.
return (T) parentBeanFactory.getBean(nameToLookup, args);
}
else if (requiredType != null) {
// No args -> delegate to standard getBean method.
return parentBeanFactory.getBean(nameToLookup, requiredType);
}
else {
return (T) parentBeanFactory.getBean(nameToLookup);
}
}
dependsOn
在調用 getBean 方法之前，已經將合并的 bean 定義存入了容器中。因此，我們可以直接獲取已經合并好的 bean 定義，并解析 bean 定義上的 dependsOn 注解。具體的源碼邏輯如下：
RootBeanDefinition mbd = getMergedLocalBeanDefinition(beanName);
// 檢查BeanDefinition是不是Abstract的
checkMergedBeanDefinition(mbd, beanName, args);
// Guarantee initialization of beans that the current bean depends on.
String[] dependsOn = mbd.getDependsOn();
if (dependsOn != null) {
// dependsOn表示當前beanName所依賴的，當前Bean創(chuàng)建之前dependsOn所依賴的Bean必須已經創(chuàng)建好了
for (String dep : dependsOn) {
// beanName是不是被dep依賴了，如果是則出現了循環(huán)依賴
if (isDependent(beanName, dep)) {
throw new BeanCreationException(mbd.getResourceDescription(), beanName,
"Circular depends-on relationship between '" + beanName + "' and '" + dep + "'");
}
// dep被beanName依賴了，存入dependentBeanMap中，dep為key，beanName為value
registerDependentBean(dep, beanName);
// 創(chuàng)建所依賴的bean
try {
getBean(dep);
}
catch (NoSuchBeanDefinitionException ex) {
throw new BeanCreationException(mbd.getResourceDescription(), beanName,
"'" + beanName + "' depends on missing bean '" + dep + "'", ex);
}
}
}
這里的邏輯還是相對簡單的。如果當前 bean 被 dependsOn 注解所依賴，那么會先去創(chuàng)建所依賴的 bean。但是這種方式是解決不了循環(huán)依賴的問題的。在實現上，只使用了兩個 Map 進行判斷：
// 某個Bean被哪些Bean依賴了
private final Map<String, Set<String>> dependentBeanMap = new ConcurrentHashMap<>(64);
// 某個Bean依賴了哪些Bean
private final Map<String, Set<String>> dependenciesForBeanMap = new ConcurrentHashMap<>(64);
isSingleton
sharedInstance = getSingleton(beanName, () -> {
try {
return createBean(beanName, mbd, args);
}
catch (BeansException ex) {
// Explicitly remove instance from singleton cache: It might have been put there
// eagerly by the creation process, to allow for circular reference resolution.
// Also remove any beans that received a temporary reference to the bean.
destroySingleton(beanName);
throw ex;
}
});
beanInstance = getObjectForBeanInstance(sharedInstance, name, beanName, mbd);
在這個階段，我們可以看到代碼已經在準備創(chuàng)建單例 bean 實例了，因此我們可以不去深入理解這部分的源碼邏輯。反正，在 getSingleton 方法中，會調用 createBean 方法。這里使用了 lambda 表達式，如果有不太了解的讀者，可以參考下之前發(fā)的文章進行學習：
isPrototype
if (mbd.isPrototype()) {
// It's a prototype -> create a new instance.
Object prototypeInstance = null;
try {
beforePrototypeCreation(beanName);
prototypeInstance = createBean(beanName, mbd, args);
}
finally {
afterPrototypeCreation(beanName);
}
beanInstance = getObjectForBeanInstance(prototypeInstance, name, beanName, mbd);
}
在這個階段，我們發(fā)現創(chuàng)建 bean 的方法已經改變了，直接調用了 createBean 方法，而不是通過 getSingleton 方法進行調用。至于 beforePrototypeCreation 和 afterPrototypeCreation，我們可以不用管它們，因為它們只是存儲一些信息，對我們創(chuàng)建 bean 并沒有太大的影響。
其他Scope
講解這部分源碼之前，我們先來看看還有哪些Scope域：
//@RequestScope
@SessionScope
public class User {
}
現在我們來看一下 RequestScope 和 SessionScope，它們與其他作用域類似，只是一個組合注解。它們的元注解信息如下：
@Target({ElementType.TYPE, ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Scope(WebApplicationContext.SCOPE_SESSION)
public @interface SessionScope {
/**
* Alias for {@link Scope#proxyMode}.
* <p>Defaults to {@link ScopedProxyMode#TARGET_CLASS}.
*/
@AliasFor(annotation = Scope.class)
ScopedProxyMode proxyMode() default ScopedProxyMode.TARGET_CLASS;
}
然后我們再來看下Spring對其他Scope注解的邏輯判斷：
String scopeName = mbd.getScope();
if (!StringUtils.hasLength(scopeName)) {
throw new IllegalStateException("No scope name defined for bean ′" + beanName + "'");
}
Scope scope = this.scopes.get(scopeName);
if (scope == null) {
throw new IllegalStateException("No Scope registered for scope name '" + scopeName + "'");
}
try { // session.getAttriute(beaName) setAttri
Object scopedInstance = scope.get(beanName, () -> {
beforePrototypeCreation(beanName);
try {
return createBean(beanName, mbd, args);
}
finally {
afterPrototypeCreation(beanName);
}
});
beanInstance = getObjectForBeanInstance(scopedInstance, name, beanName, mbd);
}
catch (IllegalStateException ex) {
throw new ScopeNotActiveException(beanName, scopeName, ex);
}
其實他主要用的getAttriute方法，我們看下scope.get主要的邏輯判斷：
public Object get(String name, ObjectFactory<?> objectFactory) {
RequestAttributes attributes = RequestContextHolder.currentRequestAttributes();
Object scopedObject = attributes.getAttribute(name, getScope());
if (scopedObject == null) {
scopedObject = objectFactory.getObject();
attributes.setAttribute(name, scopedObject, getScope());
// Retrieve object again, registering it for implicit session attribute updates.
// As a bonus, we also allow for potential decoration at the getAttribute level.
Object retrievedObject = attributes.getAttribute(name, getScope());
if (retrievedObject != null) {
// Only proceed with retrieved object if still present (the expected case).
// If it disappeared concurrently, we return our locally created instance.
scopedObject = retrievedObject;
}
}
return scopedObject;
}
在這個階段，我們可以看到，通過 objectFactory.getObject() 方法，會調用外層定義的 lambda 表達式，也就是 createBean 方法的邏輯。假設這個過程成功地創(chuàng)建了 bean 實例，并返回了它，那么 Spring 會調用 setAttribute 方法，將這個 bean 實例以及其 scope 值放入以 beanName 為 key 的屬性中。這樣，當需要獲取這個 bean 實例時，Spring 就可以直接從作用域中獲取了。
結語
getBean 方法主要包含以下幾個步驟：文章來源：http://www.zghlxwxcb.cn/news/detail-433641.html
- 首先，從單例緩存池中獲取 bean 實例。如果沒有，Spring 會創(chuàng)建新的 bean 實例，并將其添加到單例緩存池中。
- 接著，Spring 會檢查當前容器是否有指定名稱的 bean 定義。如果沒有，Spring 會調用父容器的 getBean 方法，直到找到為止。
- 一旦找到了 bean 定義，Spring 會根據不同的作用域類型，創(chuàng)建對應的 bean 實例，并將其存儲在作用域中。
- 最后，Spring 會返回創(chuàng)建好的 bean 實例。
非常好，這樣我們對 getBean 方法的邏輯判斷有了一個大體的了解，有助于我們更好地理解 createBean 方法的實現細節(jié)。如果在后續(xù)的學習中有任何問題或疑問，可以隨時聯系我進行咨詢文章來源地址http://www.zghlxwxcb.cn/news/detail-433641.html
到了這里，關于Spring源碼：Bean生命周期（三）的文章就介紹完了。如果您還想了解更多內容，請在右上角搜索TOY模板網以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網！
