前阵子我在团队内部做技术分享一上来就问了个问题你们天天用 Spring 写接口那谁能用一句话说清楚Autowired到底帮你做了什么有人说是依赖注入有人说是把对象装配好也有人开玩笑说是魔法。我再追问一句如果你的项目里每个接口都要统计耗时、记录操作日志、做权限校验你会怎么实现大概率有人会说写个拦截器有人会说写个注解再深入问拦截器底层凭什么能把你的方法包起来这时候能讲清楚的人就不多了。这两个问题的答案其实就是 Spring 框架的两大核心IoC控制反转和AOP面向切面编程。这不是两个孤立的概念而是一套落地到字节码层面的设计哲学。这篇文章不讲那种搜一下到处都是的入门科普而是从原理、源码设计、真实项目应用和踩坑经验四个维度展开帮你把这两块彻底吃透。无论你是准备面试还是想在团队里把 Spring 用到更明白都值得认真看完。1. 先搞清楚两件事谁管理对象谁处理横切逻辑1.1 没有容器之前Java 对象的创建有多痛我最早写 Java Web 还是 Servlet JDBC 的年代代码里到处都是new。Service 里 new DaoDao 里 new DataSource想换一个数据库连接池得把相关类全部改一遍。更难受的是测试Dao 连的是真实数据库你没法在单元测试里塞一个 Mock 进去因为对象依赖是写死在代码里的。多年以后我回头看这段历史的本质问题是对象的创建和依赖关系管理被散落在每个业务类里。每个类既当运动员又当裁判员管自己还不够还要管别人。如果系统里有一百个类这团线就乱了。控制反转 IoC 解决的问题恰恰就是把谁负责创建对象、谁负责注入依赖这个控制权从业务类手中收回来统一交给容器。Spring 容器扫描配置或注解分析类之间的依赖关系然后替你完成实例化和注入。你只需要声明我这个类需要一个数据源剩下的由容器负责。1.2 控制反转到底反转了什么很多朋友背概念的时候只说把对象的创建交给容器但面试官追问一句反转了什么就卡壳。反转的是控制权。传统写法里控制权在对象自己手里你要用 B就在 A 里new B()A 需要知道 B 的实现细节、B 的构造参数、B 的生命周期。反转之后A 类只声明一个接口或类型的依赖容器在运行时把符合条件的对象塞给你。用生活的例子类比你要吃外卖传统方式是自己买菜、进厨房、炒菜、洗碗整个过程都由你控制。IoC 是你下单之后外卖由平台调度厨师做菜骑手配送送到你手里你只管吃。你的依赖对象厨师、骑手不是你创建的是平台外部注入给你的。这个平台就是 Spring 容器。IoC 带来的收益是解耦、可替换、可测试。因为 A 不关心 B 的具体实现只依赖接口那么在测试里注入一个 MockB在线上注入一个 RealBA 的代码一行都不用改。1.3 面向切面编程解决的是横切逻辑的归属问题再来说 AOP。业务系统里有很多逻辑是横切的什么意思它不属于某一个业务模块而是像 X 光一样穿透所有业务方法。例如方法执行耗时统计操作日志记录权限校验事务管理重复提交拦截如果这些逻辑不用 AOP你会怎么做最土的办法是在每个业务方法里手动调一个LogUtil.record()或者每个方法开头都写一段鉴权代码。结果是主业务逻辑被大量非业务代码淹没而且一旦日志格式要改几十个类同步修改极易漏掉。AOP 的思路是把这类横切逻辑抽离成切面通过代理机制在目标方法执行前后自动织入。业务代码只管业务横切逻辑交给切面两者互不污染。Spring AOP 的底层依赖动态代理后面我会展开讲。2. IoC 不是概念是容器Bean 生命周期与三级缓存拆解2.1 一个 Bean 从定义到销毁经历了什么很多人用 Spring 用了很久对Component、Service背后的机制还停留在注解层面。我建议你至少把 Bean 的完整生命周期在脑子里过一遍。它是 IoC 容器的核心脉络扫描与解析容器启动时Spring 扫描指定包路径把带Component等注解的类解析成BeanDefinition相当于给每个 Bean 建立档案。实例化根据BeanDefinition通过反射构造对象此时对象刚new出来属性还是空的。属性填充容器扫描依赖通过Autowired或构造器等方法注入依赖属性。初始化调用BeanPostProcessor的前置增强、PostConstruct方法、InitializingBean接口等完成自定义初始化。使用对象被放入单例池供业务调用。销毁容器关闭时执行PreDestroy、DisposableBean等方法释放资源。这里有个经常被忽略的点BeanPostProcessor 是 Spring 留给使用者的最大后门。你需要对某个 Bean 做自定义处理只需要实现这个接口Spring 在 Bean 初始化前后都会回调你。Spring 内部的 AOP 自动代理、Autowired注解解析都是借助各类BeanPostProcessor实现的。生命周期阶段关键扩展点典型用途实例化前InstantiationAwareBeanPostProcessor自定义实例化逻辑实例化后BeanPostProcessor#postProcessBeforeInitialization修改对象、包装对象初始化前PostConstruct、InitializingBean初始化缓存、校验配置初始化后BeanPostProcessor#postProcessAfterInitializationAOP 自动代理就发生在这里销毁前PreDestroy、DisposableBean释放连接、线程池我实际排查过一个线上问题一个 Bean 里的静态配置始终是旧值最后发现是有同事在PostConstruct里做了异步初始化容器还没初始化完另一个线程已经读到旧值。理解了生命周期这种问题就不难定位。2.2 依赖注入的三种方式怎么选Spring 支持构造器注入、setter注入和字段注入三种方式。代码写起来字段注入最爽一个Autowired搞定。但在真正的工程实践里我强烈建议优先使用构造器注入。构造器注入的好处是显而易见的不可变性依赖在对象创建时就必须给齐对象在后续生命周期里不会被偷换。强校验容器在启动阶段就能发现循环依赖或缺失依赖而不是运行时才炸。方便测试用构造函数直接 new 对象不需要反射设置私有字段。字段注入的问题在于它隐藏了依赖关系而且容易在不经意间产生循环依赖。Spring 虽然能处理循环依赖但不能滥用。我看到过一些老项目一个 Service 类里十几个字段全是Autowired这种类已经变成了上帝类维护成本极高。2.3 Spring 三级缓存到底三级在哪关于循环依赖Spring 面试题几乎必问为什么三级缓存能解决循环依赖为什么不是二级先明确概念。循环依赖指的是 A 依赖 BB 又依赖 A。Spring 处理单例 Bean 的循环依赖靠的是三个缓存一级缓存singletonObjects存放创建完成的单例 Bean。二级缓存earlySingletonObjects存放提前暴露的半成品 Bean。三级缓存singletonFactories存放ObjectFactory可以从工厂中提前拿到包装过的早期引用。创建流程简化描述创建 AA 实例化完成后放入三级缓存然后开始填充属性发现需要 B于是去创建 BB 实例化后也要填充属性发现需要 A这时从三级缓存拿到 A 的工厂调用工厂得到 A 的早期引用放入二级缓存B 拿到 A完成创建回到 A继续完成剩余属性填充和初始化最后放入一级缓存。为什么三级而不是三级不够关键在于AOP 代理。如果 A 需要被代理那么 B 持有的 A 应该是代理对象而不是原始对象。三级缓存放的是ObjectFactory它可以在返回早期引用前决定是直接返回原始对象还是返回代理对象。如果把二级缓存直接放对象那么 B 拿到的可能是未经过代理的原始对象最终 A 的代理对象被放入一级缓存B 里存的是原对象两边引用就不一致了程序会出现诡异行为。我见过一个比较形象的口诀一级存成品二级存半成品三级存工厂工厂能帮你做代理。这句话理解了循环依赖就通了一大半。3. AOP 的底层是代理JDK 动态代理与 CGLIB 的取舍3.1 Spring AOP 凭什么能在方法前后插入逻辑Spring AOP 的实现原理可以压缩成一句话用代理对象替换真实对象在代理里织入切面逻辑。框架本身不修改目标类的字节码文件而是在运行时生成代理类。代理有两种实现方式JDK 动态代理目标类必须实现接口代理类也实现同一接口通过java.lang.reflect.Proxy生成一个实现了该接口的代理对象在InvocationHandler#invoke里织入切面逻辑。CGLIB 代理目标是普通类通过继承目标类生成子类在子类中重写父类方法从而织入逻辑。因为继承的关系目标方法不能被final修饰否则无法重写。Spring AOP 默认选择规则是如果目标对象实现了接口优先 JDK 动态代理反之使用 CGLIB。Spring Boot 2.x 之后默认遇到有接口的 Bean 也强制使用 CGLIB准确说法是 Spring Boot 2.x 默认spring.aop.proxy-target-classtrue也就是优先 CGLIB。如果有代理冲突通过配置或EnableTransactionManagement(proxyTargetClass true)控制。对比项JDK 动态代理CGLIB前提条件目标类必须实现接口目标类可以不实现接口生成方式JVM 反射生成代理类字节码库生成目标类子类性能代理创建快调用慢一点代理创建慢调用快一点限制只代理接口中的方法不能代理 final 类或 final 方法定位方式通过接口类型拿到代理对象通过类类型拿到代理对象这里给一个真实坑如果你的目标对象是 CGLIB 代理代码里使用target.getClass()拿到的并不是你自己的业务类而是那个$$EnhancerBySpringCGLIB子类。做类型转换时如果不使用接口类型极容易抛ClassCastException。所以面向接口编程不是一句口号在 Spring 里这是实打实的坑。3.2 切点表达式与通知类型一次写明白Spring AOP 的语法并不复杂难在切点表达式是否能精确命中。我用一个实际例子说明。假设我要给com.example.service.OrderService下所有public方法加日志Aspect Component public class LogAspect { // 切点OrderService 类下的所有 public 方法 Pointcut(execution(public * com.example.service.OrderService.*(..))) public void orderServiceLogPointcut() { } // 环绕通知 Around(orderServiceLogPointcut()) public Object around(ProceedingJoinPoint joinPoint) throws Throwable { String methodName joinPoint.getSignature().getName(); long start System.currentTimeMillis(); try { return joinPoint.proceed(); } finally { long cost System.currentTimeMillis() - start; System.out.println(方法 methodName 耗时 cost ms); } } }通知类型有五种每一种对应不同的时机Before方法执行前适合做权限校验、参数校验。AfterReturning方法正常返回后适合记录返回值、统计成功次数。AfterThrowing方法抛异常后适合异常通知和报警。After无论成功失败都会执行类似 finally适合释放资源。Around最强大可以控制方法是否执行、修改返回值、包裹前后逻辑。切点表达式不仅支持execution还有within、annotation、args等指示器。日常中最常用的组合是annotation因为基于自定义注解的切点不够精确且不会误伤。我在真实项目里更愿意用自定义注解 AOP的方式。因为execution表达式控制粒度较粗写在类名上容易把所有方法都命中包括一些不需要处理的方法。自定义注解可以精确标注到每个方法比如OpLog(创建订单)切面里读取注解属性作为日志内容。3.3 代理失效的三个经典场景AOP 是不是只要加了切面就一定会生效不是。我把最容易踩的三个场景列在这里自调用绕过代理A 类的methodA内部直接调用this.methodB()this指向的是原始对象不是代理对象所以 methodB 上的切面不会生效。解决方式是把 methodB 拆到另一个 Bean或者注入ApplicationContext通过getBean拿到代理对象或者通过AopContext.currentProxy()。非 public 方法Spring AOP 依赖代理JDK 动态代理只能代理接口方法CGLIB 虽然能重写方法但对非public方法的拦截受限默认不处理非 public 方法导致切面不生效。final 方法被 CGLIB 限制目标类被 CGLIB 代理时final方法无法被子类重写切面自然无效。我处理过最隐蔽的一次自调用 bug一个 Service 类里createOrder方法调用了同一个类的sendMessage方法事务注解加在sendMessage上结果是消息发送根本没走事务代理导致数据库操作和消息发送不在同一个事务里。排查的时候先在代码里看到this.sendMessage()立刻定位到问题。自调用是 AOP 失效的第一大元凶没有之一。4. 声明式事务、日志切面、鉴权切面AOP 的实际项目应用4.1 Transactional 是 AOP 最经典的应用很多人每天用Transactional却不知道它底层就是 AOP。Spring 通过事务切面拦截被Transactional标注的方法在方法开始前开启事务在执行成功后提交在抛异常后回滚。这里有三个高频坑我挨个说透方法必须由代理对象调用自己调自己事务失效前面讲过。异常被 catch 掉方法内部 catch 了异常并吃掉事务切面感知不到异常不会回滚数据就脏了。默认只回滚 RuntimeException 和 Error受检异常默认不回滚想让受检异常也回滚必须配置rollbackFor Exception.class。我遇到过这样一个案例一个导入订单的方法内部循环处理一万条数据每条数据try-catch记录错误最后把错误汇总写到一张表里。方法上加了Transactional期望是任何一条数据出错整个事务回滚。但实际上异常在 catch 里被吞掉事务感知不到全部提交了。最后解决方案是抛出一个自定义运行时异常并且在外层统计失败数量失败数量大于零就显式回滚。理解 AOP 之后你会明白Transactional不是魔法它只是代理模式的一种应用。4.2 用自定义注解 AOP 实现操作日志切面在业务系统里审计日志是非常常见的需求。我的做法是不侵入业务代码做一个操作日志切面。先定义注解Target(ElementType.METHOD) Retention(RetentionPolicy.RUNTIME) public interface OpLog { String module() default ; String action() default ; }然后在切面里解析注解记录操作人、目标方法、参数、耗时和结果。Aspect Component public class OpLogAspect { Around(annotation(opLog)) public Object record(ProceedingJoinPoint joinPoint, OpLog opLog) throws Throwable { long start System.currentTimeMillis(); Object result joinPoint.proceed(); MethodSignature signature (MethodSignature) joinPoint.getSignature(); String methodName signature.getName(); Object[] args joinPoint.getArgs(); // 把操作人、module、action、methodName、args、耗时、result 落库 saveLog(opLog.module(), opLog.action(), methodName, args, result); return result; } }这样的好处是业务方法上只增加一行OpLog(module 订单, action 创建订单)没有任何和日志相关的杂代码。日志系统以后要加字段只改切面不用改各个业务类。我在多个项目里就用这一套足够支撑中等规模系统的审计需求。4.3 用 AOP 做幂等校验与权限控制除了日志另一个高频 AOP 应用是防重复提交。场景是用户快速点击下单按钮导致同一订单被创建两次。我用一个RepeatSubmit注解加在提交方法上切面里基于用户 ID 加业务流水号作为 Redis key设置几秒过期时间第一次进来执行几秒内再次进来直接拦截。Aspect Component public class RepeatSubmitAspect { Before(annotation(repeatSubmit)) public void check(JoinPoint joinPoint, RepeatSubmit repeatSubmit) { // 根据 userId 业务唯一键拼 key // 调用 Redis SETNX如果已经存在抛异常 } }AOP 做权限控制也适合用在细粒度权限场景比如方法级权限校验。但要注意AOP 并不是万能的它适合单方法的横切逻辑不适合跨几个模块之间的复杂流程编排。如果一个切面要同时访问多个服务、处理复杂的状态流转那么代码会变得极其难懂。这时候我会选择显式调用把逻辑放在业务层里而不是硬塞进切面。5. 手写一个极简 Spring从零搭建 IoC 容器与 AOP5.1 实现一个简化版 IoC 容器纸上得来终觉浅我建议每个认真学 Spring 的人都试着写一个迷你版容器。不需要多严谨能跑通基本流程即可但你会获得完全不同的理解深度。第一步定义一个注解Target(ElementType.TYPE) Retention(RetentionPolicy.RUNTIME) public interface MyComponent { }第二步实现一个简单容器扫描包路径下的所有类找到标注了MyComponent的类通过反射实例化并放入一个 Mappublic class MyApplicationContext { private MapClass?, Object beanMap new ConcurrentHashMap(); public MyApplicationContext(String packageName) throws Exception { // 扫描 packageName 路径下所有类 // 过滤出标有 MyComponent 的类 // 调用无参构造器实例化 // 注入依赖遍历字段找 MyAutowired 字段 } public T T getBean(ClassT clazz) { return clazz.cast(beanMap.get(clazz)); } }注入的逻辑就是在实例化完成后遍历每个字段如果字段标了注入注解就从 beanMap 中取出对应实例通过反射set进去。这个极简版本没有解决构造器循环依赖但能让你直观感受到 IoC 的核心流程。5.2 给容器加上 AOP 代理能力容器具备了基本能力后就可以加 AOP。最简洁的做法是在实例化阶段之后增加一个代理包装环节。如果某个类标注了MyTransactional注解就通过 JDK 动态代理创建代理对象然后在代理对象里拦截方法在方法执行前后模拟事务语义。public class JdkProxyFactory { public static Object createProxy(Object target) { return Proxy.newProxyInstance( target.getClass().getClassLoader(), target.getClass().getInterfaces(), (proxy, method, args) - { System.out.println(开启事务); Object result method.invoke(target, args); System.out.println(提交事务); return result; } ); } }把这个代理对象放入 beanMap容器对外提供的就是代理对象。你会发现从使用者的角度看业务代码完全感知不到代理的存在调用方拿到的 Bean 已经是增强后的版本。这个无感知正是 Spring AOP 的核心体验。5.3 手写过程中领悟到的 Spring 设计智慧手写之后有几个细节让我对 Spring 的敬畏感更明显了Spring 没有魔法全是设计。三级缓存也好BeanPostProcessor 也好都是用非常朴素的集合和回调机制组合出来的。好的框架尽量推迟决策。Spring 把很多逻辑抽象成接口比如BeanPostProcessor、FactoryBean让使用者可以在关键节点介入这才是框架的生命力所在。AOP 与 IoC 是天然配合的。脱离了 IoC 容器AOP 很难做到对调用方完全透明脱离了 AOPIoC 容器里的 Bean 也很难被统一增强。两者配合才形成了 Spring 的完整威力。在面试中如果你能说出类似我手写过迷你版容器发现 Spring 的关键在于把扩展点暴露给用户这种话面试官通常会眼前一亮因为这说明你是真正研究过原理而不是只背概念。6. 面试高频题与真实项目里的避坑总结6.1 面试时怎么讲 IoC 才能拿高分面试官问什么是 IoC很多人的回答是把对象的创建交给 Spring 容器这个回答只能得基础分。高分的回答应该包含三层第一层控制权反转容器管理对象的创建和依赖注入。第二层在 Spring 中的具体实现BeanFactory与ApplicationContext的关系Bean 生命周期。第三层扩展点BeanPostProcessor、BeanFactoryPostProcessor能干什么甚至能提到三级缓存解决循环依赖。面试官再追问三级缓存为什么要三级你能解释出 AOP 代理与循环依赖之间的关系就和其他候选人拉开差距了。这里不建议背源码建议理解后用自己的话讲核心要点是三级缓存能够在 Bean 未完全初始化前通过ObjectFactory决定返回原对象还是代理对象保证最终所有引用一致。6.2 面试时怎么讲 AOP 才不显浅讲 AOP 也是一样不要只背概念。用我自己的话是这么组织的Spring AOP 基于代理模式通过 JDK 动态代理或 CGLIB 在运行时生成代理对象把切面逻辑织入到业务方法前后。它适合处理日志、事务、权限这类横切逻辑。在使用中需要注意的是代理只在通过容器获取 Bean 时生效自调用、非 public 方法、final 方法会导致代理失效同时我会优先用自定义注解做切点让切面精确控制粒度。这段话把原理、应用、坑都串起来了面试官只要顺着往下问你都能接住。6.3 我在真实项目里踩过的几个坑最后写点实战教训这些可能在你读过的教科书里没有。坑一事务方法里调用异步方法事务直接失效。一次排查发现一个事务方法里调用了Async的方法异步线程里做数据库写入主线程事务已经提交了异步线程还没执行完数据状态错乱。后来把异步调用和事务方法拆开各自独立控制边界问题解决。根源在于Async本身也是通过 AOP 实现的代理增强两个代理叠加时执行顺序和线程绑定关系极其容易搞混。坑二切面表达式写太宽系统性能直线下降。曾经有人把切点写成execution(* com.example..*.*(..))结果启动后所有方法都被切面包裹日志量暴增接口变慢。切面不是越宽越好它的粒度应该和需求一一对应宁可多写几个注解也不要做大而全的切点。坑三循环依赖虽然 Spring 能解决但改起来依然心累。有一次代码用到构造器循环依赖Spring 启动直接报错。我花了一个多小时拆依赖最后明白了一件事Spring 的三级缓存只解决单例模式下非构造器注入的循环依赖设计代码时应当尽量避免循环依赖而不是依赖容器兜底。坑四CGLIB 代理对象与getClass的坑。有一次在代码里通过bean.getClass()然后去取自定义注解发现取不到因为方法是被 CGLIB 重写过的要让代理暴露目标类信息需要使用AnnotationUtils并注意Inherited的影响。后来改用AopUtils.getTargetClass(bean)才拿到底层真实类。写在最后的一点体会我一直觉得Spring 最厉害的地方不是功能多而是把复杂问题包装成简单接口的同时还留下了足够的后门让你深挖。理解 IoC 和 AOP不应该停留在会用注解上而是要把它们背后的对象生命周期、代理机制和设计取舍想通。我见过不少工作了五六年的开发者能熟练写业务但遇到一个诡异问题就无从下手归根到底还是基础没打通。希望这篇长文能给你一个相对完整的切入路径下次再碰到 Spring 相关的疑难杂症你不妨从这里是不是 IoC 容器在做怪这里是不是 AOP 代理失效了这两个角度去猜大概率能少走很多弯路。