Spring框架是Java后端面试绕不开的关卡IOC和AOP这两个核心概念几乎是必考题而且面试官往往不满足于“控制反转就是对象创建交给容器”“AOP就是面向切面编程”这种一句话答案。十次面试里有九次会追问到底层机制、生命周期细节和循环依赖处理方式。这篇文章我把Spring IOC与AOP的底层逻辑掰开揉碎讲清楚结合源码思路和实际踩坑经验看完再去面试至少能接住三连问。先交代一下这篇文章的定位适合有Java基础、准备中级以上Java开发岗位面试的读者也可作为复习Spring源码前的快速思路梳理。文章里不会贴大段源码而是把核心设计逻辑和关键流程讲明白再配合面试标准答法和排查经验目标是让你能听懂、能讲出、能应对追问。1. IOC容器设计思路拆解IOC全称Inversion of Control控制反转。很多教程喜欢用“好莱坞原则”——“Don‘t call us, we‘ll call you”来解释但面试时候光说这个不够。真正要理解IOC得从容器本身的设计去看理解BeanFactory和ApplicationContext两个接口的关系、Bean的生命周期流程、以及单例Bean的缓存机制。1.1 BeanFactory与ApplicationContext的关系BeanFactory是IOC容器的顶层接口定义了最基本的getBean、containsBean、isSingleton这些方法相当于容器的“骨架”。ApplicationContext是BeanFactory的子接口在骨架之上扩展了国际化、事件发布、资源加载、自动扫描这些能力可以理解成“完整版容器”。面试问答里有个高频点ApplicationContext refresh()的时候做了什么如果读过源码会知道AbstractApplicationContext里那十几个步骤本质上是把BeanFactory从“空壳”变成“可用容器”的过程——包括设置BeanFactoryPostProcessor、注册BeanPostProcessor、实例化单例Bean等等。记忆方式是三步走先准备工厂再扩展工厂最后让工厂开始干活。还有一个常被混淆的BeanFactory和FactoryBean。前者是容器本身后者是容器里一个特殊的Bean它本身是一个工厂能生产出其他对象。为什么要把FactoryBean生出来的对象和普通对象区分开因为像mybatis的Mapper代理对象、Spring AOP生成的代理对象都需要通过FactoryBean来做定制创建容器直接拿到的其实是一个“工厂”调用getObject才得到真正的对象。这里就埋了一个伏笔AOP的代理对象同样依赖这套机制。1.2 Bean生命周期源码级拆解Bean的生命周期是IOC的高频追问点面试官会问“一个Bean从注册到销毁经历了哪些阶段”。标准答案分几步但要补充底层细节才有区分度。BeanDefinition合并完成后进入实例化流程。先推断构造方法选择要使用的构造函数并实例化然后做属性填充populateBean。属性填充之后容器会挨个回调所有BeanPostProcessor的postProcessBeforeInitialization之后执行InitializingBean接口的afterPropertiesSet或者自定义的init-method最后再回调postProcessAfterInitialization。这一套流程中重点在于AOP代理对象的织入发生在哪一步。答案是BeanPostProcessor的postProcessAfterInitialization。也就是说Spring先把原始Bean实例创建出来填充好属性在初始化后置处理的时候才根据切面配置决定要不要生成代理。弄清楚这个时机后面理解“代理失效”“循环依赖”“事务失效”就顺了。Bean的后置处理器与BeanFactoryPostProcessor容易搞混BeanFactoryPostProcessor作用于BeanDefinition阶段容器先让它改配置BeanPostProcessor作用于Bean实例化阶段容器让它改实例。顺序不能反这也是面试官爱挖的一个细节。1.3 三级缓存解决循环依赖原理Spring如何解决循环依赖是面试中原题几乎每次都会遇到。所谓循环依赖就是A依赖BB又依赖A双方都是单例。Spring不是一遍遍历就解决而是靠三级缓存。三级缓存是三个Map一级缓存singletonObjects存放完整创建好的单例Bean。二级缓存earlySingletonObjects存放提前暴露的、尚未完成初始化的半成品Bean。三级缓存singletonFactories存放ObjectFactory也就是创建半成品Bean的工厂。完整的流程大概是A创建时需要BSpring去缓存找B找不到就去创建B。B创建时发现需要A此时三级缓存里已经有A的ObjectFactoryA在实例化后、属性填充前被提前暴露。B通过ObjectFactory拿到A的早期引用也就是半成品A完成自己的属性填充随后B完成初始化进入一级缓存。接下来A拿到完整的B完成自己的属性填充和初始化也进入一级缓存。这里面值得深挖的两点为什么需要三级缓存二级缓存不就行了吗因为Spring希望在AOP的场景下B拿到的是A的代理对象而不是原始对象。三级缓存存ObjectFactory在真正需要提前引用时由工厂决定是返回原始Bean还是返回代理Bean这样兼顾了延迟和正确性。还有一个考点循环依赖只能解决单例、setter注入的循环。如果是构造器注入Spring直接抛出BeanCurrentlyInCreationException。所以非常推荐在面试时主动补一句Spring并不能解决构造器循环依赖因此日常开发中更推荐用setter注入避免写出“死循环”。这一句话能让面试官觉得你是真的踩过坑、读过源码。2. AOP底层机制与代理选择AOP面向切面编程解决的核心问题是横切逻辑复用。日志、权限、事务、监控这些逻辑如果不做切面会散落到每个业务方法里代码污染严重。Spring AOP的底层核心是动态代理围绕代理机制衍生出的三个关键问题是代理怎么创建、切点怎么匹配、通知怎么执行。2.1 JDK动态代理与CGLIB的选择逻辑Spring AOP同时支持JDK动态代理和CGLIB。JDK动态代理要求目标类必须有接口它基于java.lang.reflect.Proxy生成一个实现相同接口的代理类。CGLIB基于继承生成目标类的子类作为代理类因此目标类不能被final修饰。Spring Boot 2.x默认使用CGLIB代理也就是proxyTargetClass默认开启。为什么不再优先用JDK动态代理因为在现代应用里很多被切的对象没有接口比如配置类、第三方组件。若强行JDK代理代码里到处会碰到ClassCastException。此外CGLIB性能在优化后已经非常接近原生调用不再像早期那样被嫌弃。这里有一个重点JDK动态代理和CGLIB在反射调用上有本质差异。JDK动态代理的InvocationHandler只管派发真正的方法调用走Method.invokeCGLIB则直接把方法调用字节码包装在FastClass体系中查找索引后直接调用减少了反射的开销。面试时可以提这一点“CGLIB通过索引定位方法避免反射调用的元数据解析开销”这种细节是加分项。2.2 Advisor、Pointcut、Advice的协作关系AOP的几个核心概念容易混淆Pointcut是切点定义在哪拦截Advice是通知定义拦截后做什么Advisor可以理解成“切点通知”的组合对象。在Spring里配置一个Aspect切面最终会被解析成Advisor集合。Aspect类中被Before、Around标注的方法会被包装为Advice同时从Pointcut表达式生成Pointcut对象最终组装成InstantiationModelAwarePointcutAdvisor。切点表达式匹配是面试官爱深挖的点。execution表达式里最常用的签名 execution(修饰符 返回类型 类名.方法名(参数列表))例如execution(* com.example.service..(..))表示匹配com.example.service包下所有类的所有方法。常见坑就在于号和(..)的粒度第一个可以切任意返回类型类名后的*匹配当前包和子包需要加上..否则只匹配一层。参数列表两个点表示任意参数想让方法无参必须写空的括号这个细节最容易配错。2.3 代理对象创建时机前面提到AOP的代理在Bean生命周期最后一步postProcessAfterInitialization。但还有一个前置条件是容器要装一个BeanPostProcessor叫做AbstractAutoProxyCreator。它做什么在Bean实例化后调用wrapIfNecessary判断当前Bean是否需要代理。判断逻辑就是拿着所有的Advisor的Pointcut去匹配这个Bean的类型和方法命中就创建代理。到这里就能解释为什么同类方法调用不走代理。假设UserService调用this.doSomething()这里的this实际是目标类自身而不是代理对象切面自然不会被执行。这也是Spring事务失效最常见的场景。Transactional加在同类方法调用上不生效原理是一样的。还有一个容易忽略的事务和AOP的执行顺序。Spring事务本身也靠事务管理器加代理实现如果一个方法同时被业务切面和事务切面拦截谁先执行要看Order属性。默认情况下事务Advisor优先级较高会先开启事务再进入业务环绕通知。所以在自定义Around里通过TransactionSynchronizationManager拿到当前事务往往是可以拿到的。3. 高频面试追问与标准答法面试官问IOC和AOP时很少只问概念一定带着场景追问。三个高频追问场景循环依赖如何解决、事务为何失效、BeanFactory与FactoryBean区别。把这三题答利索Spring面试基本稳了一大半。3.1 循环依赖在什么场景下会直接报错虽然三级缓存解决了一部分循环依赖但有些情况仍然报错。第一是构造器注入循环依赖前面讲了直接创建异常。第二是非单例范围比如prototype类型的Bean因为容器不会缓存它无法提前暴露短期引用来解决问题。第三是Async或者类似需要在执行前做代理的Bean由于代理在初始化之后才创建提前暴露的原始对象里没有异步能力可能报“Cannot determine target class for proxy”或异步逻辑不生效。回答这道题时不要背概念用场景串联A依赖BB又依赖A并且A是单例且用setter注入那么三级缓存能兜底。如果换了构造器注入直接抛异常。面试官继续问“为什么构造器循环依赖不能解决”就要点出构造器调用必须在完整对象创建之前完成没有“半成品”可以提前暴露缺少提前注入的先决条件。3.2 事务失效场景分析事务失效是Spring面试的超高频题。常见失效场景有很多逐个拆解同类方法调用此时走的是原始对象this代理逻辑不介入。方法被private、final修饰private方法不能代理final类无法CGLIB增强。抛出的是checked异常Spring默认只回滚RuntimeException和Error。要让checked异常回滚得配rollbackFor Exception.class。自己catch了异常又没有抛出事务上下文拿不到异常回滚无从谈起。多线程环境下事务与线程绑定新开的线程不共享原事务上下文。数据库存储引擎不支持事务比如MySQL用MyISAM事务照样不生效。这几点里同类方法调用和异常被吞是我见过团队里最常见的两处。如果面试时能配合举例说“我之前排查事务不生效最后发现是同类事务方法自调用导致代理没生效”非常有说服力。3.3 BeanFactory与FactoryBean概念辨析这个题面试官爱用来考察基本功。BeanFactory是IOC容器根接口提供getBean等基本管理能力。FactoryBean是一种特殊的Bean接口它本身是注册在容器里的但是getBean(工厂名)拿到的不是FactoryBean实例而是它getObject()方法的返回值。典型应用有多少mybatis的MapperFactoryBean就是用FactoryBean机制生成Mapper接口的代理对象OpenFeign的FeignClientFactoryBean动态生成远程调用代理Spring整合Quartz也有类似的工厂Bean。能提到mybatis Mapper这个例子面试官就知道你用过这些组件并且关注过原理。4. 手写一个迷你IOC容器来验证思路面试中偶尔出现“手写一个Spring”的考察尤其是二线大厂的架构岗位。虽然不会要求写出完整Spring但验证候选人是否真正理解IOC常常要求实现一个“简化版容器”能够注册Bean定义、解析依赖、创建Bean实例、并支持单例缓存。这个练习强烈推荐做一遍做完之后再去回答前面那些生命周期问题完全是两个理解层次。4.1 最小可用的容器设计定义一个自定义注解比如取名MyComponent用来标记被容器托管的类。再定义一个属性类存放Bean的Class和是否为单例。容器类里维护一个Mapkey是Bean名称value是BeanDefinition。创建容器时扫描指定包路径下所有带MyComponent的类注册到BeanDefinitionMap。之后调用createBean流程先用反射调用构造器创建实例再遍历字段找MyResource这类注入注解对每个需要注入的字段递归getBean。最后把创建好的完整对象放入singletonObjects缓存。这个流程与Spring的差异点是Spring做了大量前置后置处理还有复杂的BeanDefinition合并与条件判断但核心的“注册定义→实例化→填充属性→缓存单例”这条主链路是一样的。4.2 在该练习中验证三级缓存思路完成最小IOC容器后还可以进一步实验只靠一个单例缓存Map能不能解决循环依赖在A依赖B、B依赖A的情况下必然出现嵌套递归和死循环。这时候把容器改造成“可以先注册一个半成品”的模型提前把未填充属性的A放入早期缓存B创建时就能拿到A的引用循环依赖自然被解开。手动做这个改造后你会发现早期的对象引用不是最终完整对象但因为Java对象引用指向同一块堆内存后面A补齐属性后B持有的引用也就“看到”了完整的A。这正是三级缓存设计的核心妙处。在代码里跑一遍比背十遍原理都管用。4.3 手写过程中的常见错误手写过程最容易踩的坑只注册具体类不注册接口导致字段注入时类型不匹配扩展点没做想加后置处理就得不断堆if-else单例缓存与早期的半成品缓存混淆写出来的代码在循环依赖场景下出现错乱。这些坑反过来恰好解释了Spring为什么设计了完整的BeanPostProcessor机制和三级缓存结构。如果你准备参加架构轮面试建议把这一节亲自实现并且把循环依赖场景的日志打出来。5. 日常开发中的常见问题与排查技巧面试讲的原理最终还是要落到业务代码里排坑。平时在项目里最常遇到的问题有三个代理不生效、切点表达式错配、循环依赖硬编码报错。把排查方法整理成一套流程遇事不慌。5.1 代理不生效的排查步骤遇到切面没执行我一般按以下顺序排查检查启动类有没有加EnableAspectJAutoProxySpring Boot则默认开启AOP但要确保引入了spring-boot-starter-aop依赖。检查目标方法访问级别private肯定不生效protected要谨慎最好public。检查同类调用搜索方法内是否直接this.method()调用改成注入自身代理或拆到另一个Service。检查切点表达式用日志方式判断是否命中比如在Advisor里临时打印方法名。检查是否被final修饰的类或方法拦截导致代理创建失败。有一次线上日志切面完全静默查了半天发现切点表达式写成了execution(* com.xxx.service...(..))其中的类名写错了一个字母直接匹配不上。所以排查顺序不要跳先把表达式真实跑一遍。5.2 循环依赖相关报错定位遇到BeanCurrentlyInCreationException时先看报错提示里的构造器链。如果是构造器循环依赖需要调整设计将部分注入属性改为setter或方法参数。如果是启动时提示“The dependencies of some of the beans in the application context form a cycle”可以从堆栈里把完整的循环链摘出来。我见过的真实案例两个审计Service互相依赖各是通过构造器注入导致启动失败。当时的解决方式是其中一个改造成懒加载注入或者拆掉相互依赖将公共逻辑抽成一个底层Service。归根结底循环依赖是一种设计味道即使Spring能解决setter类型的循环依赖也不应该成为代码常态架构上要把依赖层级理顺。5.3 切点表达式误配速查切点表达式是日常最容易出错的配置项。这里给一份常用参考匹配任意返回类型、指定包下的所有类方法execution(* com.example..(..))匹配指定包及子包execution(* com.example...(..))匹配指定类中所有public方法execution(public * com.example.UserService.*(..))匹配方法参数为String且只有这一个参数execution(* com.example.SayService.say(String))注意包路径后面是否有“..”决定是否包含子包。类名后的方法名用*匹配任意方法名方法括号内的(..)表示任意参数不要漏配。如果用了注解切点annotation(com.example.annotation.Log)要确认注解的RetentionPolicy是RUNTIME否则运行期拿不到注解。6. 我对Spring核心源码学习的几点体会源码本身很庞大不建议从头读到尾。我自己的学习路径是先通读Bean生命周期相关的核心类——DefaultSingletonBeanRegistry、AbstractAutowireCapableBeanFactory再顺着“refresh → 实例化单例Bean → 创建Bean → 属性填充 → 初始化后置处理”这条主线去读。这条主线读顺之后IOC等于过了一遍。AOP这一块建议从ProxyFactory入手。ProxyFactory是Spring AOP的底层配置类手动用它创建一次代理对象体会Advisor和TargetSource的作用再去看自动代理创建器就轻松了。网络上有不少源码解析系列可以对照着画流程脑图但手写体验是视频无法替代的这也是为什么我把第4节特意安排为手写练习。最后分享一个面试技巧回答Spring问题时习惯性地把“为什么这样设计”加进答案里比如提到三级缓存时主动说明“提前暴露是为了处理循环依赖、延迟代理是为了保持AOP正确性”让面试官觉得你具备源码级思考习惯。这个能力一旦建立IOC、AOP以及Spring Boot的自动装配这些问题都能触类旁通面试的主动权就回到你手上了。