【Spring性能调优系列】第1讲AOP动态代理性能瓶颈导致Full GC故障排查前言生产环境中AOP 切面一旦覆盖高频接口代理对象创建、方法拦截和上下文对象堆积都可能放大 GC 压力。接口耗时升高、Full GC 变频繁、老年代持续上涨往往不是单一代码泄漏而是代理链路和对象生命周期共同造成的性能问题。本文围绕 Spring AOP 动态代理的内存开销、调用链路和排查方法分析如何定位由代理使用不当引发的 Full GC 故障。一、底层原理1.1 核心机制Spring AOP 的本质就是给目标对象穿了一层“隐身衣”。你调用的不是原对象而是代理对象。这层衣服平时没事但穿的人多了衣服就成累赘了。我们常用的有两种代理方式JDK 动态代理和 CGLIB。JDK 基于接口CGLIB 基于继承。在高频调用的场景下如果代理对象的生命周期管理不当它们就会在新生代里“赖着不走”。一旦新生代装不下它们就会被强行晋升到老年代。老年代空间有限一旦被塞满JVM 就只能触发 Full GC 来清理。如果清理不掉服务就崩了。下面这张图展示了代理对象在内存中的“流浪”路径。sequenceDiagram participant 调用者 participant 容器 as Spring 容器 participant 代理工厂 as 代理工厂 participant 目标对象 as 目标对象 Bean participant 内存 as JVM 内存 调用者-容器获取 Bean 容器-代理工厂检查是否需要代理 代理工厂--容器返回代理对象 容器--调用者交付代理对象 调用者-代理对象执行方法 代理对象-目标对象调用实际业务 Note over 代理对象目标对象若代理对象被静态集合持有br/则无法被 GC 回收 代理对象--调用者返回结果设计优势在于解耦但劣势在于引入了额外的对象引用链。如果开发者没意识到代理对象也是对象也会占用堆内存那就容易翻车。1.2 与同类方案的对比为了让大家更直观地理解我们对比一下几种常见的代理方案。方案实现方式性能表现内存占用特征适用场景JDK 动态代理基于接口较快生成代理类内存占用低目标类实现了接口CGLIB基于继承略慢 (首次)生成子类内存占用略高目标类无接口静态代理手动编写最快无额外代理对象简单业务不推荐看到没CGLIB 因为要生成子类在高频创建场景下对元空间Metaspace和堆内存的压力都比 JDK 大。但这次故障的根源不在于谁快谁慢而在于对象“活”得太久了。二、快速上手别光听理论咱们先写个最简单的 Demo 感受一下。这个示例模拟了一个高频调用的日志切面。代码很短但能跑通三分钟见效。// 定义一个简单的业务接口 public interface 用户服务接口 { void 登录(String 用户名); } // 实现类 public class 用户服务实现 implements 用户服务接口 { Override public void 登录(String 用户名) { System.out.println(用户 用户名 正在登录...); } } // 切面类 Aspect Component public class 日志切面 { Before(execution(* com.example.service.*.*(..))) public void 记录日志() { // 模拟一些耗时操作 try { Thread.sleep(1); } catch (Exception e) {} } }在 Spring 容器中当你注入用户服务实现时实际拿到的是代理对象。只要这个 Bean 是单例的通常没问题。问题出在“非单例”或者“意外持有”上。三、核心 API / 深水区3.1 核心方法速查搞懂 AOP这几个注解和工具类你得门儿清。核心组件作用生产级注意事项Aspect标记切面类确保该类被 Spring 扫描到Pointcut定义切点表达式表达式写错会导致切面不生效AopContext获取当前代理对象慎用自调用会失效EnableAspectJAutoProxy开启 AOP 支持通常由SpringBootApplication包含3.2 生产级配置在生产环境默认配置往往不够用。特别是proxyTargetClass这个参数。spring: aop: auto: true proxy-target-class: true # 强制使用 CGLIB为什么要强制 CGLIB因为很多老代码里业务类根本没写接口。如果不强制Spring 可能会 fallback 到 JDK 代理导致行为不一致。但要注意开启 CGLIB 后内存占用会微增需监控元空间。3.3 高级定制有时候我们需要在代理对象创建时做点手脚。比如给代理对象加个 ID方便追踪。这时候可以用Advisor或者自定义BeanPostProcessor。但千万别在BeanPostProcessor里做耗时操作。那是容器启动的咽喉堵住了整个应用都起不来。四、实战演练接下来是本次故障的“案发现场”还原。当时我们的代码长这样看起来没啥毛病其实暗藏杀机。Component public class 订单处理服务 { // 这是一个静态集合用来缓存一些临时数据 private static final ListObject 缓存列表 new ArrayList(); Autowired private 用户服务接口 用户服务; public void 处理订单(String 订单号) { // 坑点在这里每次处理订单都往静态列表里塞一个代理对象 // 这个代理对象引用了用户服务导致用户服务的代理对象无法被回收 缓存列表.add(用户服务); 用户服务.登录(测试用户); // 注意这里没有 remove列表只增不减 // 随着订单量增加老年代迅速被填满 } }这段代码的问题极其隐蔽。用户服务本身是单例 Bean通常没问题。但把它塞进static集合就等于给垃圾堆上了锁。GC Root 会一直引用着这个集合集合里又引用着代理对象。代理对象想死门都没有。这就是典型的“对象持续晋升”。新生代装不下了就进老年代。老年代也装不下了就 Full GC。Full GC 清理不掉就 OOM。五、避坑指南与最佳实践踩了这么多坑总结几条血泪经验。技巧一警惕静态引用永远不要把 Spring 管理的 Bean 塞进静态变量里。除非你非常清楚自己在做什么并且手动管理生命周期。⚠️警告自调用失效在类内部调用带 AOP 的方法代理不会生效。public void 方法 A() { 方法 B(); // 这里不会触发 B 的切面 } Async public void 方法 B() { // ... }想要生效必须通过代理对象调用或者把方法 B抽离到另一个 Service 中。✅推荐使用 ThreadLocal 替代静态集合如果非要存临时数据用ThreadLocal。请求结束数据自动清理不会污染老年代。private static final ThreadLocalString 用户上下文 new ThreadLocal(); public void 执行() { 用户上下文.set(当前用户); try { // 业务逻辑 } finally { 用户上下文.remove(); // 必须清理防止内存泄漏 } }六、综合实战演示最后给大家看一套修正后的、符合生产规范的代码。这套代码解决了内存泄漏问题并且加入了异常处理和超时控制。Component public class 安全订单处理服务 { // 不再使用静态集合改用局部变量或 ThreadLocal private static final ThreadLocal 用户服务接口 当前用户服务 new ThreadLocal(); Autowired private 用户服务接口 用户服务 Bean; Transactional(rollbackFor Exception.class) public void 处理订单(String 订单号) { // 1. 设置上下文 当前用户服务.set(用户服务 Bean); try { // 2. 设置超时控制 // 实际生产中建议使用 Resilience4j 或 Sentinel if (!执行超时检查()) { throw new BusinessException(处理超时); } // 3. 执行业务 用户服务 Bean.登录(订单关联用户); System.out.println(订单 订单号 处理成功); } catch (Exception e) { // 4. 异常处理与日志记录 System.err.println(订单处理失败 e.getMessage()); throw new BusinessException(订单处理异常, e); } finally { // 5. 关键清理 ThreadLocal防止内存泄漏 当前用户服务.remove(); } } private boolean 执行超时检查() { // 模拟超时检查逻辑 return true; } }这段代码的核心在于finally块中的remove()。这就像进更衣室换衣服出来时必须把衣服挂回原处。不然更衣室迟早被堆满后面的人就没地方换了。七、总结这次故障给我们上了一课。AOP 是利器但也是双刃剑。代理对象也是对象它也要占内存也要被 GC 回收。只要切断了不必要的引用链Full GC 自然就会消失。技术没有银弹只有对细节的敬畏。散会。
【Spring性能调优系列】第1讲：AOP动态代理性能瓶颈导致Full GC故障排查
【Spring性能调优系列】第1讲AOP动态代理性能瓶颈导致Full GC故障排查前言生产环境中AOP 切面一旦覆盖高频接口代理对象创建、方法拦截和上下文对象堆积都可能放大 GC 压力。接口耗时升高、Full GC 变频繁、老年代持续上涨往往不是单一代码泄漏而是代理链路和对象生命周期共同造成的性能问题。本文围绕 Spring AOP 动态代理的内存开销、调用链路和排查方法分析如何定位由代理使用不当引发的 Full GC 故障。一、底层原理1.1 核心机制Spring AOP 的本质就是给目标对象穿了一层“隐身衣”。你调用的不是原对象而是代理对象。这层衣服平时没事但穿的人多了衣服就成累赘了。我们常用的有两种代理方式JDK 动态代理和 CGLIB。JDK 基于接口CGLIB 基于继承。在高频调用的场景下如果代理对象的生命周期管理不当它们就会在新生代里“赖着不走”。一旦新生代装不下它们就会被强行晋升到老年代。老年代空间有限一旦被塞满JVM 就只能触发 Full GC 来清理。如果清理不掉服务就崩了。下面这张图展示了代理对象在内存中的“流浪”路径。sequenceDiagram participant 调用者 participant 容器 as Spring 容器 participant 代理工厂 as 代理工厂 participant 目标对象 as 目标对象 Bean participant 内存 as JVM 内存 调用者-容器获取 Bean 容器-代理工厂检查是否需要代理 代理工厂--容器返回代理对象 容器--调用者交付代理对象 调用者-代理对象执行方法 代理对象-目标对象调用实际业务 Note over 代理对象目标对象若代理对象被静态集合持有br/则无法被 GC 回收 代理对象--调用者返回结果设计优势在于解耦但劣势在于引入了额外的对象引用链。如果开发者没意识到代理对象也是对象也会占用堆内存那就容易翻车。1.2 与同类方案的对比为了让大家更直观地理解我们对比一下几种常见的代理方案。方案实现方式性能表现内存占用特征适用场景JDK 动态代理基于接口较快生成代理类内存占用低目标类实现了接口CGLIB基于继承略慢 (首次)生成子类内存占用略高目标类无接口静态代理手动编写最快无额外代理对象简单业务不推荐看到没CGLIB 因为要生成子类在高频创建场景下对元空间Metaspace和堆内存的压力都比 JDK 大。但这次故障的根源不在于谁快谁慢而在于对象“活”得太久了。二、快速上手别光听理论咱们先写个最简单的 Demo 感受一下。这个示例模拟了一个高频调用的日志切面。代码很短但能跑通三分钟见效。// 定义一个简单的业务接口 public interface 用户服务接口 { void 登录(String 用户名); } // 实现类 public class 用户服务实现 implements 用户服务接口 { Override public void 登录(String 用户名) { System.out.println(用户 用户名 正在登录...); } } // 切面类 Aspect Component public class 日志切面 { Before(execution(* com.example.service.*.*(..))) public void 记录日志() { // 模拟一些耗时操作 try { Thread.sleep(1); } catch (Exception e) {} } }在 Spring 容器中当你注入用户服务实现时实际拿到的是代理对象。只要这个 Bean 是单例的通常没问题。问题出在“非单例”或者“意外持有”上。三、核心 API / 深水区3.1 核心方法速查搞懂 AOP这几个注解和工具类你得门儿清。核心组件作用生产级注意事项Aspect标记切面类确保该类被 Spring 扫描到Pointcut定义切点表达式表达式写错会导致切面不生效AopContext获取当前代理对象慎用自调用会失效EnableAspectJAutoProxy开启 AOP 支持通常由SpringBootApplication包含3.2 生产级配置在生产环境默认配置往往不够用。特别是proxyTargetClass这个参数。spring: aop: auto: true proxy-target-class: true # 强制使用 CGLIB为什么要强制 CGLIB因为很多老代码里业务类根本没写接口。如果不强制Spring 可能会 fallback 到 JDK 代理导致行为不一致。但要注意开启 CGLIB 后内存占用会微增需监控元空间。3.3 高级定制有时候我们需要在代理对象创建时做点手脚。比如给代理对象加个 ID方便追踪。这时候可以用Advisor或者自定义BeanPostProcessor。但千万别在BeanPostProcessor里做耗时操作。那是容器启动的咽喉堵住了整个应用都起不来。四、实战演练接下来是本次故障的“案发现场”还原。当时我们的代码长这样看起来没啥毛病其实暗藏杀机。Component public class 订单处理服务 { // 这是一个静态集合用来缓存一些临时数据 private static final ListObject 缓存列表 new ArrayList(); Autowired private 用户服务接口 用户服务; public void 处理订单(String 订单号) { // 坑点在这里每次处理订单都往静态列表里塞一个代理对象 // 这个代理对象引用了用户服务导致用户服务的代理对象无法被回收 缓存列表.add(用户服务); 用户服务.登录(测试用户); // 注意这里没有 remove列表只增不减 // 随着订单量增加老年代迅速被填满 } }这段代码的问题极其隐蔽。用户服务本身是单例 Bean通常没问题。但把它塞进static集合就等于给垃圾堆上了锁。GC Root 会一直引用着这个集合集合里又引用着代理对象。代理对象想死门都没有。这就是典型的“对象持续晋升”。新生代装不下了就进老年代。老年代也装不下了就 Full GC。Full GC 清理不掉就 OOM。五、避坑指南与最佳实践踩了这么多坑总结几条血泪经验。技巧一警惕静态引用永远不要把 Spring 管理的 Bean 塞进静态变量里。除非你非常清楚自己在做什么并且手动管理生命周期。⚠️警告自调用失效在类内部调用带 AOP 的方法代理不会生效。public void 方法 A() { 方法 B(); // 这里不会触发 B 的切面 } Async public void 方法 B() { // ... }想要生效必须通过代理对象调用或者把方法 B抽离到另一个 Service 中。✅推荐使用 ThreadLocal 替代静态集合如果非要存临时数据用ThreadLocal。请求结束数据自动清理不会污染老年代。private static final ThreadLocalString 用户上下文 new ThreadLocal(); public void 执行() { 用户上下文.set(当前用户); try { // 业务逻辑 } finally { 用户上下文.remove(); // 必须清理防止内存泄漏 } }六、综合实战演示最后给大家看一套修正后的、符合生产规范的代码。这套代码解决了内存泄漏问题并且加入了异常处理和超时控制。Component public class 安全订单处理服务 { // 不再使用静态集合改用局部变量或 ThreadLocal private static final ThreadLocal 用户服务接口 当前用户服务 new ThreadLocal(); Autowired private 用户服务接口 用户服务 Bean; Transactional(rollbackFor Exception.class) public void 处理订单(String 订单号) { // 1. 设置上下文 当前用户服务.set(用户服务 Bean); try { // 2. 设置超时控制 // 实际生产中建议使用 Resilience4j 或 Sentinel if (!执行超时检查()) { throw new BusinessException(处理超时); } // 3. 执行业务 用户服务 Bean.登录(订单关联用户); System.out.println(订单 订单号 处理成功); } catch (Exception e) { // 4. 异常处理与日志记录 System.err.println(订单处理失败 e.getMessage()); throw new BusinessException(订单处理异常, e); } finally { // 5. 关键清理 ThreadLocal防止内存泄漏 当前用户服务.remove(); } } private boolean 执行超时检查() { // 模拟超时检查逻辑 return true; } }这段代码的核心在于finally块中的remove()。这就像进更衣室换衣服出来时必须把衣服挂回原处。不然更衣室迟早被堆满后面的人就没地方换了。七、总结这次故障给我们上了一课。AOP 是利器但也是双刃剑。代理对象也是对象它也要占内存也要被 GC 回收。只要切断了不必要的引用链Full GC 自然就会消失。技术没有银弹只有对细节的敬畏。散会。
