Spring5源码解析-Spring框架中的单例和原型bean

发表于   |   分类于   |     |   本站访客数 人次

Spring5源码解析-Spring框架中的单例和原型bean

最近一直有问我单例和原型bean的一些原理性问题，这里就开一篇来说说的

通过Spring中的依赖注入极大方便了我们的开发。在xml通过<bean>定义(或者通过@Bean在配置类里定义)对象之后，然后只需简单地使用@Autowired注解，就可以使用由Spring上下文管理的每个对象。需要注意的是，所有这些对象在Spring中默认都是单例。

这一次我们会去讨论Spring如何来管理这些定义的bean。在第一部分中，我们将讲解单例和原型作用域的概念。第二部分中，我们将分析单例和原型作用域之间的依赖关系。其后说一下方法注入。最后专门对相关Spring的代码来做下分析，具体看看bean是如何构建出来的。

Spring中的bean默认都是单身贵族

Spring使用单例设计模式来管理bean？不完全是。Singleton设计模式假定它们是由Java的类加载器管理的jvm中给定类的唯一一个实例。在Spring中，还是有点不一样。默认情况下，它们为每个给定的org.springframework.context.ApplicationContext实例存在唯一的一个bean (有点别扭，也就是可以有多个Spring容器，每一个容器内存在唯一bean实例，之前的文章中有涉及例子的)。这意味着如果你有两个或更多上下文，所有这些上下文都由同一Java的类加载器管理(因为在同一个jvm环境中)，则可能会有多个给定bean的实例。唯一需要做到的是必须在每个上下文中定义此bean。讲那么多不如代码更有说服力:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
public class MultipleContextes {
 
  public static void main(String[] args) {
    try {
      // retreive two different contexts
      ApplicationContext firstContext = new FileSystemXmlApplicationContext("/home/bartosz/webapp/src/main/resources/META-INF/applicationContext.xml");
      ApplicationContext secondContext = new FileSystemXmlApplicationContext("/home/bartosz/webapp/src/main/resources/META-INF/applicationContext.xml");
 
      // compare the objects from different contexts
      ShoppingCart firstShoppingCart = (ShoppingCart) firstContext.getBean("shoppingCart");
      ShoppingCart secondShoppingCart = (ShoppingCart) secondContext.getBean("shoppingCart");
      System.out.println("1. Are they the same ? " + (firstShoppingCart == secondShoppingCart));
 
      // compare the objects from the same context
      ShoppingCart firstShoppingCartBis = (ShoppingCart) firstContext.getBean("shoppingCart");
      System.out.println("2. Are they the same ? "+ (firstShoppingCart == firstShoppingCartBis));
    } catch (Exception e) {
      e.printStackTrace();
    }
  } 
}

通过执行此代码，你应该得到:

1
2
1. Are they the same ? false
2. Are they the same ? true

所以你可以看到，bean只是一个上下文的单例。这就是为什么你不应该将Spring的单例概念与设计模式中的的单例混合在一起。

但是，如果要为一个定义的bean在一个上下文内可以使用不同的实例，应该怎么做？很简单，你应该将此Bean配置为原型作用域:

1
2
<bean id="shoppingCart" class="com.migo.data.ShoppingCart" scope="prototype">
</bean>

现在，在运行以前的代码之后，你可以看到如下输出:

1
2
1. Are they the same ? false
2. Are they the same ? false

我们已经知道两个作用域之间的区别。但在哪种情况下我们应该选择使用单例还是原型？Singleton适用于无状态的bean，即没有状态的bean。比如一个service，DAO或者controller。他们都没有自己的状态(举个简单的例子，一个函数sin(x)，这个函数本身就是无状态的，所以我们现在喜欢的函数式编程也遵循这个理念)。而是根据传输的参数执行一些操作(作为HTTP请求参数)。另一方面，我们可以通过状态bean管理一些状态。比如购物车bean，假如它是一个单例，那么两个不同消费者购买的产品将被放置在同一个对象上。而如果其中一个消费者想要删除一个产品，另一个消费者就铁定不高兴。这也就是状态类对象应该是原型。

这里说点题外话，不能确定时间的保证，未来会出一个用Java的代码习惯去解析vue的一些东西，内容已经总结完毕，也应用到自己的项目中了，然后得出的一些方法论，为什么在这里去说，就是因为vue也是遵循这个无状态和状态专门管理的原则的，扯远了，接着进行下一部分。

将原型放在单例中，反之亦然

通过上面的描述，很多概念都很清楚了吧，但有时候会发生一些更复杂的情况。第一个是在原型bean中放置单例。显然，如果注入的单例对象真的是一个单例的bean(没有状态)，这个真的没一点问题。想象一下，对于我们的购物车，我们需要注入产品服务。此服务只会检查添加到购物车的产品是否库存。由于服务没有状态，并且会基于在方法签名中所传递的对象进行验证，因此不存在风险。

另一方面，将原型bean放在单例中需要做更多的工作。我们不能在单例bean中通过使用自动注入(比如@Autowired注解)注入原型bean。当Spring初始化所有具有依赖关系的单例bean时，这些注入只会执行一次。这也就意味着在以下代码，ShoppingCart的实例将始终是相同的:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
@Controller
public class TestController {
  @Autowired
  private ShoppingCart shoppingCart;
 
  @RequestMapping(value = "/addProduct/{productName}")
  public String testAdd(@PathVariable(value="productName") String productName) {
    Product product = new Product();
    product.setName(productName);
    this.shoppingCart.addProduct(product);
    LOGGER.debug("ShoppingCart is "+this.shoppingCart);
    return "test";
  }
}

编译此类并进行一些URL调用:http://localhost:8080/addProduct/ice%20tea，http://localhost:8080/addProduct/milk。你将看到如下输出的顺序:

1
2
3
4
// after http://localhost:8080/addProduct/ice%20tea
ShoppingCart is ShoppingCart {products: [Product {ice tea}]}
// after http://localhost:8080/addProduct/milk
ShoppingCart is ShoppingCart {products: [Product {ice tea}, Product {milk}]}

为了在按照我们预想情况下工作(要求不一样的ShoppingCart)，我们可以通过bean工厂手动获取ShoppingCart实例(这样就可以再一次生成一个不一样的ShoppingCart实例了):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
@Controller
public class TestController {
  @Autowired
  private ApplicationContext context;
 
  @RequestMapping(value = "/addProduct/{productName}")
  public String testAdd(@PathVariable(value="productName") String productName) {
    Product product = new Product();
    product.setName(productName);
 
    ShoppingCart shoppingCart = (ShoppingCart) context.getBean("shoppingCart");
    shoppingCart.addProduct(product);
    LOGGER.debug("ShoppingCart is "+shoppingCart);
    return "test";
  }
}

这样，你就可以日志中看到，每次调用都会有新的ShoppingCart实例的生成:

1
2
3
4
// after http://localhost:8080/addProduct/ice%20tea
ShoppingCart is ShoppingCart {products: [Product {ice tea}]}
// after http://localhost:8080/addProduct/milk
ShoppingCart is ShoppingCart {products: [Product {milk}]}

方法注入

有没有别的方法在每次调用都会产生一个新实例？这就是接下来要说的方法注入的技术。它看起来有点像我们的手动去进行bean的查找，但更优雅。一个可以被上下文所感知(访问应用程序上下文可以得到)的bean将负责在单例bean中生成原型bean实例:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
@Service("shoppingCartProvider")
public class ShoppingCartProvider implements ApplicationContextAware {
 
  private ApplicationContext context;
 
  @Override
  public void setApplicationContext(ApplicationContext context) throws BeansException {
    this.context = context;
  }
 
  public ShoppingCart getInstance() {
    return (ShoppingCart) context.getBean("shoppingCart");
  }
 
}

经过上面的修改，controller这里相应修改:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
@Controller
public class TestController {
  @Autowired
  private ShoppingCartProvider shoppingCartProvider;
   
  @RequestMapping(value = "/addProduct/{productName}")
  public String testAdd(@PathVariable(value="productName") String productName) {
    Product product = new Product();
    product.setName(productName);
 
    ShoppingCart shoppingCart = shoppingCartProvider.getInstance();
    shoppingCart.addProduct(product);
    System.out.println("ShoppingCart is "+shoppingCart);
    return "test";
  }
}

也可以在XML配置文件中定义。里面会有一个属性引用原型bean，并允许在每次调用时创建新的实例。它可以很轻松地在一个bean中混合更多东西:

1
2
3
4
5
6
7
 <bean id="shoppingCartProvider" class="com.migo.data.ShoppingCartProvider">
        <lookup-method name="getInstance" bean="shoppingCart">
    	</lookup-method>
</bean> 
  
    <bean id="shoppingCart" class="com.migo.data.ShoppingCart" scope="prototype">
</bean>
1
2
3
public abstract class ShoppingCartProvider   {
  public abstract ShoppingCart getInstance();
}

Controller的代码与实现ApplicationContextAware接口的provider的那个例子是一样的。而区别也仅在于provider的bean定义和实现。该定义包含一个标签查找方法。它指定必须使用哪个方法来获取bean属性中指定的bean的新实例。在我们的这个例子中，我们通过调用ShoppingCartProvider类的getInstance方法来寻找新的ShoppingCart的实例。需要注意的一点，类和方法都可以是抽象的。通过这样做，你可以让Spring生成将实现该方法并返回所需bean的子类。如果这个方法不是抽象的，Spring会重写覆盖它。

Spring中的Bean类

单例的源码实现主要存在于org.springframework.beans和org.springframework.context包中。首先，从Bean包中查看BeanFactory接口。它包含两个我们绝对感兴趣的方法，可用来确定bean是单例还是原型:

  • boolean isSingleton(String name)throws NoSuchBeanDefinitionException
  • boolean isPrototype(String name)throws NoSuchBeanDefinitionException

接下来，我们来深入一下AbstractFactoryBean,从这个类的注释可以知道它是作为“FactoryBean实现的简单模板超类(还是直白翻译下比较好，说默认实现也觉得不靠谱)”。它包含一个用来返回单例或创建原型bean的getObject方法的实现。原型和单例是通过createInstance方法在不同的时间段进行的。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
/**
 * Simple template superclass for {@link FactoryBean} implementations that
 * creates a singleton or a prototype object, depending on a flag.
 *
 * <p>If the "singleton" flag is {@code true} (the default),
 * this class will create the object that it creates exactly once
 * on initialization and subsequently return said singleton instance
 * on all calls to the {@link #getObject()} method.
 *
 * <p>Else, this class will create a new instance every time the
 * {@link #getObject()} method is invoked. Subclasses are responsible
 * for implementing the abstract {@link #createInstance()} template
 * method to actually create the object(s) to expose.
 *
 * @author Juergen Hoeller
 * @author Keith Donald
 * @since 1.0.2
 * @see #setSingleton
 * @see #createInstance()
 */
public abstract class AbstractFactoryBean<T>
		implements FactoryBean<T>, BeanClassLoaderAware, BeanFactoryAware, InitializingBean, DisposableBean {
	/**
	 * Expose the singleton instance or create a new prototype instance.
	 * @see #createInstance()
	 * @see #getEarlySingletonInterfaces()
	 */
	@Override
	public final T getObject() throws Exception {
		if (isSingleton()) {
			return (this.initialized ? this.singletonInstance : getEarlySingletonInstance());
		}
		else {
			return createInstance();
		}
	}
		...
	/**
	 * Template method that subclasses must override to construct
	 * the object returned by this factory.
	 * <p>Invoked on initialization of this FactoryBean in case of
	 * a singleton; else, on each {@link #getObject()} call.
	 * @return the object returned by this factory
	 * @throws Exception if an exception occurred during object creation
	 * @see #getObject()
	 */
	protected abstract T createInstance() throws Exception;
	...
	}

另一个我们会感兴趣的一个点是BeanDefinition接口。bean如其名，它定义了一个bean属性，例如:scope，class name，factory method name，properties或constructor arguments。

org.springframework.beans.factory.config.BeanDefinition

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
/**
 * A BeanDefinition describes a bean instance, which has property values,
 * constructor argument values, and further information supplied by
 * concrete implementations.
 *
 * <p>This is just a minimal interface: The main intention is to allow a
 * {@link BeanFactoryPostProcessor} such as {@link PropertyPlaceholderConfigurer}
 * to introspect and modify property values and other bean metadata.
 *
 * @author Juergen Hoeller
 * @author Rob Harrop
 * @since 19.03.2004
 * @see ConfigurableListableBeanFactory#getBeanDefinition
 * @see org.springframework.beans.factory.support.RootBeanDefinition
 * @see org.springframework.beans.factory.support.ChildBeanDefinition
 */
public interface BeanDefinition extends AttributeAccessor, BeanMetadataElement {
  //限于篇幅，请自行查看源码，能发现很多有用的东西
}

想要看到bean被初始化的位置，我们需要跳转到context包中，更准确地说就是在AbstractApplicationContext类(这个类我们已经接触过好多次了)中。在它的public void refresh()throws BeansException，IllegalStateException我们可以找到一些关于bean创建的片段，特别是:

  • protected void invokeBeanFactoryPostProcessors(ConfigurableListableBeanFactory beanFactory):实现org.springframework.beans.factory.config .BeanFactoryPostProcessor接口的所有bean 都被初始化和调用。这种类型bean允许修改另一个bean的属性或构造函数参数(请看PostProcessorRegistrationDelegate的相应代码可以知道，使用BeanFactoryPostProcessor来处理我们所要用beanFactory生成的bean，这里可以直接把beanFactory看成是我们需要的bean即可)。但是请注意，在此阶段只能修改bean定义。“正常”bean实例尚未创建。关于这块会请参考文章Spring中的bean工厂后置处理器。 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
/**
	 * Instantiate and invoke all registered BeanFactoryPostProcessor beans,
	 * respecting explicit order if given.
	 * <p>Must be called before singleton instantiation.
	 */
	protected void invokeBeanFactoryPostProcessors(ConfigurableListableBeanFactory beanFactory) {
		PostProcessorRegistrationDelegate.invokeBeanFactoryPostProcessors(beanFactory, getBeanFactoryPostProcessors());

		// Detect a LoadTimeWeaver and prepare for weaving, if found in the meantime
		// (e.g. through an @Bean method registered by ConfigurationClassPostProcessor)
		if (beanFactory.getTempClassLoader() == null && beanFactory.containsBean(LOAD_TIME_WEAVER_BEAN_NAME)) {
			beanFactory.addBeanPostProcessor(new LoadTimeWeaverAwareProcessor(beanFactory));
			beanFactory.setTempClassLoader(new ContextTypeMatchClassLoader(beanFactory.getBeanClassLoader()));
		}
	}

org.springframework.context.support.PostProcessorRegistrationDelegate

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
/**
 * Delegate for AbstractApplicationContext's post-processor handling.
 *
 * @author Juergen Hoeller
 * @since 4.0
 */
class PostProcessorRegistrationDelegate {

	public static void invokeBeanFactoryPostProcessors(
			ConfigurableListableBeanFactory beanFactory, List<BeanFactoryPostProcessor> beanFactoryPostProcessors) {

		// Invoke BeanDefinitionRegistryPostProcessors first, if any.
		Set<String> processedBeans = new HashSet<>();

		if (beanFactory instanceof BeanDefinitionRegistry) {
			BeanDefinitionRegistry registry = (BeanDefinitionRegistry) beanFactory;
			List<BeanFactoryPostProcessor> regularPostProcessors = new LinkedList<>();
			List<BeanDefinitionRegistryPostProcessor> registryPostProcessors =
					new LinkedList<>();

			for (BeanFactoryPostProcessor postProcessor : beanFactoryPostProcessors) {
				if (postProcessor instanceof BeanDefinitionRegistryPostProcessor) {
					BeanDefinitionRegistryPostProcessor registryPostProcessor =
							(BeanDefinitionRegistryPostProcessor) postProcessor;
					registryPostProcessor.postProcessBeanDefinitionRegistry(registry);
					registryPostProcessors.add(registryPostProcessor);
				}
				else {
					regularPostProcessors.add(postProcessor);
				}
			}
...
        }
  • protected void registerBeanPostProcessors(ConfigurableListableBeanFactory beanFactory):这里上下文实例化并调用实现了org.springframework.beans.factory.config.BeanPostProcessor接口的所有bean 。实现此接口的bean包含可以在其他bean初始化之前或之后调用的回调。因为内容比较多，关于这块会请参考文章Spring中的bean工厂后置处理器。 
1
2
3
4
5
6
7
8
/**
	 * Instantiate and invoke all registered BeanPostProcessor beans,
	 * respecting explicit order if given.
	 * <p>Must be called before any instantiation of application beans.
	 */
	protected void registerBeanPostProcessors(ConfigurableListableBeanFactory beanFactory) {
		PostProcessorRegistrationDelegate.registerBeanPostProcessors(beanFactory, this);
	}
  • protected void finishBeanFactoryInitialization(ConfigurableListableBeanFactory beanFactory):主要调用定义在org.springframework.beans.factory.config.ConfigurableListableBeanFactory接口内的preInstantiateSingletons方法。该方法的目的是实例化所有被定义为非延迟加载的bean。如果在应用程序上下文加载时遇到BeansException异常，则可能来自此方法。当bean无法创建时，它会抛出BeansException异常。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
/**
	 * Finish the initialization of this context's bean factory,
	 * initializing all remaining singleton beans.
	 */
	protected void finishBeanFactoryInitialization(ConfigurableListableBeanFactory beanFactory) {
		// Initialize conversion service for this context.
		if (beanFactory.containsBean(CONVERSION_SERVICE_BEAN_NAME) &&
				beanFactory.isTypeMatch(CONVERSION_SERVICE_BEAN_NAME, ConversionService.class)) {
			beanFactory.setConversionService(
					beanFactory.getBean(CONVERSION_SERVICE_BEAN_NAME, ConversionService.class));
		}

		// Register a default embedded value resolver if no bean post-processor
		// (such as a PropertyPlaceholderConfigurer bean) registered any before:
		// at this point, primarily for resolution in annotation attribute values.
		if (!beanFactory.hasEmbeddedValueResolver()) {
			beanFactory.addEmbeddedValueResolver(strVal -> getEnvironment().resolvePlaceholders(strVal));
		}

		// Initialize LoadTimeWeaverAware beans early to allow for registering their transformers early.
		String[] weaverAwareNames = beanFactory.getBeanNamesForType(LoadTimeWeaverAware.class, false, false);
		for (String weaverAwareName : weaverAwareNames) {
			getBean(weaverAwareName);
		}

		// Stop using the temporary ClassLoader for type matching.
		beanFactory.setTempClassLoader(null);

		// Allow for caching all bean definition metadata, not expecting further changes.
		beanFactory.freezeConfiguration();

		// Instantiate all remaining (non-lazy-init) singletons.
		beanFactory.preInstantiateSingletons();
	}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
@Override
	public void refresh() throws BeansException, IllegalStateException {
		synchronized (this.startupShutdownMonitor) {
			// Prepare this context for refreshing.
			prepareRefresh();

			// Tell the subclass to refresh the internal bean factory.
			ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory();

			// Prepare the bean factory for use in this context.
			prepareBeanFactory(beanFactory);

			try {
				// Allows post-processing of the bean factory in context subclasses.
				postProcessBeanFactory(beanFactory);

				// Invoke factory processors registered as beans in the context.
				invokeBeanFactoryPostProcessors(beanFactory);

				// Register bean processors that intercept bean creation.
				registerBeanPostProcessors(beanFactory);

				// Initialize message source for this context.
				initMessageSource();

				// Initialize event multicaster for this context.
				initApplicationEventMulticaster();

				// Initialize other special beans in specific context subclasses.
				onRefresh();

				// Check for listener beans and register them.
				registerListeners();

				// Instantiate all remaining (non-lazy-init) singletons.
				finishBeanFactoryInitialization(beanFactory);

				// Last step: publish corresponding event.
				finishRefresh();
			}

			catch (BeansException ex) {
				if (logger.isWarnEnabled()) {
					logger.warn("Exception encountered during context initialization - " +
							"cancelling refresh attempt: " + ex);
				}

				// Destroy already created singletons to avoid dangling resources.
				destroyBeans();

				// Reset 'active' flag.
				cancelRefresh(ex);

				// Propagate exception to caller.
				throw ex;
			}

			finally {
				// Reset common introspection caches in Spring's core, since we
				// might not ever need metadata for singleton beans anymore...
				resetCommonCaches();
			}
		}
	}

总结

首先，我们讲了单例和原型作用域之间的区别。第一个为每个容器创建一个对象，而第二个在每个请求时创建一个新的bean对象。单例和原型都可以一起交叉使用，但原型不能通过@Autowired或其他注入方式来解决。它们应该使用getBean()方法或方法查找来生成新实例。最后随意说了一说关于bean及其初始化的内容。

您的支持将鼓励我继续创作！