前言
在之前的文章中，我們已經對 bean 的準備作業進行了講解，包括 bean 定義和 FactoryBean 判斷等，在這個基礎上，我們可以更加深入地理解 getBean 方法的實作邏輯，并在后續的學習中更好地掌握createBean 方法的實作細節，
getBean用法
講解getBean方法之前，我們先來看看他有幾種常見的用法：
// 創建一個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 實體，第四種方法則是在創建 bean 實體時，通過推斷構造方法的方式來選擇使用帶有引數的構造方法進行實體化，
如果我們想要讓第四種方法生效，可以考慮使用多例的形式，即通過設定 scope 屬性為 prototype 來實作，這樣，每次獲取 bean 時，都會創建新的 bean 實體，從而可以觸發使用帶有引數的構造方法進行實體化，比如這樣：
@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注解，如果存在回圈依賴則報錯
// 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 定義是如何創建的時，我們可以不考慮單例快取池中獲取物件的情況，而是逐步分析 bean 定義是如何創建的，在這個程序中，即使存在 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創建之前dependsOn所依賴的Bean必須已經創建好了
for (String dep : dependsOn) {
// beanName是不是被dep依賴了，如果是則出現了回圈依賴
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);
// 創建所依賴的bean
try {
getBean(dep);
}
catch (NoSuchBeanDefinitionException ex) {
throw new BeanCreationException(mbd.getResourceDescription(), beanName,
"'" + beanName + "' depends on missing bean '" + dep + "'", ex);
}
}
}
這里的邏輯還是相對簡單的，如果當前 bean 被 dependsOn 注解所依賴，那么會先去創建所依賴的 bean，但是這種方式是解決不了回圈依賴的問題的，在實作上，只使用了兩個 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);
在這個階段，我們可以看到代碼已經在準備創建單例 bean 實體了，因此我們可以不去深入理解這部分的原始碼邏輯，反正，在 getSingleton 方法中，會呼叫 createBean 方法，這里使用了 lambda 運算式，如果有不太了解的讀者，可以參考下之前發的文章進行學習：
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);
}
在這個階段，我們發現創建 bean 的方法已經改變了，直接呼叫了 createBean 方法，而不是通過 getSingleton 方法進行呼叫，至于 beforePrototypeCreation 和 afterPrototypeCreation，我們可以不用管它們，因為它們只是存盤一些資訊，對我們創建 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 方法的邏輯，假設這個程序成功地創建了 bean 實體，并回傳了它，那么 Spring 會呼叫 setAttribute 方法，將這個 bean 實體以及其 scope 值放入以 beanName 為 key 的屬性中，這樣，當需要獲取這個 bean 實體時，Spring 就可以直接從作用域中獲取了，
結語
getBean 方法主要包含以下幾個步驟：
- 首先，從單例快取池中獲取 bean 實體，如果沒有，Spring 會創建新的 bean 實體，并將其添加到單例快取池中，
- 接著，Spring 會檢查當前容器是否有指定名稱的 bean 定義，如果沒有，Spring 會呼叫父容器的 getBean 方法，直到找到為止，
- 一旦找到了 bean 定義，Spring 會根據不同的作用域型別，創建對應的 bean 實體，并將其存盤在作用域中，
- 最后，Spring 會回傳創建好的 bean 實體，
非常好，這樣我們對 getBean 方法的邏輯判斷有了一個大體的了解，有助于我們更好地理解 createBean 方法的實作細節，如果在后續的學習中有任何問題或疑問，可以隨時聯系我進行咨詢，
ps：以上內容，純屬個人見解，有任何問題下方評論！關注博主公眾號，原始碼專題、面試精選、AI最新擴展等你來看！原創撰寫不易，轉載請說明出處！
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/551606.html
標籤：其他
上一篇：Java 雙指標專案中的實際應用
下一篇：返回列表