深入理解Spring依赖注入
什么是依赖注入?
依赖注入是一种设计模式,用于管理对象之间的依赖关系。在传统的编程模式中,一个对象通常负责创建和管理其所依赖的其他对象。而在依赖注入中,这种控制权被反转了。对象不再负责创建和管理其依赖的对象,而是通过外部机制将依赖对象注入到目标对象中。
Spring框架中的依赖注入
Spring框架是一个开源的Java应用程序开发框架,提供了广泛的功能和特性,其中之一就是依赖注入。Spring框架通过依赖注入来管理应用程序中的对象之间的依赖关系。
在Spring框架中,依赖注入的实现方式有多种,包括构造函数注入、Setter方法注入和字段注入。
构造函数注入(Constructor Injection):通过构造函数将依赖对象作为参数传递给目标对象。这种方式要求目标对象在创建时必须提供其依赖的对象。Spring框架会负责解析依赖关系并自动将依赖对象传递给目标对象的构造函数。构造函数注入可以不添加任何额外的注解,所以对代码侵入性是最小的,这也是Spring官方推荐的用法。
@Service public class AService { public void test() { System.out.println("AService test"); } } @Service public class BService { private final AService aService; public BService(AService aService) { this.aService = aService; } @PostConstruct public void init() { aService.test(); } }Setter方法注入(Setter Injection):通过Setter方法将依赖对象注入到目标对象中。目标对象提供一组Setter方法,用于设置其依赖的对象。Spring框架会在创建目标对象后,自动调用Setter方法并将依赖对象传递给它们。
@Service public class BService { private AService aService; @PostConstruct public void init() { aService.test(); } @Autowired public void setaService(AService aService) { this.aService = aService; } }字段注入(Field Injection):通过直接注入到目标对象的字段中来实现依赖注入。目标对象的字段上使用注解或配置来标识依赖关系,Spring框架会在创建目标对象后,自动将依赖对象赋值给这些字段。
@Service public class BService { @Autowired private AService aService; @PostConstruct public void init() { aService.test(); } }
Spring依赖注入的实现方式
在Spring框架中,实现依赖对象的注入是通过容器管理的。Spring容器负责创建、配置和管理应用程序中的对象,并在需要时将依赖对象注入到目标对象中。
Spring框架中实现依赖对象注入的具体步骤:
声明依赖对象:首先,需要先在Spring配置文件(如XML配置文件或Java配置类)中定义依赖对象。这可以通过使用Spring提供的特定标签(如
<bean>标签)或注解来完成。在配置中,您可以指定依赖对象的类名、构造函数参数、属性值等信息。创建Spring容器:接下来,需要创建一个Spring容器。Spring提供了不同类型的容器实现,如ApplicationContext和BeanFactory。可以根据需要选择适合的容器类型。容器负责解析配置文件并创建、初始化和管理对象。
注入依赖对象:当容器创建目标对象时,它会检查目标对象的依赖注入点(如构造函数、Setter方法或字段)。然后,容器会查找对应的依赖对象,并将其注入到目标对象中。
使用注入的依赖对象:一旦依赖对象被成功注入到目标对象中,就可以在目标对象的方法中使用这些依赖对象了。Spring容器会确保依赖对象的生命周期和目标对象的生命周期一致,以及正确地管理它们之间的关系。
以SpringBoot的web项目为例(不考虑XML配置的Bean),项目的启动入口一般会出现如下代码:
@SpringBootApplication
public class Application {
public static void main(String[] args) {
SpringApplication.run(Application.class, args);
}
}其中@SpringBootApplication注解相当于同时使用了@SpringBootConfiguration、@EnableAutoConfiguration和@ComponentScan这三个注解,@ComponentScan的包扫描路径就是启动类下的路径。
声明了@ComponentScan的包扫描路径后,Spring就会扫描包路径下所有带有@Component注解的类(@Configuration、@Service、@Controller、@Repository等注解都继承了@Component注解)。具体实现的代码在ConfigurationClassPostProcessor这个后置处理器中,通过调用ClassPathBeanDefinitionScanner的doScan(String... basePackages) 方法来进行注解的扫描与解析,我们先知道这个概念,后续我会在其他博文中详细进行介绍,在这里不再继续深入探究。
public class ClassPathBeanDefinitionScanner extends ClassPathScanningCandidateComponentProvider {
protected Set<BeanDefinitionHolder> doScan(String... basePackages) {
Assert.notEmpty(basePackages, "At least one base package must be specified");
Set<BeanDefinitionHolder> beanDefinitions = new LinkedHashSet<>();
for (String basePackage : basePackages) {
Set<BeanDefinition> candidates = findCandidateComponents(basePackage);
for (BeanDefinition candidate : candidates) {
ScopeMetadata scopeMetadata = this.scopeMetadataResolver.resolveScopeMetadata(candidate);
candidate.setScope(scopeMetadata.getScopeName());
String beanName = this.beanNameGenerator.generateBeanName(candidate, this.registry);
if (candidate instanceof AbstractBeanDefinition) {
postProcessBeanDefinition((AbstractBeanDefinition) candidate, beanName);
}
if (candidate instanceof AnnotatedBeanDefinition) {
AnnotationConfigUtils.processCommonDefinitionAnnotations((AnnotatedBeanDefinition) candidate);
}
if (checkCandidate(beanName, candidate)) {
BeanDefinitionHolder definitionHolder = new BeanDefinitionHolder(candidate, beanName);
definitionHolder =
AnnotationConfigUtils.applyScopedProxyMode(scopeMetadata, definitionHolder, this.registry);
beanDefinitions.add(definitionHolder);
registerBeanDefinition(definitionHolder, this.registry);
}
}
}
return beanDefinitions;
}
}SpringApplication.run(Class<?> primarySource, String... args)方法中,会创建一个ApplicationContext,并执行refresh()方法刷新容器:
public abstract class AbstractApplicationContext extends DefaultResourceLoader
implements ConfigurableApplicationContext {
@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都是在finishBeanFactoryInitialization(beanFactory)这一阶段创建并完成依赖注入的(扫描注解是在invokeBeanFactoryPostProcessors(beanFactory)这一步完成的,后置处理器执行完成后,会将所有扫描到的类注册成BeanDefinition),这里我们只看关键步骤:
遍历所有BeanDefinition,依次执行getBean(beanName)方法创建Bean
public class DefaultListableBeanFactory extends AbstractAutowireCapableBeanFactory implements ConfigurableListableBeanFactory, BeanDefinitionRegistry, Serializable { @Override public void preInstantiateSingletons() throws BeansException { if (logger.isTraceEnabled()) { logger.trace("Pre-instantiating singletons in " + this); } // Iterate over a copy to allow for init methods which in turn register new bean definitions. // While this may not be part of the regular factory bootstrap, it does otherwise work fine. List<String> beanNames = new ArrayList<>(this.beanDefinitionNames); // Trigger initialization of all non-lazy singleton beans... for (String beanName : beanNames) { RootBeanDefinition bd = getMergedLocalBeanDefinition(beanName); if (!bd.isAbstract() && bd.isSingleton() && !bd.isLazyInit()) { if (isFactoryBean(beanName)) { Object bean = getBean(FACTORY_BEAN_PREFIX + beanName); if (bean instanceof FactoryBean) { FactoryBean<?> factory = (FactoryBean<?>) bean; boolean isEagerInit; if (System.getSecurityManager() != null && factory instanceof SmartFactoryBean) { isEagerInit = AccessController.doPrivileged( (PrivilegedAction<Boolean>) ((SmartFactoryBean<?>) factory)::isEagerInit, getAccessControlContext()); } else { isEagerInit = (factory instanceof SmartFactoryBean && ((SmartFactoryBean<?>) factory).isEagerInit()); } if (isEagerInit) { getBean(beanName); } } } else { getBean(beanName); } } } …… } }实例化Bean,主要是通过反射创建对象,如果Bean的构造函数存在参数,还会完成构造参数Bean的自动注入
protected Object doCreateBean(String beanName, RootBeanDefinition mbd, @Nullable Object[] args) throws BeanCreationException { // Instantiate the bean. BeanWrapper instanceWrapper = null; if (mbd.isSingleton()) { instanceWrapper = this.factoryBeanInstanceCache.remove(beanName); } if (instanceWrapper == null) { instanceWrapper = createBeanInstance(beanName, mbd, args); } Object bean = instanceWrapper.getWrappedInstance(); …… }对Bean的属性进行赋值,此处会完成Setter方式和字段方式的Bean的自动注入
初始化Bean,可以看到初始化是在属性填充之后进行的。在Bean的属性填充过程中,如果发现存在对其他Bean的依赖,会先完成依赖Bean的创建、属性填充、初始化等过程。只有当依赖的所有Bean都全部成功创建后,才会继续当前Bean的初始化工作,所以初始化流程里可以放心大胆的使用依赖的Bean完成业务逻辑
protected Object doCreateBean(String beanName, RootBeanDefinition mbd, @Nullable Object[] args) throws BeanCreationException { …… // Initialize the bean instance. Object exposedObject = bean; try { populateBean(beanName, mbd, instanceWrapper); exposedObject = initializeBean(beanName, exposedObject, mbd); } catch (Throwable ex) { if (ex instanceof BeanCreationException && beanName.equals(((BeanCreationException) ex).getBeanName())) { throw (BeanCreationException) ex; } else { throw new BeanCreationException( mbd.getResourceDescription(), beanName, "Initialization of bean failed", ex); } } …… return exposedObject; }
循环依赖问题与解决方式
循环依赖指的是两个或多个Bean之间相互依赖,形成一个闭环的情况。例如,Bean A依赖于Bean B,同时Bean B也依赖于Bean A。这种情况下,如果不采取措施,就无法正确地创建这些Bean。Spring使用了一种特殊的机制来解决这个问题,该机制称为"循环依赖解析"(Circular Dependency Resolution)。
下面是Spring框架解决循环依赖的基本步骤:
创建Bean的实例:当Spring容器创建Bean时,它会首先实例化Bean,但不会完成依赖注入。
提前暴露Bean的引用:在实例化Bean之后,Spring容器会提前暴露一个尚未完成依赖注入的Bean引用。
解析循环依赖:当存在循环依赖时,Spring容器会尝试解析循环依赖。它会检查已经创建的Bean实例中是否存在循环依赖的情况。
使用提前暴露的引用:如果存在循环依赖,Spring会先从缓存中查找是否存在提前暴露的Bean引用,如果存在则将其暴露给其他Bean进行引用。
完成依赖注入:其他Bean获取提前暴露的引用完成后,Spring容器会继续完成当前Bean依赖注入的过程,以满足Bean之间的循环依赖关系。
需要注意的是,Spring的循环依赖解析机制是基于Bean的单例模式。默认情况下,Spring容器中的Bean都是单例的,即每个Bean只有一个实例。如果Bean的作用域不是单例(如原型作用域),则Spring无法解决循环依赖。此外,可以看到Spring是通过先实例化对象,将对象引用提前暴露给其他的Bean,再完成Bean的属性填充来解决Bean之间的循环依赖,所以构造函数循环依赖是无法解决的。此时,需要重新设计和优化的Bean依赖关系。
protected Object doCreateBean(String beanName, RootBeanDefinition mbd, @Nullable Object[] args)
throws BeanCreationException {
……
if (earlySingletonExposure) {
Object earlySingletonReference = getSingleton(beanName, false);
if (earlySingletonReference != null) {
if (exposedObject == bean) {
exposedObject = earlySingletonReference;
}
else if (!this.allowRawInjectionDespiteWrapping && hasDependentBean(beanName)) {
String[] dependentBeans = getDependentBeans(beanName);
Set<String> actualDependentBeans = new LinkedHashSet<>(dependentBeans.length);
for (String dependentBean : dependentBeans) {
if (!removeSingletonIfCreatedForTypeCheckOnly(dependentBean)) {
actualDependentBeans.add(dependentBean);
}
}
if (!actualDependentBeans.isEmpty()) {
throw new BeanCurrentlyInCreationException(beanName,
"Bean with name '" + beanName + "' has been injected into other beans [" +
StringUtils.collectionToCommaDelimitedString(actualDependentBeans) +
"] in its raw version as part of a circular reference, but has eventually been " +
"wrapped. This means that said other beans do not use the final version of the " +
"bean. This is often the result of over-eager type matching - consider using " +
"'getBeanNamesForType' with the 'allowEagerInit' flag turned off, for example.");
}
}
}
}
……
return exposedObject;
}存在代理的对象之间的循环依赖
当存在循环依赖的Bean存在AOP切面、@Transactional事务注解、@Async声明的异步执行方法等,Spring最终放到容器中的Bean实际是一个代理对象。在这种情况下,Spring是否也可以完成存循环依赖关系的Bean的注入呢?
通过AOP切面、@Transactional事务注解来形成的代理对象之间是可以成功进行循环依赖的,但是通过@Async注解形成的代理对象之间存在循环依赖,Spring容器刷新时就会报错,报错内容如下:
Error creating bean with name 'AService': Bean with name 'AService' has been injected into other beans [BService] in its raw version as part of a circular reference, but has eventually been wrapped. This means that said other beans do not use the final version of the bean. This is often the result of over-eager type matching - consider using 'getBeanNamesForType' with the 'allowEagerInit' flag turned off, for example.
@EnableAsync
@SpringBootApplication
public class Application {
public static void main(String[] args) {
SpringApplication.run(Application.class, args);
}
}
@Service
public class AService {
@Autowired
BService bService;
@Async
public void test() {
bService.test();
}
}
@Service
public class BService {
@Autowired
AService aService;
public void test() {
System.out.println("BService test");
}
}
但当我们将@Async注解换到BService中的test()方法上,发现又可以成功完成Spring容器的刷新,这是为什么呢?
@Service
public class AService {
@Autowired
BService bService;
public void test() {
bService.test();
}
}
@Service
public class BService {
@Autowired
AService aService;
@Async
public void test() {
System.out.println("BService test");
}
}这就不得不说,Spring为Bean创建代理是在其初始化方法执行完成后,通过调用BeanPostProcessor的postProcessAfterInitialization(bean, beanName)方法来生成代理对象的。
public abstract class AbstractAutowireCapableBeanFactory extends AbstractBeanFactory
implements AutowireCapableBeanFactory {
@Override
public Object applyBeanPostProcessorsAfterInitialization(Object existingBean, String beanName)
throws BeansException {
Object result = existingBean;
for (BeanPostProcessor processor : getBeanPostProcessors()) {
Object current = processor.postProcessAfterInitialization(result, beanName);
if (current == null) {
return result;
}
result = current;
}
return result;
}
}通过上面介绍我们知道依赖注入是在Bean的初始化方法之前调用的,存在循环引用的依赖注入会使用提前暴露的引用,注意这里提前暴露的引用是原始对象的引用,而不是代理对象的引用,这就会导致提前暴露的引用不是最终放入到Spring容器中的对象。Spring当然不会允许这种情况发生,会在刷新容器时直接报错,并提示上述的错误信息。
所以理论上来说,需要创建代理的Bean之间存在循环引用,Spring就无法正常完成容器的刷新。但实际上通过AOP切面和@Transactional事务注解来形成的代理对象之间存在循环引用,也可以成功完成容器的刷新,Spring是如何解决这一问题的呢?
三级缓存解决代理的对象循环依赖
Spring框架使用了三级缓存(三级Map)来解决循环依赖:
第一级缓存(singletonObjects):这个缓存用于存储已经完全初始化的Bean实例。当Spring容器创建Bean时,如果Bean已经在第一级缓存中存在,它会直接从缓存中获取并返回该实例。
第二级缓存(earlySingletonObjects):这个缓存用于存储已经实例化但尚未完成依赖注入的Bean实例。当Spring容器创建Bean时,如果Bean在第一级缓存中不存在,它会尝试从第二级缓存中获取。如果Bean在第二级缓存中存在,它会返回这个实例,并提前暴露一个未完成依赖注入的引用。
第三级缓存(singletonFactories):这个缓存用于存储Bean的创建工厂(ObjectFactory)。当Spring容器创建Bean时,如果Bean既不在第一级缓存中,也不在第二级缓存中,它会尝试从第三级缓存中获取。如果Bean的创建工厂在第三级缓存中存在,它会使用工厂创建Bean的实例,并将实例放入第二级缓存中。
// 一级缓存 private final Map<String, ObjectFactory<?>> singletonFactories = new HashMap<>(16); // 二级缓存 private final Map<String, Object> earlySingletonObjects = new HashMap<>(16); // 三级缓存 private final Map<String, ObjectFactory<?>> singletonFactories = new HashMap<>(16); protected Object getSingleton(String beanName, boolean allowEarlyReference) { Object singletonObject = this.singletonObjects.get(beanName); if (singletonObject == null && isSingletonCurrentlyInCreation(beanName)) { synchronized (this.singletonObjects) { singletonObject = this.earlySingletonObjects.get(beanName); if (singletonObject == null && allowEarlyReference) { ObjectFactory<?> singletonFactory = this.singletonFactories.get(beanName); if (singletonFactory != null) { singletonObject = singletonFactory.getObject(); this.earlySingletonObjects.put(beanName, singletonObject); this.singletonFactories.remove(beanName); } } } } return singletonObject; }
在创建Bean的过程中,如果发现项目允许循环依赖(SpringBoot3.0之前默认是开启的,3.0版本之后默认是关闭的),就会先向三级缓存中通过lambda表示放入一个匿名工厂对象,这里就是解决存在代理的Bean对象之间循环依赖的关键步骤
protected Object doCreateBean(String beanName, RootBeanDefinition mbd, @Nullable Object[] args)
throws BeanCreationException {
……
// Eagerly cache singletons to be able to resolve circular references
// even when triggered by lifecycle interfaces like BeanFactoryAware.
boolean earlySingletonExposure = (mbd.isSingleton() && this.allowCircularReferences &&
isSingletonCurrentlyInCreation(beanName));
if (earlySingletonExposure) {
if (logger.isTraceEnabled()) {
logger.trace("Eagerly caching bean '" + beanName +
"' to allow for resolving potential circular references");
}
addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean));
}
……
return exposedObject;
}
// 添加三级缓存
protected void addSingletonFactory(String beanName, ObjectFactory<?> singletonFactory) {
Assert.notNull(singletonFactory, "Singleton factory must not be null");
synchronized (this.singletonObjects) {
if (!this.singletonObjects.containsKey(beanName)) {
this.singletonFactories.put(beanName, singletonFactory);
this.earlySingletonObjects.remove(beanName);
this.registeredSingletons.add(beanName);
}
}
}我们查看getEarlyBeanReference(beanName, mbd, bean)方法,发现调用了SmartInstantiationAwareBeanPostProcessor的getEarlyBeanReference(exposedObject, beanName)方法,在这里就可以实现偷天换日,将Bean提前暴露出去的引用替换为代理对象。
protected Object getEarlyBeanReference(String beanName, RootBeanDefinition mbd, Object bean) {
Object exposedObject = bean;
if (!mbd.isSynthetic() && hasInstantiationAwareBeanPostProcessors()) {
for (BeanPostProcessor bp : getBeanPostProcessors()) {
if (bp instanceof SmartInstantiationAwareBeanPostProcessor) {
SmartInstantiationAwareBeanPostProcessor ibp = (SmartInstantiationAwareBeanPostProcessor) bp;
exposedObject = ibp.getEarlyBeanReference(exposedObject, beanName);
}
}
}
return exposedObject;
}如果在此处最终返回的对象和原始对象不一样,就会将最终放入Spring容器中的对象exposedObject替换为该对象,这样就保证了提前暴露的引用对象和最终放入Spring容器的对象时同一个对象。
if (earlySingletonExposure) {
Object earlySingletonReference = getSingleton(beanName, false);
if (earlySingletonReference != null) {
if (exposedObject == bean) {
exposedObject = earlySingletonReference;
}
……
}
}看到这里,就可以知道通过AOP切面@Transactional事务注解来形成的代理对象的BeanPostProcessor一定继承了SmartInstantiationAwareBeanPostProcessor这个接口,而@Async声明的异步执行方法来创建代理对象的BeanPostProcessor没有继承这个接口,从而导致Spring容器无法成功完成刷新。
AOP切面是通过AnnotationAwareAspectJAutoProxyCreator完成代理对象的创建
@Transactional事务注解是通过InfrastructureAdvisorAutoProxyCreator完成代理对象的创建
@Async声明的异步执行方法是通过AsyncAnnotationBeanPostProcessor完成代理对象的创建
可以看到,确实通过AOP切面@Transactional事务注解来形成的代理对象的BeanPostProcessor都继承了SmartInstantiationAwareBeanPostProcessor接口,而@Async声明的异步执行方法来创建代理对象的BeanPostProcessor没有继承这个接口。所以会出现前面两种代理Bean之间存在循环引用可以正常注入,而后者一旦存在循环依赖,Spring容器就无法正常启动。
那么了解了Spring解决存在代理对的Bean质检的循环依赖方式后,我们就可以解决@Async声明的异步执行方法来创建代理对象的Bean之间的循环依赖问题。我们不使用Spring提供的@EnableAsync注解来开启异步支持,而是自己实现一个Configuration来手动声明AsyncAnnotationBeanPostProcessor。
@Configuration
@Role(BeanDefinition.ROLE_INFRASTRUCTURE)
public class ProxyAsyncConfiguration extends AbstractAsyncConfiguration {
@Override
public void setImportMetadata(AnnotationMetadata importMetadata) {
// @EnableAsync is not used
}
@Bean(name = TaskManagementConfigUtils.ASYNC_ANNOTATION_PROCESSOR_BEAN_NAME)
@Role(BeanDefinition.ROLE_INFRASTRUCTURE)
public AsyncAnnotationBeanPostProcessor asyncAdvisor() {
AsyncAnnotationBeanPostProcessor bpp = new CircleSupportAsyncAnnotationBeanPostProcessor();
bpp.configure(this.executor, this.exceptionHandler);
bpp.setProxyTargetClass(false);
bpp.setOrder(Ordered.LOWEST_PRECEDENCE);
return bpp;
}
}
// 继承SmartInstantiationAwareBeanPostProcessor接口, 并重写getEarlyBeanReference(bean, beanName)方法
public class CircleSupportAsyncAnnotationBeanPostProcessor extends AsyncAnnotationBeanPostProcessor
implements SmartInstantiationAwareBeanPostProcessor {
private final Map<Object, Object> earlyProxyReferences = new ConcurrentHashMap<>(16);
@Override
public Object getEarlyBeanReference(Object bean, String beanName) throws BeansException {
this.earlyProxyReferences.put(beanName, bean);
return super.postProcessAfterInitialization(bean, beanName);
}
// 初始化方法后回调方法, 就不要再重复创建代理对象了, 直接返回原始对象
@Override
public Object postProcessAfterInitialization(Object bean, String beanName) {
if (bean != null) {
if (this.earlyProxyReferences.remove(beanName) != bean) {
return super.postProcessAfterInitialization(bean, beanName);
}
}
return bean;
}
}通过这种方式再运行上面容器启动失败的代码,就可以成功启动Spring容器了。