1. 项目概述为什么我们需要深入Spring的“进阶篇”如果你已经用Spring Boot写过几个增删改查的项目觉得注解一加、依赖一配就能跑起来感觉Spring不过如此那这篇文章就是为你准备的。我见过太多开发者停留在“会用”的层面面试时被问到“Spring三级缓存原理”、“事务传播机制在嵌套方法中如何生效”就支支吾吾。这就像开车只会踩油门和刹车一旦遇到复杂路况或者车子抛锚就完全束手无策。Spring框架的优雅和强大恰恰隐藏在那些看似自动化的“魔法”背后。理解这些机制不仅能让你写出更健壮、高效的代码更能让你在排查诸如循环依赖导致启动失败、事务意外回滚、AOP拦截失效等诡异问题时拥有清晰的思路和底气。“进阶”并不意味着要去阅读Spring Framework那浩如烟海的源码虽然读源码是终极途径而是要把核心的运行原理、设计思想内化成自己的知识体系。本篇作为进阶系列的开篇我们将聚焦于Spring容器的核心——IoC容器深入其初始化过程、Bean的生命周期管理以及解决循环依赖的著名“三级缓存”机制。我们会绕过简单的概念复述直接切入实际开发中高频出现的场景和问题用“为什么”和“怎么办”串联起所有知识点。无论你是准备应对深度技术面试还是希望提升项目架构能力这里的讨论都将提供实实在在的助力。2. IoC容器初始化深度解析不止是ApplicationContext当我们启动一个Spring Boot应用SpringApplication.run()这一行代码背后容器究竟经历了什么很多人只知道结果Bean被创建了依赖被注入了。但这个过程里的关键抉择和潜在陷阱才是进阶路上必须清楚的。2.1BeanFactory与ApplicationContext的选用逻辑Spring提供了两种核心容器接口BeanFactory和ApplicationContext。ApplicationContext是BeanFactory的子接口意味着它拥有全部Bean工厂的能力并增加了更多企业级功能。为什么我们几乎总是使用ApplicationContext而非更基础的BeanFactory功能增强ApplicationContext在BeanFactory单纯管理Bean的基础上整合了消息资源处理国际化、事件发布、应用层特定的上下文如WebApplicationContext等功能。这些是现代应用开发的基础设施。Bean的预实例化这是关键区别之一。默认情况下BeanFactory延迟初始化所有单例Bean即用到时才创建而ApplicationContext在容器启动时就会初始化所有非延迟加载的单例Bean。这会导致启动时间变长但能尽早暴露配置错误和依赖问题符合大多数生产环境对稳定性的要求。如果你的应用有大量Bean且启动速度至关重要可以仔细规划Lazy注解的使用但需要警惕延迟初始化可能带来的运行时首次请求性能波动和循环依赖解析问题。注意在Spring Boot中通过SpringBootApplication注解引导的正是AnnotationConfigApplicationContext或针对Web的AnnotationConfigServletWebServerApplicationContext。它的初始化过程是理解后续所有机制的基础。2.2 容器启动的关键步骤与源码线索容器的初始化可以简化为几个核心阶段理解它们有助于定位启动期问题加载与解析配置容器读取配置源XML、Java Config、注解扫描的包路径将其转化为内部的BeanDefinition对象。BeanDefinition是Bean的“配方”或“蓝图”包含了类名、作用域、初始化方法、属性值等元数据但此时尚未创建真正的Java对象。BeanDefinition的注册与后处理将解析得到的BeanDefinition注册到BeanFactory的beanDefinitionMap中。随后BeanFactoryPostProcessor接口的实现类开始工作。这是容器提供的第一个强大的扩展点。例如PropertySourcesPlaceholderConfigurer或Spring Boot中的PropertySource就是在此阶段运行将${}占位符替换为具体的属性值。你可以自定义BeanFactoryPostProcessor来动态修改BeanDefinition比如根据环境变量调整Bean的类名。Bean实例化与依赖注入对于非延迟加载的单例Bean容器开始实例化。它根据BeanDefinition提供的信息通过反射调用构造函数创建对象实例化。然后进行依赖注入填充属性处理Autowired、Resource等注解。Bean的生命周期回调在依赖注入之后如果Bean实现了InitializingBean接口会调用其afterPropertiesSet()方法如果配置了init-method或使用了PostConstruct注解相应的方法也会被执行。至此一个完全可用的Bean就准备就绪了。容器刷新完成当所有单例Bean初始化完毕容器会触发上下文刷新完成事件应用正式进入可服务状态。实操心得很多启动时爆出的BeanCreationException根源都在前两步。例如BeanDefinitionStoreException可能是配置解析错误如XML语法错误BeanDefinitionOverrideExceptionSpring Boot 2.1默认禁止覆盖则是重复定义了同名的Bean。学会查看异常堆栈定位到是哪个阶段出了问题能极大提升排查效率。3. Bean的生命周期全景图不只是创建和销毁Bean的生命周期远比“创建、使用、销毁”复杂。Spring提供了一系列精确的“钩子”允许我们在容器管理的各个关键时刻介入。完整理解这些节点是进行高级定制如整合第三方库、实现特定资源管理的前提。3.1 生命周期阶段的精细划分一个单例Bean在Spring IoC容器中的完整生命周期可以细化为以下连贯的步骤实例化相当于new关键字创建一个对象。属性填充进行依赖注入填充Autowired、Value等注解标记的属性。Aware接口回调如果Bean实现了各种Aware接口如BeanNameAware,BeanFactoryAware,ApplicationContextAware容器会回调相应方法将容器本身的某些对象注入给Bean。BeanPostProcessor.postProcessBeforeInitialization这是所有BeanPostProcessor实现的前置处理机会。ApplicationContext会自动注册一些内置的BeanPostProcessor例如负责处理PostConstruct、PreDestroy注解的CommonAnnotationBeanPostProcessor以及进行AOP代理创建的AnnotationAwareAspectJAutoProxyCreator。你的自定义BeanPostProcessor也会在此刻执行。初始化执行PostConstruct注解的方法。如果实现了InitializingBean接口执行afterPropertiesSet()方法。执行自定义的init-method通过XML或Bean(initMethod”…”)指定。BeanPostProcessor.postProcessAfterInitialization所有BeanPostProcessor的后置处理机会。AOP的动态代理通常就是在这个阶段创建的。如果Bean需要被代理容器会返回一个代理对象如JDK动态代理或CGLIB代理来代替原始的目标Bean。后续对Bean的调用实际上是对代理对象的调用。Bean就绪此时Bean已完全初始化并可能已被代理存放在单例池中供其他Bean或应用使用。销毁容器执行PreDestroy注解的方法。如果实现了DisposableBean接口执行destroy()方法。执行自定义的destroy-method。3.2 关键扩展点BeanPostProcessor与InstantiationAwareBeanPostProcessorBeanPostProcessor影响范围最广的扩展接口。它干预的是Bean初始化前后的阶段。上面提到的AOP代理创建、PostConstruct处理都是通过它实现的。你可以实现它来对Bean进行包装、修改甚至替换。Component public class MyBeanPostProcessor implements BeanPostProcessor { Override public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException { // 例如为所有Service类的方法调用添加日志 if (bean instanceof MyService) { // 这里通常返回一个代理对象 return Proxy.newProxyInstance(...); } return bean; } }注意BeanPostProcessor本身也是一个Bean但它的加载和初始化时机非常早在大多数其他Bean之前以便能处理后续的Bean。定义BeanPostProcessor时要避免让它依赖尚未初始化的Bean。InstantiationAwareBeanPostProcessor这是BeanPostProcessor的子接口它提供了更早的干预点——在Bean实例化前后以及属性填充之前。这常用于实现一些“黑科技”比如在实例化前直接返回一个代理对象跳过Spring默认的实例化和属性填充流程。一些集成框架如Mockito与Spring的集成会用到此技巧。在属性填充前对要注入的属性值进行修改或校验。常见问题排查如果你发现Autowired注入的属性为null而Bean明明定义了可以检查该Bean是否真的被Spring管理是否在组件扫描路径内或是否被Bean声明你是否在构造方法中试图使用被Autowired标注的字段构造方法执行时依赖注入尚未发生字段自然为null。解决方法是将依赖作为构造方法的参数构造器注入这是Spring推荐的方式。是否涉及静态字段或方法Autowired无法直接注入静态成员需要通过setter方法间接注入。4. 循环依赖的解决之道深入三级缓存机制循环依赖是面试必问也是实际开发中常见的“坑”。Spring通过其著名的“三级缓存”机制巧妙地解决了单例Bean的Setter注入和字段注入场景下的循环依赖问题。理解这个机制是判断Spring能否解决特定循环依赖情况的关键。4.1 什么是循环依赖Spring的解决边界假设有AService依赖BService同时BService也依赖AService这就构成了循环依赖。Spring并非能解决所有类型的循环依赖可解决单例Bean且依赖注入方式为属性注入Autowired字段或Setter方法注入。不可解决原型Prototype作用域的Bean会发生循环依赖。因为原型Bean每次请求都会新建Spring无法决定用哪个“半成品”进行注入。不可解决构造器注入发生的循环依赖。因为构造Bean A时需要完整的B构造B时又需要完整的A形成了“先有鸡还是先有蛋”的死锁。Spring会在启动时抛出BeanCurrentlyInCreationException。4.2 三级缓存的工作流程详解Spring容器内部维护了三个重要的Map称为三级缓存一级缓存singletonObjectsConcurrentHashMap存放完全初始化好的、成熟的单例Bean。这是主缓存我们getBean()最终获取的对象就在这里。二级缓存earlySingletonObjectsHashMap存放早期的Bean引用即已经实例化但尚未完成属性填充和初始化的“半成品”Bean。这些Bean可能已经被代理如果存在BeanPostProcessor提前干预。三级缓存singletonFactoriesHashMap存放的是ObjectFactory对象工厂。在Bean实例化之后、初始化之前Spring会将一个能生成该Bean早期引用的工厂函数放入此缓存。让我们以AService和BService循环依赖为例拆解整个过程开始创建AService。实例化AService调用构造函数得到一个原始对象a。此时a的属性bService是null。关键步骤Spring将a包装成一个ObjectFactory并将其放入三级缓存。这个工厂的能力是当被调用时它可以返回a的早期引用。如果存在AOP工厂会在这里执行getEarlyBeanReference逻辑可能返回一个代理对象。开始为a进行属性填充。发现它依赖BService于是尝试getBean(“bService”)。开始创建BService。实例化BService得到原始对象b。同样将b的ObjectFactory放入三级缓存。为b进行属性填充。发现它依赖AService于是尝试getBean(“aService”)。此时getBean(“aService”)的查找顺序是一级缓存 → 二级缓存 → 三级缓存。在一级缓存未找到在二级缓存也未找到但在三级缓存中找到了AService的ObjectFactory。关键步骤调用三级缓存中的ObjectFactory.getObject()。这个调用会触发可能存在的AOP处理然后返回a的早期引用可能是原始对象也可能是代理对象。Spring将这个早期引用放入二级缓存并从三级缓存中移除该工厂。BService成功获得了AService的早期引用并注入到自己的属性中。至此BService完成了属性填充接着执行初始化回调PostConstruct等变成一个完全成熟的Bean然后被放入一级缓存。BService创建完毕返回到AService的属性填充流程。此时AService顺利获得已经完全成熟的BServiceBean完成注入。AService继续执行初始化回调最终也变成一个完全成熟的Bean。最后清理AService被放入一级缓存。同时Spring会检查二级缓存如果存在AService的早期引用本例中存在会将其移除。因为一级缓存中的成熟Bean才是权威版本。整个过程中三级缓存的核心价值在于延迟代理对象的创建时机。如果只有二级缓存那么在实例化后立刻创建代理对象放入二级缓存对于大多数没有循环依赖的Bean来说是多余的、提前的操作。三级缓存通过一个工厂函数实现了“按需创建”早期引用只有真正发生循环依赖、其他Bean需要引用它时才会调用工厂生成早期引用可能是代理。实操心得与避坑指南构造器注入是首选虽然它无法解决循环依赖但它能强制要求设计清晰的、无循环的依赖关系这通常意味着更好的代码结构。Spring官方也推荐使用构造器注入。警惕PostConstruct中的循环调用即使Spring解决了属性注入的循环依赖但如果两个Bean的PostConstruct方法互相调用对方仍可能导致NullPointerException或逻辑错误。因为PostConstruct执行时另一个Bean可能尚未完成初始化。使用Lazy注解打破循环在其中一个注入点添加Lazy注解告诉Spring延迟初始化该依赖或者注入一个代理对象在实际调用时才去获取真实Bean可以有效解决许多循环依赖问题。Service public class AService { Autowired Lazy // 延迟注入BService private BService bService; }5. Spring AOP的核心原理与代理机制AOP面向切面编程是Spring的另一大基石用于解耦横切关注点如日志、事务、安全。其底层实现依赖于动态代理技术。理解代理机制对于解决AOP拦截失效、this调用导致增强不生效等问题至关重要。5.1 JDK动态代理与CGLIB代理的选型逻辑Spring AOP默认根据目标对象是否有实现接口来选择代理方式JDK动态代理基于接口。要求目标类至少实现一个接口。代理对象会实现和目标类相同的接口因此只能对接口中声明的方法进行拦截。性能中等。CGLIB代理基于继承。通过生成目标类的子类来创建代理。因此可以代理没有接口的类并且可以拦截非final的方法。由于涉及字节码生成创建代理对象的速度可能比JDK代理慢但方法调用性能通常更好。在Spring Boot中通过spring.aop.proxy-target-class属性可以强制指定false(默认)使用JDK动态代理如果目标有接口。true强制使用CGLIB代理无论目标是否有接口。为什么需要了解这个因为代理方式会影响一些细节Bean的类型被CGLIB代理的Bean其Class对象会是EnhancerBySpringCGLIB这样的子类而不是原始类。在某些需要精确类型匹配的场景如根据类型获取Bean时需要注意。final方法CGLIB无法代理final方法因为子类不能重写父类的final方法。内部方法调用这是最常见的“坑”。在同一个Bean内部一个方法A直接调用另一个方法Bthis.methodB()由于this指向的是目标对象本身而不是其代理对象因此对方法B的AOP增强如Transactional会失效。5.2 解决“内部调用”导致AOP失效的实践方案针对上述第3点问题有几种常见的解决方案注入自身代理推荐让Spring将代理对象自身注入到Bean中。Service public class MyService { Autowired private MyService self; // 注入代理对象本身 Transactional public void methodA() { // 业务逻辑A self.methodB(); // 通过代理对象调用事务生效 } Transactional(propagation Propagation.REQUIRES_NEW) public void methodB() { // 业务逻辑B } }需要确保在配置中启用了暴露代理对象在Spring Boot中EnableAspectJAutoProxy(exposeProxy true)默认已由Spring Boot自动配置处理。使用AopContext.currentProxy()需谨慎在方法内部获取当前代理对象。public void methodA() { // 业务逻辑A ((MyService) AopContext.currentProxy()).methodB(); }这种方法需要在配置中显式设置exposeProxy true并且有性能开销和类型转换风险。重构设计将方法B抽取到另一个Service中。这是最符合“单一职责”和“解耦”原则的方案但可能涉及较大的代码改动。常见问题排查如果发现Transactional注解不生效检查顺序如下方法是否是public的Spring AOP默认只代理public方法。是否在同一个Bean内部进行了this.调用异常类型是否被正确捕获默认情况下只有抛出RuntimeException和Error才会回滚检查型异常Exception不会。可以通过Transactional(rollbackFor Exception.class)修改。数据源配置是否正确事务管理器是否已配置6. Spring事务管理深度剖析Spring的事务管理抽象是处理数据一致性的利器但其传播行为和隔离级别常常令人困惑。理解这些概念在嵌套方法调用时的表现至关重要。6.1 事务传播行为Propagation实战场景传播行为定义了当一个事务方法被另一个事务方法调用时事务应该如何传播。最常用的几种REQUIRED(默认)如果当前存在事务则加入该事务如果当前没有事务则创建一个新的事务。场景大多数业务方法适用。例如用户下单操作主事务内部会调用扣库存、生成订单两个子方法它们都应运行在同一个事务中。REQUIRES_NEW无论如何都会创建一个新事务。如果当前存在事务则将当前事务挂起。场景需要独立提交/回滚的操作。例如在主要的业务逻辑中需要记录一个独立的审计日志即使主业务失败审计日志也必须成功保存。坑点因为会挂起外部事务所以两个事务完全独立。外部事务回滚不影响内部事务内部事务回滚会抛出异常影响外部除非被捕获处理。同时创建新连接有性能开销。NESTED如果当前存在事务则在当前事务的嵌套事务中执行。嵌套事务是外部事务的一部分只有外部事务提交时嵌套事务才会提交。嵌套事务可以独立回滚而不影响外部事务。场景部分操作可独立回滚。例如一个批量处理任务其中单条记录处理失败不希望影响其他记录但希望整体任务标记为失败。注意需要底层数据库支持保存点Savepoint如MySQL的InnoDB引擎。SUPPORTS如果当前存在事务则加入该事务如果当前没有事务则以非事务方式执行。NOT_SUPPORTED以非事务方式执行操作。如果当前存在事务则将其挂起。MANDATORY必须在一个已有的事务中运行否则抛出异常。NEVER必须不在事务中运行否则抛出异常。6.2 事务隔离级别Isolation与锁的关联隔离级别解决的是并发事务可能引发的读现象脏读、不可重复读、幻读。Spring定义了标准级别READ_UNCOMMITTED可读取未提交数据。存在脏读、不可重复读、幻读问题。基本不用。READ_COMMITTED(多数数据库默认)只能读取已提交数据。可避免脏读但存在不可重复读和幻读。REPEATABLE_READ(MySQL InnoDB默认)确保在同一事务中多次读取同一数据的结果一致。可避免脏读和不可重复读通过MVCC机制在一定程度上缓解幻读但并非完全杜绝。SERIALIZABLE最高隔离级别完全串行化执行。可避免所有并发问题但性能最差。重要认知Spring的隔离级别只是一个声明最终生效取决于底层数据库的支持。例如将Spring事务声明为SERIALIZABLESpring会告诉数据库连接使用该隔离级别具体的锁机制记录锁、间隙锁、表锁由数据库实现。实操心得默认值通常足够对于大多数应用使用默认的REQUIRED传播行为和数据库默认的隔离级别通常是READ_COMMITTED是安全且性能良好的。谨慎使用REQUIRES_NEW和NESTED它们会改变事务边界带来复杂的语义和潜在的性能问题。使用前务必明确业务需求。Transactional注解的位置注解在类上会对所有public方法生效注解在方法上优先级更高。推荐在具体方法上注解意图更清晰。事务与异常默认只在遇到RuntimeException和Error时回滚。如果希望检查型异常也触发回滚需使用rollbackFor属性。同样可以用noRollbackFor指定某些异常不回滚。理解Spring事务的底层机制结合具体的业务场景选择合适的传播行为和隔离级别是构建稳定数据访问层的基础。避免过度设计在简单场景使用默认配置在复杂场景审慎评估这才是进阶开发者应有的姿态。 深入Spring IoC容器：Bean生命周期、循环依赖与AOP代理机制全解析
1. 项目概述为什么我们需要深入Spring的“进阶篇”如果你已经用Spring Boot写过几个增删改查的项目觉得注解一加、依赖一配就能跑起来感觉Spring不过如此那这篇文章就是为你准备的。我见过太多开发者停留在“会用”的层面面试时被问到“Spring三级缓存原理”、“事务传播机制在嵌套方法中如何生效”就支支吾吾。这就像开车只会踩油门和刹车一旦遇到复杂路况或者车子抛锚就完全束手无策。Spring框架的优雅和强大恰恰隐藏在那些看似自动化的“魔法”背后。理解这些机制不仅能让你写出更健壮、高效的代码更能让你在排查诸如循环依赖导致启动失败、事务意外回滚、AOP拦截失效等诡异问题时拥有清晰的思路和底气。“进阶”并不意味着要去阅读Spring Framework那浩如烟海的源码虽然读源码是终极途径而是要把核心的运行原理、设计思想内化成自己的知识体系。本篇作为进阶系列的开篇我们将聚焦于Spring容器的核心——IoC容器深入其初始化过程、Bean的生命周期管理以及解决循环依赖的著名“三级缓存”机制。我们会绕过简单的概念复述直接切入实际开发中高频出现的场景和问题用“为什么”和“怎么办”串联起所有知识点。无论你是准备应对深度技术面试还是希望提升项目架构能力这里的讨论都将提供实实在在的助力。2. IoC容器初始化深度解析不止是ApplicationContext当我们启动一个Spring Boot应用SpringApplication.run()这一行代码背后容器究竟经历了什么很多人只知道结果Bean被创建了依赖被注入了。但这个过程里的关键抉择和潜在陷阱才是进阶路上必须清楚的。2.1BeanFactory与ApplicationContext的选用逻辑Spring提供了两种核心容器接口BeanFactory和ApplicationContext。ApplicationContext是BeanFactory的子接口意味着它拥有全部Bean工厂的能力并增加了更多企业级功能。为什么我们几乎总是使用ApplicationContext而非更基础的BeanFactory功能增强ApplicationContext在BeanFactory单纯管理Bean的基础上整合了消息资源处理国际化、事件发布、应用层特定的上下文如WebApplicationContext等功能。这些是现代应用开发的基础设施。Bean的预实例化这是关键区别之一。默认情况下BeanFactory延迟初始化所有单例Bean即用到时才创建而ApplicationContext在容器启动时就会初始化所有非延迟加载的单例Bean。这会导致启动时间变长但能尽早暴露配置错误和依赖问题符合大多数生产环境对稳定性的要求。如果你的应用有大量Bean且启动速度至关重要可以仔细规划Lazy注解的使用但需要警惕延迟初始化可能带来的运行时首次请求性能波动和循环依赖解析问题。注意在Spring Boot中通过SpringBootApplication注解引导的正是AnnotationConfigApplicationContext或针对Web的AnnotationConfigServletWebServerApplicationContext。它的初始化过程是理解后续所有机制的基础。2.2 容器启动的关键步骤与源码线索容器的初始化可以简化为几个核心阶段理解它们有助于定位启动期问题加载与解析配置容器读取配置源XML、Java Config、注解扫描的包路径将其转化为内部的BeanDefinition对象。BeanDefinition是Bean的“配方”或“蓝图”包含了类名、作用域、初始化方法、属性值等元数据但此时尚未创建真正的Java对象。BeanDefinition的注册与后处理将解析得到的BeanDefinition注册到BeanFactory的beanDefinitionMap中。随后BeanFactoryPostProcessor接口的实现类开始工作。这是容器提供的第一个强大的扩展点。例如PropertySourcesPlaceholderConfigurer或Spring Boot中的PropertySource就是在此阶段运行将${}占位符替换为具体的属性值。你可以自定义BeanFactoryPostProcessor来动态修改BeanDefinition比如根据环境变量调整Bean的类名。Bean实例化与依赖注入对于非延迟加载的单例Bean容器开始实例化。它根据BeanDefinition提供的信息通过反射调用构造函数创建对象实例化。然后进行依赖注入填充属性处理Autowired、Resource等注解。Bean的生命周期回调在依赖注入之后如果Bean实现了InitializingBean接口会调用其afterPropertiesSet()方法如果配置了init-method或使用了PostConstruct注解相应的方法也会被执行。至此一个完全可用的Bean就准备就绪了。容器刷新完成当所有单例Bean初始化完毕容器会触发上下文刷新完成事件应用正式进入可服务状态。实操心得很多启动时爆出的BeanCreationException根源都在前两步。例如BeanDefinitionStoreException可能是配置解析错误如XML语法错误BeanDefinitionOverrideExceptionSpring Boot 2.1默认禁止覆盖则是重复定义了同名的Bean。学会查看异常堆栈定位到是哪个阶段出了问题能极大提升排查效率。3. Bean的生命周期全景图不只是创建和销毁Bean的生命周期远比“创建、使用、销毁”复杂。Spring提供了一系列精确的“钩子”允许我们在容器管理的各个关键时刻介入。完整理解这些节点是进行高级定制如整合第三方库、实现特定资源管理的前提。3.1 生命周期阶段的精细划分一个单例Bean在Spring IoC容器中的完整生命周期可以细化为以下连贯的步骤实例化相当于new关键字创建一个对象。属性填充进行依赖注入填充Autowired、Value等注解标记的属性。Aware接口回调如果Bean实现了各种Aware接口如BeanNameAware,BeanFactoryAware,ApplicationContextAware容器会回调相应方法将容器本身的某些对象注入给Bean。BeanPostProcessor.postProcessBeforeInitialization这是所有BeanPostProcessor实现的前置处理机会。ApplicationContext会自动注册一些内置的BeanPostProcessor例如负责处理PostConstruct、PreDestroy注解的CommonAnnotationBeanPostProcessor以及进行AOP代理创建的AnnotationAwareAspectJAutoProxyCreator。你的自定义BeanPostProcessor也会在此刻执行。初始化执行PostConstruct注解的方法。如果实现了InitializingBean接口执行afterPropertiesSet()方法。执行自定义的init-method通过XML或Bean(initMethod”…”)指定。BeanPostProcessor.postProcessAfterInitialization所有BeanPostProcessor的后置处理机会。AOP的动态代理通常就是在这个阶段创建的。如果Bean需要被代理容器会返回一个代理对象如JDK动态代理或CGLIB代理来代替原始的目标Bean。后续对Bean的调用实际上是对代理对象的调用。Bean就绪此时Bean已完全初始化并可能已被代理存放在单例池中供其他Bean或应用使用。销毁容器执行PreDestroy注解的方法。如果实现了DisposableBean接口执行destroy()方法。执行自定义的destroy-method。3.2 关键扩展点BeanPostProcessor与InstantiationAwareBeanPostProcessorBeanPostProcessor影响范围最广的扩展接口。它干预的是Bean初始化前后的阶段。上面提到的AOP代理创建、PostConstruct处理都是通过它实现的。你可以实现它来对Bean进行包装、修改甚至替换。Component public class MyBeanPostProcessor implements BeanPostProcessor { Override public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException { // 例如为所有Service类的方法调用添加日志 if (bean instanceof MyService) { // 这里通常返回一个代理对象 return Proxy.newProxyInstance(...); } return bean; } }注意BeanPostProcessor本身也是一个Bean但它的加载和初始化时机非常早在大多数其他Bean之前以便能处理后续的Bean。定义BeanPostProcessor时要避免让它依赖尚未初始化的Bean。InstantiationAwareBeanPostProcessor这是BeanPostProcessor的子接口它提供了更早的干预点——在Bean实例化前后以及属性填充之前。这常用于实现一些“黑科技”比如在实例化前直接返回一个代理对象跳过Spring默认的实例化和属性填充流程。一些集成框架如Mockito与Spring的集成会用到此技巧。在属性填充前对要注入的属性值进行修改或校验。常见问题排查如果你发现Autowired注入的属性为null而Bean明明定义了可以检查该Bean是否真的被Spring管理是否在组件扫描路径内或是否被Bean声明你是否在构造方法中试图使用被Autowired标注的字段构造方法执行时依赖注入尚未发生字段自然为null。解决方法是将依赖作为构造方法的参数构造器注入这是Spring推荐的方式。是否涉及静态字段或方法Autowired无法直接注入静态成员需要通过setter方法间接注入。4. 循环依赖的解决之道深入三级缓存机制循环依赖是面试必问也是实际开发中常见的“坑”。Spring通过其著名的“三级缓存”机制巧妙地解决了单例Bean的Setter注入和字段注入场景下的循环依赖问题。理解这个机制是判断Spring能否解决特定循环依赖情况的关键。4.1 什么是循环依赖Spring的解决边界假设有AService依赖BService同时BService也依赖AService这就构成了循环依赖。Spring并非能解决所有类型的循环依赖可解决单例Bean且依赖注入方式为属性注入Autowired字段或Setter方法注入。不可解决原型Prototype作用域的Bean会发生循环依赖。因为原型Bean每次请求都会新建Spring无法决定用哪个“半成品”进行注入。不可解决构造器注入发生的循环依赖。因为构造Bean A时需要完整的B构造B时又需要完整的A形成了“先有鸡还是先有蛋”的死锁。Spring会在启动时抛出BeanCurrentlyInCreationException。4.2 三级缓存的工作流程详解Spring容器内部维护了三个重要的Map称为三级缓存一级缓存singletonObjectsConcurrentHashMap存放完全初始化好的、成熟的单例Bean。这是主缓存我们getBean()最终获取的对象就在这里。二级缓存earlySingletonObjectsHashMap存放早期的Bean引用即已经实例化但尚未完成属性填充和初始化的“半成品”Bean。这些Bean可能已经被代理如果存在BeanPostProcessor提前干预。三级缓存singletonFactoriesHashMap存放的是ObjectFactory对象工厂。在Bean实例化之后、初始化之前Spring会将一个能生成该Bean早期引用的工厂函数放入此缓存。让我们以AService和BService循环依赖为例拆解整个过程开始创建AService。实例化AService调用构造函数得到一个原始对象a。此时a的属性bService是null。关键步骤Spring将a包装成一个ObjectFactory并将其放入三级缓存。这个工厂的能力是当被调用时它可以返回a的早期引用。如果存在AOP工厂会在这里执行getEarlyBeanReference逻辑可能返回一个代理对象。开始为a进行属性填充。发现它依赖BService于是尝试getBean(“bService”)。开始创建BService。实例化BService得到原始对象b。同样将b的ObjectFactory放入三级缓存。为b进行属性填充。发现它依赖AService于是尝试getBean(“aService”)。此时getBean(“aService”)的查找顺序是一级缓存 → 二级缓存 → 三级缓存。在一级缓存未找到在二级缓存也未找到但在三级缓存中找到了AService的ObjectFactory。关键步骤调用三级缓存中的ObjectFactory.getObject()。这个调用会触发可能存在的AOP处理然后返回a的早期引用可能是原始对象也可能是代理对象。Spring将这个早期引用放入二级缓存并从三级缓存中移除该工厂。BService成功获得了AService的早期引用并注入到自己的属性中。至此BService完成了属性填充接着执行初始化回调PostConstruct等变成一个完全成熟的Bean然后被放入一级缓存。BService创建完毕返回到AService的属性填充流程。此时AService顺利获得已经完全成熟的BServiceBean完成注入。AService继续执行初始化回调最终也变成一个完全成熟的Bean。最后清理AService被放入一级缓存。同时Spring会检查二级缓存如果存在AService的早期引用本例中存在会将其移除。因为一级缓存中的成熟Bean才是权威版本。整个过程中三级缓存的核心价值在于延迟代理对象的创建时机。如果只有二级缓存那么在实例化后立刻创建代理对象放入二级缓存对于大多数没有循环依赖的Bean来说是多余的、提前的操作。三级缓存通过一个工厂函数实现了“按需创建”早期引用只有真正发生循环依赖、其他Bean需要引用它时才会调用工厂生成早期引用可能是代理。实操心得与避坑指南构造器注入是首选虽然它无法解决循环依赖但它能强制要求设计清晰的、无循环的依赖关系这通常意味着更好的代码结构。Spring官方也推荐使用构造器注入。警惕PostConstruct中的循环调用即使Spring解决了属性注入的循环依赖但如果两个Bean的PostConstruct方法互相调用对方仍可能导致NullPointerException或逻辑错误。因为PostConstruct执行时另一个Bean可能尚未完成初始化。使用Lazy注解打破循环在其中一个注入点添加Lazy注解告诉Spring延迟初始化该依赖或者注入一个代理对象在实际调用时才去获取真实Bean可以有效解决许多循环依赖问题。Service public class AService { Autowired Lazy // 延迟注入BService private BService bService; }5. Spring AOP的核心原理与代理机制AOP面向切面编程是Spring的另一大基石用于解耦横切关注点如日志、事务、安全。其底层实现依赖于动态代理技术。理解代理机制对于解决AOP拦截失效、this调用导致增强不生效等问题至关重要。5.1 JDK动态代理与CGLIB代理的选型逻辑Spring AOP默认根据目标对象是否有实现接口来选择代理方式JDK动态代理基于接口。要求目标类至少实现一个接口。代理对象会实现和目标类相同的接口因此只能对接口中声明的方法进行拦截。性能中等。CGLIB代理基于继承。通过生成目标类的子类来创建代理。因此可以代理没有接口的类并且可以拦截非final的方法。由于涉及字节码生成创建代理对象的速度可能比JDK代理慢但方法调用性能通常更好。在Spring Boot中通过spring.aop.proxy-target-class属性可以强制指定false(默认)使用JDK动态代理如果目标有接口。true强制使用CGLIB代理无论目标是否有接口。为什么需要了解这个因为代理方式会影响一些细节Bean的类型被CGLIB代理的Bean其Class对象会是EnhancerBySpringCGLIB这样的子类而不是原始类。在某些需要精确类型匹配的场景如根据类型获取Bean时需要注意。final方法CGLIB无法代理final方法因为子类不能重写父类的final方法。内部方法调用这是最常见的“坑”。在同一个Bean内部一个方法A直接调用另一个方法Bthis.methodB()由于this指向的是目标对象本身而不是其代理对象因此对方法B的AOP增强如Transactional会失效。5.2 解决“内部调用”导致AOP失效的实践方案针对上述第3点问题有几种常见的解决方案注入自身代理推荐让Spring将代理对象自身注入到Bean中。Service public class MyService { Autowired private MyService self; // 注入代理对象本身 Transactional public void methodA() { // 业务逻辑A self.methodB(); // 通过代理对象调用事务生效 } Transactional(propagation Propagation.REQUIRES_NEW) public void methodB() { // 业务逻辑B } }需要确保在配置中启用了暴露代理对象在Spring Boot中EnableAspectJAutoProxy(exposeProxy true)默认已由Spring Boot自动配置处理。使用AopContext.currentProxy()需谨慎在方法内部获取当前代理对象。public void methodA() { // 业务逻辑A ((MyService) AopContext.currentProxy()).methodB(); }这种方法需要在配置中显式设置exposeProxy true并且有性能开销和类型转换风险。重构设计将方法B抽取到另一个Service中。这是最符合“单一职责”和“解耦”原则的方案但可能涉及较大的代码改动。常见问题排查如果发现Transactional注解不生效检查顺序如下方法是否是public的Spring AOP默认只代理public方法。是否在同一个Bean内部进行了this.调用异常类型是否被正确捕获默认情况下只有抛出RuntimeException和Error才会回滚检查型异常Exception不会。可以通过Transactional(rollbackFor Exception.class)修改。数据源配置是否正确事务管理器是否已配置6. Spring事务管理深度剖析Spring的事务管理抽象是处理数据一致性的利器但其传播行为和隔离级别常常令人困惑。理解这些概念在嵌套方法调用时的表现至关重要。6.1 事务传播行为Propagation实战场景传播行为定义了当一个事务方法被另一个事务方法调用时事务应该如何传播。最常用的几种REQUIRED(默认)如果当前存在事务则加入该事务如果当前没有事务则创建一个新的事务。场景大多数业务方法适用。例如用户下单操作主事务内部会调用扣库存、生成订单两个子方法它们都应运行在同一个事务中。REQUIRES_NEW无论如何都会创建一个新事务。如果当前存在事务则将当前事务挂起。场景需要独立提交/回滚的操作。例如在主要的业务逻辑中需要记录一个独立的审计日志即使主业务失败审计日志也必须成功保存。坑点因为会挂起外部事务所以两个事务完全独立。外部事务回滚不影响内部事务内部事务回滚会抛出异常影响外部除非被捕获处理。同时创建新连接有性能开销。NESTED如果当前存在事务则在当前事务的嵌套事务中执行。嵌套事务是外部事务的一部分只有外部事务提交时嵌套事务才会提交。嵌套事务可以独立回滚而不影响外部事务。场景部分操作可独立回滚。例如一个批量处理任务其中单条记录处理失败不希望影响其他记录但希望整体任务标记为失败。注意需要底层数据库支持保存点Savepoint如MySQL的InnoDB引擎。SUPPORTS如果当前存在事务则加入该事务如果当前没有事务则以非事务方式执行。NOT_SUPPORTED以非事务方式执行操作。如果当前存在事务则将其挂起。MANDATORY必须在一个已有的事务中运行否则抛出异常。NEVER必须不在事务中运行否则抛出异常。6.2 事务隔离级别Isolation与锁的关联隔离级别解决的是并发事务可能引发的读现象脏读、不可重复读、幻读。Spring定义了标准级别READ_UNCOMMITTED可读取未提交数据。存在脏读、不可重复读、幻读问题。基本不用。READ_COMMITTED(多数数据库默认)只能读取已提交数据。可避免脏读但存在不可重复读和幻读。REPEATABLE_READ(MySQL InnoDB默认)确保在同一事务中多次读取同一数据的结果一致。可避免脏读和不可重复读通过MVCC机制在一定程度上缓解幻读但并非完全杜绝。SERIALIZABLE最高隔离级别完全串行化执行。可避免所有并发问题但性能最差。重要认知Spring的隔离级别只是一个声明最终生效取决于底层数据库的支持。例如将Spring事务声明为SERIALIZABLESpring会告诉数据库连接使用该隔离级别具体的锁机制记录锁、间隙锁、表锁由数据库实现。实操心得默认值通常足够对于大多数应用使用默认的REQUIRED传播行为和数据库默认的隔离级别通常是READ_COMMITTED是安全且性能良好的。谨慎使用REQUIRES_NEW和NESTED它们会改变事务边界带来复杂的语义和潜在的性能问题。使用前务必明确业务需求。Transactional注解的位置注解在类上会对所有public方法生效注解在方法上优先级更高。推荐在具体方法上注解意图更清晰。事务与异常默认只在遇到RuntimeException和Error时回滚。如果希望检查型异常也触发回滚需使用rollbackFor属性。同样可以用noRollbackFor指定某些异常不回滚。理解Spring事务的底层机制结合具体的业务场景选择合适的传播行为和隔离级别是构建稳定数据访问层的基础。避免过度设计在简单场景使用默认配置在复杂场景审慎评估这才是进阶开发者应有的姿态。