@circuitbreaker注解本身不依赖spring aop,而是通过spring boot自动配置+aspectj切面实现方法增强;其底层依赖spring aop代理机制拦截方法调用,在前后织入熔断逻辑,因java反射无法实现横切拦截,故必须借助代理完成状态检查、结果记录与异常处理。

Resilience4j 的 @CircuitBreaker 注解本身**不依赖 Spring AOP 或 CGLIB 代理**,而是通过 **Spring Boot 自动配置 + AspectJ 切面(基于代理)** 实现方法增强。它底层利用 Spring 的 AOP 机制,在运行时对标注了该注解的方法织入熔断逻辑,而非直接使用 Java 原生反射完成增强。
为什么不是纯反射代理?
Java 反射(java.lang.reflect)只能动态调用方法、读取注解,但**无法在不修改字节码或不借助代理的情况下拦截并增强方法执行流程**。熔断器需要在方法调用前检查状态、调用后记录结果、异常时触发状态转换——这必须通过**横切拦截**实现,而 Spring AOP 提供了标准且可配置的拦截能力。
实际增强过程是怎么发生的?
当 Spring 容器启动时,Resilience4j 会注册一个切面(CircuitBreakerAspect),该切面匹配所有标注 @CircuitBreaker 的方法。Spring 根据 Bean 类型决定代理方式:
你接手一个需求时,是不是经常这样:"改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续";这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境(JDK、Spring Boot、ORM、数据库、前端框架),记在
- 若目标类实现了接口,默认使用 JDK 动态代理(基于接口)
- 若目标类无接口或强制使用 CGLIB,则生成子类代理(需类非 final)
- 代理对象在调用目标方法前后,由切面插入熔断器的
recordSuccess()、recordFailure()等逻辑
关键依赖与启用条件
要让 @CircuitBreaker 生效,必须满足:
- 引入
resilience4j-spring-boot2(Spring Boot 2.x/3.x)或对应 starter - 确保目标方法是 public,且定义在 Spring 管理的 Bean 中(非 this. 调用)
- 避免在同一个类内 self-invocation(如 service 内部调用自己带注解的方法),此时代理失效
- 配置文件中启用熔断器(如
resilience4j.circuitbreaker.instances.myCB.baseConfig=default)
手动模拟类似逻辑(仅用于理解,不推荐替代)
如果想绕过 Spring AOP、用纯反射+包装实现简易熔断,可参考思路:
- 通过
Method.getAnnotation(CircuitBreaker.class)获取配置 - 用
CircuitBreaker.of(...)创建实例 - 封装调用:先
circuitBreaker.acquirePermission(),再反射执行原方法,最后根据结果调用onSuccess()或onFailure() - 注意:这种方式需自行管理线程安全、上下文传播、异常分类等,远不如 Spring AOP 集成健壮
真正起作用的是 Spring AOP 代理链,而不是注解自身触发反射调用。理解这一点,能避免误以为“加个注解就自动增强”,从而规避 self-invocation、private 方法无效、非 Spring Bean 失效等问题。
Java免费学习笔记:立即使用
解锁 Java 大师之旅:从入门到精通的终极指南










