Spring源码:Bean生命周期(三)

这篇具有很好参考价值的文章主要介绍了Spring源码:Bean生命周期(三)。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

前言

在之前的文章中,我们已经对 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 方法主要包含以下几个步骤:

  1. 首先,从单例缓存池中获取 bean 实例。如果没有,Spring 会创建新的 bean 实例,并将其添加到单例缓存池中。
  2. 接着,Spring 会检查当前容器是否有指定名称的 bean 定义。如果没有,Spring 会调用父容器的 getBean 方法,直到找到为止。
  3. 一旦找到了 bean 定义,Spring 会根据不同的作用域类型,创建对应的 bean 实例,并将其存储在作用域中。
  4. 最后,Spring 会返回创建好的 bean 实例。

非常好,这样我们对 getBean 方法的逻辑判断有了一个大体的了解,有助于我们更好地理解 createBean 方法的实现细节。如果在后续的学习中有任何问题或疑问,可以随时联系我进行咨询文章来源地址https://www.toymoban.com/news/detail-433641.html

到了这里,关于Spring源码:Bean生命周期(三)的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • Spring源码:Bean的生命周期(二)

    让我们继续讲解Spring的Bean实例化过程。在上一节中,我们已经讲解了Spring是如何将Bean定义加入到IoC容器中,并使用合并的Bean定义来包装原始的Bean定义。接下来,我们将继续讲解Spring的 getBean() 方法,特别是针对 FactoryBean 的解析。 在 getBean() 方法中,Spring还支持对 FactoryBea

    2024年02月02日
    浏览(23)
  • Spring之Bean生命周期源码解析

    ClassPathBeanDefinitionScanner.java ClassPathScanningCandidateComponentProvider.java 通过组件索引寻找 这里的 componentsIndex 在初始化的时候会尝试解析 META-INF/spring.components 文件中的配置信息 把断点打在 ClassPathScanningCandidateComponentProvider 的 setResourceLoader 方法上调试可以看到堆栈 可以看到,的确

    2024年02月11日
    浏览(31)
  • 【Spring】Spring之Bean生命周期源码解析

    什么是bean的生命周期 是指bean在spring中是如何生成,如何销毁的; spring创建对象的过程,就是IOC(控制反转)的过程; JFR Java Flight Record,java飞行记录,类似于飞机的黑匣子,是JVM内置的基于事件的JDK监控记录框架,主要用于问题定位和持续监控; 入口代码: Spring启动的时

    2024年02月15日
    浏览(32)
  • 【框架源码】Spring源码解析之Bean生命周期流程

    观看本文前,我们先思考一个问题,什么是Spring的bean的生命周期?这也是我们在面试的时候,面试官常问的一个问题。 在没有Spring之前,我们创建对象的时候,采用new的方式,当对象不在被使用的时候,由Java的垃圾回收机制回收。 而 Spring 中的对象是 bean,bean 和普通的 J

    2024年02月09日
    浏览(29)
  • 【深入Spring源码解析:解密Bean的生命周期】

    Spring是Java企业级应用开发领域的一颗明星,它提供了很多方便开发人员的工具和思想。在分布式系统中,Spring的分布式远程协作方案,比如REST、Web服务以及消息传递等,也是不可或缺的。 你知道吗?在我们使用Spring时,容器中存放的所有对象,在Spring启动的时候就完成了实

    2024年02月05日
    浏览(30)
  • 【Spring专题】Spring之Bean的生命周期源码解析——上(扫描生成BeanDefinition)

    由于Spring源码分析是一个前后联系比较强的过程,而且这边分析,也是按照代码顺序讲解的,所以不了解前置知识的情况下,大概率没办法看懂当前的内容。所以,特别推荐看看我前面的文章(自上而下次序): Spring底层核心原理解析——引导篇【学习难度: ★★☆☆☆ 】

    2024年02月13日
    浏览(28)
  • 【Spring专题】Spring之Bean的生命周期源码解析——阶段一(扫描生成BeanDefinition)

    由于Spring源码分析是一个前后联系比较强的过程,而且这边分析,也是按照代码顺序讲解的,所以不了解前置知识的情况下,大概率没办法看懂当前的内容。所以,特别推荐看看我前面的文章(自上而下次序): Spring底层核心原理解析——引导篇【学习难度: ★★☆☆☆ 】

    2024年02月13日
    浏览(28)
  • 【Spring专题】Spring之Bean的生命周期源码解析——阶段二(IOC之实例化)

    由于Spring源码分析是一个前后联系比较强的过程,而且这边分析,也是按照代码顺序讲解的,所以不了解前置知识的情况下,大概率没办法看懂当前的内容。所以,特别推荐看看我前面的文章(自上而下次序): Spring底层核心原理解析——引导篇【学习难度: ★★☆☆☆ 】

    2024年02月13日
    浏览(38)
  • 【Spring专题】Spring之Bean的生命周期源码解析——阶段二(二)(IOC之属性填充/依赖注入)

    由于Spring源码分析是一个前后联系比较强的过程,而且这边分析,也是按照代码顺序讲解的,所以不了解前置知识的情况下,大概率没办法看懂当前的内容。所以,特别推荐看看我前面的文章(自上而下次序): Spring底层核心原理解析【学习难度: ★★☆☆☆ 】 手写简易

    2024年02月12日
    浏览(28)
  • Spring bean 生命周期

    在互联网领域中,Spring框架扮演着重要的角色。作为一个开源的Java应用程序开发框架,Spring提供了一种灵活而强大的方式来构建可扩展的应用程序。Spring框架中的一个重要概念是Bean,它是Spring应用程序的基本构建块之一。了解Spring Bean的生命周期对于充分利用Spring框架的功能

    2024年02月11日
    浏览(33)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包