【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 List<Object> 缓存列表 = 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 ThreadLocal<String> 用户上下文 = 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 自然就会消失。
技术没有银弹，只有对细节的敬畏。
散会。
