讲真的Java后端面试问到SpringIOC和AOP这两座大山是绕不过去的。你别看面试题背了一堆控制反转依赖注入面向切面这些名词面试官真正想听的其实是底层机制——三级缓存怎么解决循环依赖、代理对象什么时候被创建、事务注解为什么有时候会失效。我这些年面试Java开发从初级到高级凡是Spring相关问题答得透的基本都能聊到源码级别凡是只背概念的追问两句就露馅了。这篇就把Spring框架核心的IOC和AOP彻底拆开揉碎讲清楚围绕着面试官的追问逻辑来写你照着这个思路去准备Spring相关的题基本不会卡壳。1. 面试官为什么一上来就考IOC和AOP1.1 控制反转的本质把创建对象这件事交出去如果你用最朴素的话解释IOCInversion of Control控制反转其实就是一句话对象不再自己new自己而是交给容器去创建和管理。但很多人在面试时只说这个层面显得太浅了面试官想听的是背后的设计动机。在没有IOC的年代业务代码里到处是new UserService()、new UserDao()这种硬编码。比如A依赖BA就得自己去创建BB又依赖CB还得创建C对象之间的依赖关系像蜘蛛网一样纠缠在代码里。更麻烦的是如果B的构造方法从无参变成有参所有创建B的地方都要跟着改维护成本直线上升。IOC的核心价值在于对象之间的依赖关系由容器负责建立对象本身不关心依赖从哪来。你把接口定义好、实现类配置好容器启动的时候自动帮你在合适的位置注入合适的实现。这样带来的好处非常明显模块之间解耦了替换实现类的时候不用改业务代码单元测试的时候还能轻松注入Mock对象。实际开发中Spring Boot的Autowired大家都用得很熟但面试时要答出深度得把IOC和DIDependency Injection依赖注入的关系说清楚。IOC是一种设计思想DI是实现这种思想的具体手段。Spring通过构造器注入、Setter注入、字段注入三种方式把依赖塞给对象其中构造器注入在配合不可变对象和防止循环依赖时最有优势这也是Spring官方推荐的方式。1.2 AOP的核心价值处理那些每个方法都要写一遍的琐事AOPAspect Oriented Programming面向切面编程解决的痛点和IOC不一样。IOC管的是对象之间的纵向依赖AOP管的是方法之间的横向逻辑。举个例子你现在给系统里的所有Service层方法加日志最原始的做法是每个方法都复制粘贴几行logger.info(调用了...)然后想着在调用前后统计耗时又得在每个方法里加代码。这种代码就是横切关注点——日志、事务、权限、异常处理它们散落在每个业务方法里跟核心业务逻辑没有关系却无法避免。AOP做的事情就是把这些横切逻辑抽出来做成切面然后通过代理机制在目标方法执行时自动织入。你写业务方法的时候就只关心业务日志和事务交给切面去做。谈到AOP就绕不开代理这个核心。Spring AOP默认采用运行期动态代理有两种实现方式JDK动态代理和CGLIB代理。JDK代理要求目标对象必须实现接口CGLIB则通过生成子类来实现代理所以对没有接口的类也能代理。Spring Boot 2.x之后默认走CGLIB哪怕你实现了接口默认也不用JDK代理了这个变化值得在面试时主动提一句。2. IOC容器的核心机制从BeanDefinition到单例池2.1 启动阶段BeanDefinition扫描与注册面试聊到Spring容器的时候很多人第一反应就是启动时创建Bean。这么说不能算错但不严谨因为Spring容器的启动其实分为两个阶段配置解析阶段和Bean创建阶段。配置解析阶段发生在refresh()方法执行的时候。Spring会先扫描指定的包路径把带有Component、Service、Controller、Repository注解的类读取出来通过ClassPathBeanDefinitionScanner扫描编译后的class文件然后解析成一个个BeanDefinition对象注册到容器中。你可以把BeanDefinition理解成Bean的设计图纸它记录了类的全限定名、是否懒加载、作用域是单例还是原型、初始化方法和销毁方法是什么、依赖了哪些其他Bean等等。Spring容器在这个阶段并没有真正创建对象只是先把如何创建对象的元信息收集起来攒齐了之后才进入下一步。这里有个面试中很容易被挖的细节Component、Service、Controller这三个注解在功能上并没有本质区别Service和Controller内部都标注了Component真正的区分只在语义层面。但Spring对它们是一视同仁的都会注册成BeanDefinition。但是Configuration不一样它需要用过CGLIB代理来保证内部Bean方法返回的是容器中的单例Bean所以它被单独处理这就是另一个层面的知识点了面试时能牵扯出来会加分。2.2 Bean的完整生命周期了解完注册阶段接着就要说Bean创建。Spring中绝大部分Bean都是单例的也就是说整个容器里同一个类只有一个实例默认在容器启动时就创建好。单例Bean的生命周期可以拆成以下几个关键步骤实例化调用构造器创建出对象。这一阶段对象还是原始对象属性都是默认值。属性填充Spring根据Autowired、Resource或者XML配置把依赖的Bean注入进来。这一步对应populateBean方法。Aware回调如果Bean实现了BeanNameAware、BeanFactoryAware或ApplicationContextAwareSpring会回调这些接口把容器相关信息传给你。初始化前置处理执行所有BeanPostProcessor的postProcessBeforeInitialization方法。初始化执行InitializingBean接口的afterPropertiesSet方法以及XML/注解上配置的init-method。初始化后置处理执行BeanPostProcessor的postProcessAfterInitialization方法。这一步非常关键AOP的代理对象就是在这个环节生成的。如果你配置了切面Spring会在这里返回一个新的代理对象来替代原来的原始对象。使用容器返回Bean给调用方。销毁容器关闭时执行DisposableBean的destroy方法和destroy-method配置。面试的时候你可以这么编排先背出上面的完整链路然后挑第6步展开说AOP的实现时机。面试官看到你有意识地把生命周周期和AOP结合起来谈会觉得你对容器运转的整体脉络是清晰的。2.3 三级缓存Spring怎么解决循环依赖聊完生命周期就能自然过渡到循环依赖了这是Spring面试里核弹级的问题。连环追问非常多但请记住本文接下来的内容。先想清楚问题本身如果一个类A依赖BB又依赖A而它们又都是单例BeanSpring怎么在启动时让它们都成功创建出来最直接的思维是先有鸡还是先有蛋A创建时需要BB创建时需要A逻辑上就是死循环。很多初学者第一次碰到这个问题都会卡住所以真正设计的巧妙之处值得说清楚。Spring解决这个问题的方案是三级缓存。三个缓存都是Map存储内容各不相同缓存层级名称存储内容一级缓存singletonObjects创建完成的单例Bean也就是容器最终使用的Bean对象二级缓存earlySingletonObjects提前暴露的早期Bean引用对象已实例化但还没完成完整的初始化流程三级缓存singletonFactoriesObjectFactory工厂接口负责为核心工厂创建早期Bean的引用整个流程可以这样描述创建A时A正常实例化完成后会提前把一个ObjectFactory放入三级缓存然后开始属性填充。填充时发现A依赖B于是去容器中拿BB接着开始创建B的实例化完成后也把工厂放到三级缓存然后B在属性填充时发现依赖了A。此时B去拿A时在一级缓存没有找到在二级缓存也没有找到但在三级缓存找到了A的工厂于是调用工厂获取A的早期引用放进二级缓存B拿到了A的早期引用就能完成自身的初始化初始化完被放进一级缓存。接下来A继续走初始化流程也在一级缓存中找到B的完整实例最后A也完成创建被放入一级缓存。很多人能讲到这里但那只是知其然接下来必须讲为什么不是两级缓存。这个追问确实很锋利用来区分面试深度的。两级缓存可以解决早期引用的问题吗可以。如果不考虑AOP两级缓存就够了二级缓存直接存早期对象循环依赖照样能解。但Spring不仅要考虑能用还要考虑代理和原始对象的一致性。我们假设场景里A有一个切面需要生成代理对象。正常创建流程中代理对象是在Bean生命周期第6步postProcessAfterInitialization生成的也就是Bean完全初始化完之后才生成代理。但如果A被B循环依赖了B提前拿到的是A的早期引用——这时候A还没走完初始化更没生成代理。如果B拿的是原始对象A而容器最终对外发布的是代理对象A那B持有的引用和容器中的对象就不是同一个了这是个致命的坑会直接导致A里的增强逻辑在B调用的时候完全失效。三级缓存里的ObjectFactory巧妙解决了这个问题。这个工厂在执行时会检查Spring有没有注册对应的SmartInstantiationAwareBeanPostProcessor即AbstractAutoProxyCreator如果有就提前调用getEarlyBeanReference方法生成代理对象再返回。也就是说如果A需要被代理B拿到的早期引用就是代理对象如果A不需要被代理B拿到的就是原始对象。这样无论有没有切面B拿到的对象都和容器最终对外发布的对象保持一致。Spring源码里那句著名的注释已经把意图讲得很清楚三级缓存的存在就是为了让AOP代理能在循环依赖中提前一步暴露出来。面试时把这个场景讲透这套连环追问基本就过关了。3. AOP底层原理代理对象是怎么被创建出来的3.1 从调用方视角理解为什么需要代理聊AOP原理前我要先纠正一个常见误区Spring AOP不是在编译期增强代码也不是改写了目标类的字节码文件而是在运行时创建一个替身对象也就是代理对象。你从容器里拿到Bean的时候实际拿到的往往不是你自己写的那个类实例而是通过动态代理生成的子类实例或接口实现实例。你在调用方法时调用的是代理对象的方法代理对象在真正执行你写业务逻辑之前先执行了一段切面逻辑这就是AOP能生效的根本机制。可以将它类比成外卖平台下的订单你下单时填的菜单不变外卖平台作为代理会在厨房做菜前帮你加封签、加小票还会在送达后打电话回访。你做菜和吃饭的核心流程没变但平台的横切逻辑被加进去了。3.2 JDK动态代理与CGLIB的分工与协作面试里高频对比题是JDK动态代理和CGLIB的区别。我把两者的核心差异总结出来JDK动态代理要求目标对象必须有接口。它基于java.lang.reflect.Proxy类在运行时为指定接口动态生成代理类代理类实现接口所有方法调用都会进入InvocationHandler的invoke方法。这种代理方式处理逻辑清晰性能也不错但它有个明显的限制——如果目标类没有接口就没法用。CGLIB则走了另一条路它通过生成目标类的子类来实现代理重写其中的非final方法在重写时插入切面逻辑。这种方案不要求接口但代价是不能代理final类和方法而且生成的代理类是目标类的子类目标类的方法如果被private修饰子类也无法重写覆盖。Spring早年的行为模式是目标类有接口就默认JDK代理没有接口才用CGLIB。但Spring Boot 2.x之后默认总是使用CGLIB代理甚至你实现了接口也不再默认JDK。原因是把proxyTargetClass设为true的做法简化了框架的行为模型也避免了为什么我按接口声明但注入失败这类坑。如果你的工程还在用Spring Boot 1.x版本迁移时这个变化需要注意。在实际编码的时候想用纯JDK代理自己写一个简单Demo只需要一个接口、一个目标类、一个InvocationHandler就能跑起来。但这个机制已经被Spring封装得相当完整业务侧基本不直接接触代理类。面试主动说出Spring在AbstractAutoProxyCreator中把拦截器链和代理工厂组装起来这类源码名次会显得非常有深度。3.3 动态代理的织入时机与Pointcut表达式光知道有代理还没到终点还得说清楚切面怎么匹配到目标方法。Spring中切面由三块组成**Pointcut切点**决定拦截谁**Advice通知**决定拦截后干什么**Aspect切面**则是二者的组合。对应到注解就是Around、Before、After、AfterReturning、AfterThrowing。在Bean初始化后置处理阶段Spring会通过AnnotationAwareAspectJAutoProxyCreator扫描容器中带有Aspect注解的Bean解析出切面定义里的切点表达式比如execution(* com.example.service.*.*(..))。这个表达式翻译成人话就是匹配com.example.service包下任意类的任意方法。当某个Bean初始化时Spring会把目标类的方法与所有切点表达式逐一匹配匹配上的就生成代理匹配不上就返回原始对象。有个容易被面试官挖坑的细节Spring AOP只支持方法级别的拦截因为动态代理本身就是方法层次的。如果你试图用Spring AOP拦截类的字段访问或者类的构造器调用那是不可能实现的因为动态代理无法在执行字段访问时插入逻辑。真正的构造器拦截和字节码层面增强要用AspectJ的静态织入或LTWLoad-Time Weaving。如果面试中能主动说出这个边界说明你对Spring AOP的能力边界非常清楚。3.4 声明式事务AOP最重要的实际落地很多人对AOP的理解停留在日志切面的层面忽略了AOP在Spring中最广泛的应用——声明式事务。Transactional注解的底层就是AOP。Spring在创建Bean时扫描到类或方法上标注了Transactional就会生成一个事务代理Bean。调用方法时代理会先开启事务方法正常返回则提交抛出运行时异常则回滚这就是声明式事务的完整链路。从原理层面剖析事务切面依赖的核心是TransactionInterceptor它会往当前线程的TransactionManager里获取或创建事务。这里有两个容易考的细节事务只对运行时异常回滚。默认情况下方法抛出RuntimeException或者Error事务才会回滚抛出受检异常或者说业务异常默认不会回滚需要配合rollbackFor属性指定异常类型。事务方法自调用会失效。因为Spring AOP是代理机制你在UserService里调用同一个类中的另一个Transactional方法时调用的是this的引用并没有经过代理对象所以事务拦截器根本不会介入事务自然就失效了。第二个问题在项目里经常让人头疼。比如一个Service里有个非事务方法调用了本类的两个带事务的方法结果发现一个抛异常另一个也提交了——这就是典型的自调用陷阱。解决办法是把事务方法独立到一个单独的Bean里用注入的方式调用或者通过self代理引用去调用。4. 高频面试题实战应答与避坑清单4.1 连环追问面试官真正想验证什么愿意深挖IOC和AOP的面试官通常有很明确的考察目标并不是想听听概念背诵。下面这几条是我梳理出的高频追问及其回应思路追问一BeanFactory和ApplicationContext有什么区别BeanFactory是最基础的IOC容器接口说白了是一个只能提供Bean注册和获取能力的工厂。ApplicationContext继承了BeanFactory但它丰富了容器特性比如资源加载、事件发布、国际化、自动注册BeanPostProcessor等。在绝大多数场景下应用都用ApplicationContext作为容器入口它是面试里最容易被一笔带过但必须答对的知识。追问二Singleton Bean和Singleton模式是一回事吗不能画等号。传统单例模式关注一个类全局只有一个实例这个实例保存在private静态字段里。Spring的单例是同一个BeanDefinition在一个容器中只有一个实例它的生命周期由容器管理实例保存在singletonObjects这个Map里。不同容器实例可以各自持有同一个类的不同单例而Spring单例还默认不是线程安全的因为它们被设计为无状态组件有状态就很容易在并发访问中出现数据错乱。追问三如果注入的Bean是Prototype作用域Spring能保证每次拿到新对象吗对于Autowired注入的情况不能保证。Spring在创建依赖时原型Bean只在容器启动时创建注入的那个时间点创建一次后续访问的还是同一个对象。真正想要每次都创建新对象需要通过ObjectFactory或者ObjectProvider来延迟获取或者使用Lookup注解。这个点面试时很容易掉坑值得警惕。追问四Spring的懒加载Bean启动时不创建那循环依赖还会被限制吗懒加载通常并不能规避循环依赖问题。因为Spring对原型Bean不允许循环依赖对单例Bean采用三级缓存机制解决。如果使用了懒加载那只是把创建时机延后了等到运行时才触发依赖解析一旦被依赖的Bean在创建时又依赖回当前Bean该报循环依赖还是得报。4.2 常见问题和排查技巧实录接下来这段是实战味道最强的部分我在公司内带新人或者做代码审查时遇到最多的问题基本都集中在下面几个地方问题1切面配置了但没生效八成是你没有让切面类被Spring管理。切面类上必须加Component或Aspect并配合包扫描才能被容器识别到其次检查问题是切点表达式是否写对execution(* com.xxx.service..*.*(..))和execution(* com.xxx.service.*.*(..))分别代表包含子包和仅当前包细节不对就匹配不上。另一种常见情况是你在类内部调用了this.xxx()自调用切面照样不触发。排查思路很简单先在切面方法里加一行System.out.println输出启动时观察有没有日志再看断点能不能走到AbstractAutoProxyCreator。如果Broker创建的Bean不是代理类型那就是注解没被解析到。问题2循环依赖加上AOP后业务代码出现异常原因就是前面说的早期引用是代理后期引用是原始对象的错位。虽然三级缓存已经解决大部分场景但如果你在ObjectFactory提前暴露的早期引用阶段不小心调用了被增强的方法而此时切面依赖的某些属性还没有被填充完整就会触发空指针或者状态不一致。更稳妥的做法是重新审视设计尝试通过构造器注入配合Lazy拆分依赖或者使用事件驱动彻底解开循环依赖。Spring官方对某些复杂的循环依赖警告过不允许的原因这里也需要有判断力。问题3公司项目从Spring Boot 1.x升级到2.x突然很多代理失效或报错版本升级里最直观的坑是代理模式改变了。Spring Boot 2.x默认开启CGLIB代理如果你之前依赖的是JDK代理版本并且代码里强转成具体实现类CGLIB代理还能转JDK代理却会因为接口类型限制而各种异常。此外Spring Boot 2.6之后循环依赖默认被禁用老项目里有循环依赖的代码升级后直接启动失败这是最经典的兼容性坑。应对方法是显式设置spring.main.allow-circular-referencestrue但你得先评估循环依赖是不是合理设计而不是无脑保留。问题4方法加了Transactional但自调用导致不生效前面讲过原理这里给你一个快速的排查清单确认方法访问权限是public确认异常类型是RuntimeException或通过rollbackFor显式指定确认调用方式是外部代理调用而不是this调用最后检查是不是在TransactionTemplate中混用了多个事务边界导致提交顺序混乱。4.3 手写微型Spring检验理解深度的硬核做法还有一个小技巧推荐给准备面试的人自己动手写一个迷你的Spring容器也就两三百行代码。不要觉得工程量不可控实际上只要实现三个版本就行。第一个版本先搞BeanDefinition注册和单例缓存用反射实例化对象让容器能自注册Bean。第二个版本加上构造器注入和字段注入测试一个最简单的依赖引用能不能创建成功。第三个版本再加一层动态代理来模拟AOP给一个目标方法自动打印日志这样就能彻底理解三级缓存之外代理织入的触发点到底在哪。这个动手过程比背十遍源代码更有价值因为你会亲身体会到ObjectFactory为什么要用工厂方法包一层以及二级缓存和三级缓存在代码路径上到底存在什么差异。很多人在面试时张口三级缓存闭口循环依赖但真正手写之后才能把源码里的思路转化成自己的语言。我个人带人的经验是能写完这个迷你容器的人对整个Spring框架的理解已经超过了不少有两年工作经验的人。如果时间充裕这是一笔百利而无一害的投入。4.4 面试应答话术参考很多读者会担心原理懂了但临场组织语言困难。这里我给一套参考结构回答IOC是什么先一句话定义再讲设计动机最后落到Spring的具体实现。比如IOC是把对象创建和依赖管理的控制权反转给容器核心目的是解耦。Spring通过BeanFactory读取BeanDefinition生成Bean实例再通过依赖注入把对象所需依赖装配好。用户拿到的只是对象引用具体对象怎么来的不需要关心。回答循环依赖解决原理按问题场景-三级缓存结构-获取链路-为什么是三级-边界情况五步说。不要上来就背三级缓存里有哪三级要先说场景否则听的人会觉得你只是背书。回答AOP原理先区分底层代理机制与上层注解体系。底层由JDK动态代理或CGLIB生成代理对象上层由切面表达式匹配目标方法织入通知逻辑。然后可以补充声明式事务作为典型实践。这套话术不是让你生硬背下来而是训练大脑里有一个兜底的叙述顺序不管问题怎么变化你都能顺着结构组织出清晰的内容。5. 写在最后的经验沉淀说到底Spring的IOC和AOP之所以成为面试核心是因为这背后牵扯到几个工程上最本质的问题对象怎么创建和组装、公共逻辑怎么复用、框架怎么扩展。把它们背后的设计动机搞懂比记住一堆源码方法名更有价值。我在面试候选人的时候最常听到的回答是三级缓存就是三个Map用于解决循环依赖。这种回答在题面上是对的但缺乏场景意识。真正好的回答应该让面试官感受到——我不但知道有三级缓存我还知道它解决的是单例Bean之间互相引用且有代理的问题我知道为什么不能降级成两级我知道哪些场景下循环依赖依然无法被解决。这就是区分背题的人和理解框架的人的关键分界线。对于准备面试的同学我强烈建议不要只刷题动手写代码才是最好的老师。去写一个自定义BeanPostProcessor、写一个自定义注解切面、把一个老旧项目的启动日志完整分析一遍再回头看源码里的refresh()方法你会发现自己对Spring的掌控感完全不一样。到了面试现场面对任何关于IOC和AOP的问题你都不需要临时搜肠刮肚地组织答案因为底层逻辑已经内化成自己的东西了。
讲真的Java后端面试问到SpringIOC和AOP这两座大山是绕不过去的。你别看面试题背了一堆控制反转依赖注入面向切面这些名词面试官真正想听的其实是底层机制——三级缓存怎么解决循环依赖、代理对象什么时候被创建、事务注解为什么有时候会失效。我这些年面试Java开发从初级到高级凡是Spring相关问题答得透的基本都能聊到源码级别凡是只背概念的追问两句就露馅了。这篇就把Spring框架核心的IOC和AOP彻底拆开揉碎讲清楚围绕着面试官的追问逻辑来写你照着这个思路去准备Spring相关的题基本不会卡壳。1. 面试官为什么一上来就考IOC和AOP1.1 控制反转的本质把创建对象这件事交出去如果你用最朴素的话解释IOCInversion of Control控制反转其实就是一句话对象不再自己new自己而是交给容器去创建和管理。但很多人在面试时只说这个层面显得太浅了面试官想听的是背后的设计动机。在没有IOC的年代业务代码里到处是new UserService()、new UserDao()这种硬编码。比如A依赖BA就得自己去创建BB又依赖CB还得创建C对象之间的依赖关系像蜘蛛网一样纠缠在代码里。更麻烦的是如果B的构造方法从无参变成有参所有创建B的地方都要跟着改维护成本直线上升。IOC的核心价值在于对象之间的依赖关系由容器负责建立对象本身不关心依赖从哪来。你把接口定义好、实现类配置好容器启动的时候自动帮你在合适的位置注入合适的实现。这样带来的好处非常明显模块之间解耦了替换实现类的时候不用改业务代码单元测试的时候还能轻松注入Mock对象。实际开发中Spring Boot的Autowired大家都用得很熟但面试时要答出深度得把IOC和DIDependency Injection依赖注入的关系说清楚。IOC是一种设计思想DI是实现这种思想的具体手段。Spring通过构造器注入、Setter注入、字段注入三种方式把依赖塞给对象其中构造器注入在配合不可变对象和防止循环依赖时最有优势这也是Spring官方推荐的方式。1.2 AOP的核心价值处理那些每个方法都要写一遍的琐事AOPAspect Oriented Programming面向切面编程解决的痛点和IOC不一样。IOC管的是对象之间的纵向依赖AOP管的是方法之间的横向逻辑。举个例子你现在给系统里的所有Service层方法加日志最原始的做法是每个方法都复制粘贴几行logger.info(调用了...)然后想着在调用前后统计耗时又得在每个方法里加代码。这种代码就是横切关注点——日志、事务、权限、异常处理它们散落在每个业务方法里跟核心业务逻辑没有关系却无法避免。AOP做的事情就是把这些横切逻辑抽出来做成切面然后通过代理机制在目标方法执行时自动织入。你写业务方法的时候就只关心业务日志和事务交给切面去做。谈到AOP就绕不开代理这个核心。Spring AOP默认采用运行期动态代理有两种实现方式JDK动态代理和CGLIB代理。JDK代理要求目标对象必须实现接口CGLIB则通过生成子类来实现代理所以对没有接口的类也能代理。Spring Boot 2.x之后默认走CGLIB哪怕你实现了接口默认也不用JDK代理了这个变化值得在面试时主动提一句。2. IOC容器的核心机制从BeanDefinition到单例池2.1 启动阶段BeanDefinition扫描与注册面试聊到Spring容器的时候很多人第一反应就是启动时创建Bean。这么说不能算错但不严谨因为Spring容器的启动其实分为两个阶段配置解析阶段和Bean创建阶段。配置解析阶段发生在refresh()方法执行的时候。Spring会先扫描指定的包路径把带有Component、Service、Controller、Repository注解的类读取出来通过ClassPathBeanDefinitionScanner扫描编译后的class文件然后解析成一个个BeanDefinition对象注册到容器中。你可以把BeanDefinition理解成Bean的设计图纸它记录了类的全限定名、是否懒加载、作用域是单例还是原型、初始化方法和销毁方法是什么、依赖了哪些其他Bean等等。Spring容器在这个阶段并没有真正创建对象只是先把如何创建对象的元信息收集起来攒齐了之后才进入下一步。这里有个面试中很容易被挖的细节Component、Service、Controller这三个注解在功能上并没有本质区别Service和Controller内部都标注了Component真正的区分只在语义层面。但Spring对它们是一视同仁的都会注册成BeanDefinition。但是Configuration不一样它需要用过CGLIB代理来保证内部Bean方法返回的是容器中的单例Bean所以它被单独处理这就是另一个层面的知识点了面试时能牵扯出来会加分。2.2 Bean的完整生命周期了解完注册阶段接着就要说Bean创建。Spring中绝大部分Bean都是单例的也就是说整个容器里同一个类只有一个实例默认在容器启动时就创建好。单例Bean的生命周期可以拆成以下几个关键步骤实例化调用构造器创建出对象。这一阶段对象还是原始对象属性都是默认值。属性填充Spring根据Autowired、Resource或者XML配置把依赖的Bean注入进来。这一步对应populateBean方法。Aware回调如果Bean实现了BeanNameAware、BeanFactoryAware或ApplicationContextAwareSpring会回调这些接口把容器相关信息传给你。初始化前置处理执行所有BeanPostProcessor的postProcessBeforeInitialization方法。初始化执行InitializingBean接口的afterPropertiesSet方法以及XML/注解上配置的init-method。初始化后置处理执行BeanPostProcessor的postProcessAfterInitialization方法。这一步非常关键AOP的代理对象就是在这个环节生成的。如果你配置了切面Spring会在这里返回一个新的代理对象来替代原来的原始对象。使用容器返回Bean给调用方。销毁容器关闭时执行DisposableBean的destroy方法和destroy-method配置。面试的时候你可以这么编排先背出上面的完整链路然后挑第6步展开说AOP的实现时机。面试官看到你有意识地把生命周周期和AOP结合起来谈会觉得你对容器运转的整体脉络是清晰的。2.3 三级缓存Spring怎么解决循环依赖聊完生命周期就能自然过渡到循环依赖了这是Spring面试里核弹级的问题。连环追问非常多但请记住本文接下来的内容。先想清楚问题本身如果一个类A依赖BB又依赖A而它们又都是单例BeanSpring怎么在启动时让它们都成功创建出来最直接的思维是先有鸡还是先有蛋A创建时需要BB创建时需要A逻辑上就是死循环。很多初学者第一次碰到这个问题都会卡住所以真正设计的巧妙之处值得说清楚。Spring解决这个问题的方案是三级缓存。三个缓存都是Map存储内容各不相同缓存层级名称存储内容一级缓存singletonObjects创建完成的单例Bean也就是容器最终使用的Bean对象二级缓存earlySingletonObjects提前暴露的早期Bean引用对象已实例化但还没完成完整的初始化流程三级缓存singletonFactoriesObjectFactory工厂接口负责为核心工厂创建早期Bean的引用整个流程可以这样描述创建A时A正常实例化完成后会提前把一个ObjectFactory放入三级缓存然后开始属性填充。填充时发现A依赖B于是去容器中拿BB接着开始创建B的实例化完成后也把工厂放到三级缓存然后B在属性填充时发现依赖了A。此时B去拿A时在一级缓存没有找到在二级缓存也没有找到但在三级缓存找到了A的工厂于是调用工厂获取A的早期引用放进二级缓存B拿到了A的早期引用就能完成自身的初始化初始化完被放进一级缓存。接下来A继续走初始化流程也在一级缓存中找到B的完整实例最后A也完成创建被放入一级缓存。很多人能讲到这里但那只是知其然接下来必须讲为什么不是两级缓存。这个追问确实很锋利用来区分面试深度的。两级缓存可以解决早期引用的问题吗可以。如果不考虑AOP两级缓存就够了二级缓存直接存早期对象循环依赖照样能解。但Spring不仅要考虑能用还要考虑代理和原始对象的一致性。我们假设场景里A有一个切面需要生成代理对象。正常创建流程中代理对象是在Bean生命周期第6步postProcessAfterInitialization生成的也就是Bean完全初始化完之后才生成代理。但如果A被B循环依赖了B提前拿到的是A的早期引用——这时候A还没走完初始化更没生成代理。如果B拿的是原始对象A而容器最终对外发布的是代理对象A那B持有的引用和容器中的对象就不是同一个了这是个致命的坑会直接导致A里的增强逻辑在B调用的时候完全失效。三级缓存里的ObjectFactory巧妙解决了这个问题。这个工厂在执行时会检查Spring有没有注册对应的SmartInstantiationAwareBeanPostProcessor即AbstractAutoProxyCreator如果有就提前调用getEarlyBeanReference方法生成代理对象再返回。也就是说如果A需要被代理B拿到的早期引用就是代理对象如果A不需要被代理B拿到的就是原始对象。这样无论有没有切面B拿到的对象都和容器最终对外发布的对象保持一致。Spring源码里那句著名的注释已经把意图讲得很清楚三级缓存的存在就是为了让AOP代理能在循环依赖中提前一步暴露出来。面试时把这个场景讲透这套连环追问基本就过关了。3. AOP底层原理代理对象是怎么被创建出来的3.1 从调用方视角理解为什么需要代理聊AOP原理前我要先纠正一个常见误区Spring AOP不是在编译期增强代码也不是改写了目标类的字节码文件而是在运行时创建一个替身对象也就是代理对象。你从容器里拿到Bean的时候实际拿到的往往不是你自己写的那个类实例而是通过动态代理生成的子类实例或接口实现实例。你在调用方法时调用的是代理对象的方法代理对象在真正执行你写业务逻辑之前先执行了一段切面逻辑这就是AOP能生效的根本机制。可以将它类比成外卖平台下的订单你下单时填的菜单不变外卖平台作为代理会在厨房做菜前帮你加封签、加小票还会在送达后打电话回访。你做菜和吃饭的核心流程没变但平台的横切逻辑被加进去了。3.2 JDK动态代理与CGLIB的分工与协作面试里高频对比题是JDK动态代理和CGLIB的区别。我把两者的核心差异总结出来JDK动态代理要求目标对象必须有接口。它基于java.lang.reflect.Proxy类在运行时为指定接口动态生成代理类代理类实现接口所有方法调用都会进入InvocationHandler的invoke方法。这种代理方式处理逻辑清晰性能也不错但它有个明显的限制——如果目标类没有接口就没法用。CGLIB则走了另一条路它通过生成目标类的子类来实现代理重写其中的非final方法在重写时插入切面逻辑。这种方案不要求接口但代价是不能代理final类和方法而且生成的代理类是目标类的子类目标类的方法如果被private修饰子类也无法重写覆盖。Spring早年的行为模式是目标类有接口就默认JDK代理没有接口才用CGLIB。但Spring Boot 2.x之后默认总是使用CGLIB代理甚至你实现了接口也不再默认JDK。原因是把proxyTargetClass设为true的做法简化了框架的行为模型也避免了为什么我按接口声明但注入失败这类坑。如果你的工程还在用Spring Boot 1.x版本迁移时这个变化需要注意。在实际编码的时候想用纯JDK代理自己写一个简单Demo只需要一个接口、一个目标类、一个InvocationHandler就能跑起来。但这个机制已经被Spring封装得相当完整业务侧基本不直接接触代理类。面试主动说出Spring在AbstractAutoProxyCreator中把拦截器链和代理工厂组装起来这类源码名次会显得非常有深度。3.3 动态代理的织入时机与Pointcut表达式光知道有代理还没到终点还得说清楚切面怎么匹配到目标方法。Spring中切面由三块组成**Pointcut切点**决定拦截谁**Advice通知**决定拦截后干什么**Aspect切面**则是二者的组合。对应到注解就是Around、Before、After、AfterReturning、AfterThrowing。在Bean初始化后置处理阶段Spring会通过AnnotationAwareAspectJAutoProxyCreator扫描容器中带有Aspect注解的Bean解析出切面定义里的切点表达式比如execution(* com.example.service.*.*(..))。这个表达式翻译成人话就是匹配com.example.service包下任意类的任意方法。当某个Bean初始化时Spring会把目标类的方法与所有切点表达式逐一匹配匹配上的就生成代理匹配不上就返回原始对象。有个容易被面试官挖坑的细节Spring AOP只支持方法级别的拦截因为动态代理本身就是方法层次的。如果你试图用Spring AOP拦截类的字段访问或者类的构造器调用那是不可能实现的因为动态代理无法在执行字段访问时插入逻辑。真正的构造器拦截和字节码层面增强要用AspectJ的静态织入或LTWLoad-Time Weaving。如果面试中能主动说出这个边界说明你对Spring AOP的能力边界非常清楚。3.4 声明式事务AOP最重要的实际落地很多人对AOP的理解停留在日志切面的层面忽略了AOP在Spring中最广泛的应用——声明式事务。Transactional注解的底层就是AOP。Spring在创建Bean时扫描到类或方法上标注了Transactional就会生成一个事务代理Bean。调用方法时代理会先开启事务方法正常返回则提交抛出运行时异常则回滚这就是声明式事务的完整链路。从原理层面剖析事务切面依赖的核心是TransactionInterceptor它会往当前线程的TransactionManager里获取或创建事务。这里有两个容易考的细节事务只对运行时异常回滚。默认情况下方法抛出RuntimeException或者Error事务才会回滚抛出受检异常或者说业务异常默认不会回滚需要配合rollbackFor属性指定异常类型。事务方法自调用会失效。因为Spring AOP是代理机制你在UserService里调用同一个类中的另一个Transactional方法时调用的是this的引用并没有经过代理对象所以事务拦截器根本不会介入事务自然就失效了。第二个问题在项目里经常让人头疼。比如一个Service里有个非事务方法调用了本类的两个带事务的方法结果发现一个抛异常另一个也提交了——这就是典型的自调用陷阱。解决办法是把事务方法独立到一个单独的Bean里用注入的方式调用或者通过self代理引用去调用。4. 高频面试题实战应答与避坑清单4.1 连环追问面试官真正想验证什么愿意深挖IOC和AOP的面试官通常有很明确的考察目标并不是想听听概念背诵。下面这几条是我梳理出的高频追问及其回应思路追问一BeanFactory和ApplicationContext有什么区别BeanFactory是最基础的IOC容器接口说白了是一个只能提供Bean注册和获取能力的工厂。ApplicationContext继承了BeanFactory但它丰富了容器特性比如资源加载、事件发布、国际化、自动注册BeanPostProcessor等。在绝大多数场景下应用都用ApplicationContext作为容器入口它是面试里最容易被一笔带过但必须答对的知识。追问二Singleton Bean和Singleton模式是一回事吗不能画等号。传统单例模式关注一个类全局只有一个实例这个实例保存在private静态字段里。Spring的单例是同一个BeanDefinition在一个容器中只有一个实例它的生命周期由容器管理实例保存在singletonObjects这个Map里。不同容器实例可以各自持有同一个类的不同单例而Spring单例还默认不是线程安全的因为它们被设计为无状态组件有状态就很容易在并发访问中出现数据错乱。追问三如果注入的Bean是Prototype作用域Spring能保证每次拿到新对象吗对于Autowired注入的情况不能保证。Spring在创建依赖时原型Bean只在容器启动时创建注入的那个时间点创建一次后续访问的还是同一个对象。真正想要每次都创建新对象需要通过ObjectFactory或者ObjectProvider来延迟获取或者使用Lookup注解。这个点面试时很容易掉坑值得警惕。追问四Spring的懒加载Bean启动时不创建那循环依赖还会被限制吗懒加载通常并不能规避循环依赖问题。因为Spring对原型Bean不允许循环依赖对单例Bean采用三级缓存机制解决。如果使用了懒加载那只是把创建时机延后了等到运行时才触发依赖解析一旦被依赖的Bean在创建时又依赖回当前Bean该报循环依赖还是得报。4.2 常见问题和排查技巧实录接下来这段是实战味道最强的部分我在公司内带新人或者做代码审查时遇到最多的问题基本都集中在下面几个地方问题1切面配置了但没生效八成是你没有让切面类被Spring管理。切面类上必须加Component或Aspect并配合包扫描才能被容器识别到其次检查问题是切点表达式是否写对execution(* com.xxx.service..*.*(..))和execution(* com.xxx.service.*.*(..))分别代表包含子包和仅当前包细节不对就匹配不上。另一种常见情况是你在类内部调用了this.xxx()自调用切面照样不触发。排查思路很简单先在切面方法里加一行System.out.println输出启动时观察有没有日志再看断点能不能走到AbstractAutoProxyCreator。如果Broker创建的Bean不是代理类型那就是注解没被解析到。问题2循环依赖加上AOP后业务代码出现异常原因就是前面说的早期引用是代理后期引用是原始对象的错位。虽然三级缓存已经解决大部分场景但如果你在ObjectFactory提前暴露的早期引用阶段不小心调用了被增强的方法而此时切面依赖的某些属性还没有被填充完整就会触发空指针或者状态不一致。更稳妥的做法是重新审视设计尝试通过构造器注入配合Lazy拆分依赖或者使用事件驱动彻底解开循环依赖。Spring官方对某些复杂的循环依赖警告过不允许的原因这里也需要有判断力。问题3公司项目从Spring Boot 1.x升级到2.x突然很多代理失效或报错版本升级里最直观的坑是代理模式改变了。Spring Boot 2.x默认开启CGLIB代理如果你之前依赖的是JDK代理版本并且代码里强转成具体实现类CGLIB代理还能转JDK代理却会因为接口类型限制而各种异常。此外Spring Boot 2.6之后循环依赖默认被禁用老项目里有循环依赖的代码升级后直接启动失败这是最经典的兼容性坑。应对方法是显式设置spring.main.allow-circular-referencestrue但你得先评估循环依赖是不是合理设计而不是无脑保留。问题4方法加了Transactional但自调用导致不生效前面讲过原理这里给你一个快速的排查清单确认方法访问权限是public确认异常类型是RuntimeException或通过rollbackFor显式指定确认调用方式是外部代理调用而不是this调用最后检查是不是在TransactionTemplate中混用了多个事务边界导致提交顺序混乱。4.3 手写微型Spring检验理解深度的硬核做法还有一个小技巧推荐给准备面试的人自己动手写一个迷你的Spring容器也就两三百行代码。不要觉得工程量不可控实际上只要实现三个版本就行。第一个版本先搞BeanDefinition注册和单例缓存用反射实例化对象让容器能自注册Bean。第二个版本加上构造器注入和字段注入测试一个最简单的依赖引用能不能创建成功。第三个版本再加一层动态代理来模拟AOP给一个目标方法自动打印日志这样就能彻底理解三级缓存之外代理织入的触发点到底在哪。这个动手过程比背十遍源代码更有价值因为你会亲身体会到ObjectFactory为什么要用工厂方法包一层以及二级缓存和三级缓存在代码路径上到底存在什么差异。很多人在面试时张口三级缓存闭口循环依赖但真正手写之后才能把源码里的思路转化成自己的语言。我个人带人的经验是能写完这个迷你容器的人对整个Spring框架的理解已经超过了不少有两年工作经验的人。如果时间充裕这是一笔百利而无一害的投入。4.4 面试应答话术参考很多读者会担心原理懂了但临场组织语言困难。这里我给一套参考结构回答IOC是什么先一句话定义再讲设计动机最后落到Spring的具体实现。比如IOC是把对象创建和依赖管理的控制权反转给容器核心目的是解耦。Spring通过BeanFactory读取BeanDefinition生成Bean实例再通过依赖注入把对象所需依赖装配好。用户拿到的只是对象引用具体对象怎么来的不需要关心。回答循环依赖解决原理按问题场景-三级缓存结构-获取链路-为什么是三级-边界情况五步说。不要上来就背三级缓存里有哪三级要先说场景否则听的人会觉得你只是背书。回答AOP原理先区分底层代理机制与上层注解体系。底层由JDK动态代理或CGLIB生成代理对象上层由切面表达式匹配目标方法织入通知逻辑。然后可以补充声明式事务作为典型实践。这套话术不是让你生硬背下来而是训练大脑里有一个兜底的叙述顺序不管问题怎么变化你都能顺着结构组织出清晰的内容。5. 写在最后的经验沉淀说到底Spring的IOC和AOP之所以成为面试核心是因为这背后牵扯到几个工程上最本质的问题对象怎么创建和组装、公共逻辑怎么复用、框架怎么扩展。把它们背后的设计动机搞懂比记住一堆源码方法名更有价值。我在面试候选人的时候最常听到的回答是三级缓存就是三个Map用于解决循环依赖。这种回答在题面上是对的但缺乏场景意识。真正好的回答应该让面试官感受到——我不但知道有三级缓存我还知道它解决的是单例Bean之间互相引用且有代理的问题我知道为什么不能降级成两级我知道哪些场景下循环依赖依然无法被解决。这就是区分背题的人和理解框架的人的关键分界线。对于准备面试的同学我强烈建议不要只刷题动手写代码才是最好的老师。去写一个自定义BeanPostProcessor、写一个自定义注解切面、把一个老旧项目的启动日志完整分析一遍再回头看源码里的refresh()方法你会发现自己对Spring的掌控感完全不一样。到了面试现场面对任何关于IOC和AOP的问题你都不需要临时搜肠刮肚地组织答案因为底层逻辑已经内化成自己的东西了。
