Resilience4j 的 @Bulkhead 依赖 Spring AOP 代理机制实现熔断与并发控制；当在同一个类中直接调用带 @Bulkhead 注解的方法时，因绕过代理对象（this 调用），切面逻辑不生效，导致并发限制失效，方法退化为同步执行。
resilience4j 的 `@bulkhead` 依赖 spring aop 代理机制实现熔断与并发控制；当在同一个类中直接调用带 `@bulkhead` 注解的方法时，因绕过代理对象（`this` 调用），切面逻辑不生效，导致并发限制失效，方法退化为同步执行。
Resilience4j 是 Spring 生态中主流的轻量级容错库，其 @Bulkhead 注解用于限制方法的并发执行数（如信号量或线程池模式），防止下游服务过载。但该能力并非“魔法”，其底层完全依托 Spring 的 AOP 代理机制——只有通过 Spring 容器管理的代理对象发起的方法调用，才能触发 Resilience4j 注册的 BulkheadAspect 拦截器；而同一类内的 this.testBulkhead() 调用，是 JVM 层面的普通 Java 方法调用，完全绕过代理链，因此 @Bulkhead 形同虚设。
? 为什么同类调用会失效？
根本原因在于 Spring 的代理模型：
- Spring 为标注
@Bulkhead的 Bean 创建代理（JDK Proxy 或 CGLIB）； - 代理对象在方法入口处织入
Bulkhead逻辑（检查许可、阻塞/拒绝、统计计数等）； - 但
this.testBulkhead()是目标对象自身的直接调用，不经过代理，等价于跳过了所有切面； - 这与
@Async、@Transactional、@Retryable等注解失效原理完全一致，是 Spring AOP 的固有约束（官方称 self-invocation problem）。
✅ 正确实践：确保跨 Bean 调用
以下为生产环境推荐的三种可靠方案：
方案一：拆分服务（推荐 ★★★）
将带 @Bulkhead 的方法提取至独立 Service，并注入调用：
@Service
public class BulkheadService {
private static final String USER_SERVICE = "user-service";
@GetMapping("/bulkhead")
@Bulkhead(name = USER_SERVICE, fallbackMethod = "bulkheadDefault")
public ResponseEntity<string> testBulkhead() {
logger.info("call " + Thread.currentThread().getName());
String response = restTemplate.getForObject(BASEURL_BULKHEAD, String.class);
logger.info(LocalTime.now() + " Call processing finished = " + Thread.currentThread().getName());
return ResponseEntity.ok(response);
}
public ResponseEntity<string> bulkheadDefault(Throwable throwable) {
return ResponseEntity.status(503).body("Service unavailable due to bulkhead limit");
}
}
@Service
public class UserServiceApplication {
@Autowired
private BulkheadService bulkheadService;
// ✅ 正确：跨 Bean 调用，代理生效
public void triggerBulkhead() {
for (int i = 0; i bulkheadService.testBulkhead()).start();
}
}
}</string></string>
方案二：自我注入（Self-Injection）
启用代理暴露并注入自身代理对象（需配置 @EnableAspectJAutoProxy(exposeProxy = true)）：
@Configuration
@EnableAspectJAutoProxy(exposeProxy = true) // 关键：允许获取当前代理
public class AppConfig { }
@Service
public class UserServiceApplication {
@Autowired
private UserServiceApplication self; // 自我注入代理对象
@GetMapping("/bulkhead")
@Bulkhead(name = "user-service", fallbackMethod = "bulkheadDefault")
public ResponseEntity<string> testBulkhead() {
// ... 实现同上
}
public void triggerBulkhead() {
for (int i = 0; i {
// ✅ 通过代理调用：AopContext.currentProxy() 返回当前代理
UserServiceApplication proxy = (UserServiceApplication) AopContext.currentProxy();
proxy.testBulkhead();
}).start();
}
}
}</string>
⚠️ 注意：
AopContext.currentProxy()仅在exposeProxy = true且线程上下文未被重置（如异步线程中需手动传递）时有效，适用于简单场景，不建议在复杂异步链路中使用。
方案三：显式调用 BulkheadRegistry（最灵活）
绕过注解，直接编程式使用 Resilience4j 的 Bulkhead 实例：
@Service
public class UserServiceApplication {
@Autowired
private BulkheadRegistry bulkheadRegistry;
public void triggerBulkhead() {
Bulkhead bulkhead = bulkheadRegistry.bulkhead("user-service");
for (int i = 0; i {
try {
// 手动申请许可
if (bulkhead.tryAcquirePermission()) {
try {
ResponseEntity<string> result = testBulkheadCore();
logger.info("Success: {}", result.getBody());
} finally {
bulkhead.onComplete(); // 释放许可
}
} else {
logger.warn("Bulkhead rejected request - max concurrent reached");
throw new BulkheadFullException("Bulkhead is full");
}
} catch (Exception e) {
logger.error("Bulkhead execution failed", e);
}
}).start();
}
}
// 核心逻辑剥离为无注解方法
private ResponseEntity<string> testBulkheadCore() {
logger.info("call " + Thread.currentThread().getName());
String response = restTemplate.getForObject(BASEURL_BULKHEAD, String.class);
logger.info(LocalTime.now() + " Call processing finished = " + Thread.currentThread().getName());
return ResponseEntity.ok(response);
}
}</string></string>
? 关键注意事项
- ✅ 必须确保
@Bulkhead方法所在类由 Spring 管理（如@Service），且调用方也通过 Spring 注入（非new实例）； - ✅
fallbackMethod必须在同一类中，且签名兼容（相同参数 +Throwable或子类）； - ❌ 避免在
@Controller中直接定义@Bulkhead方法并同类调用——应下沉至@Service层统一管控； - ? 若使用 Resilience4j Spring Boot Starter，请确认已添加依赖并启用自动配置：
<dependency><groupid>io.github.resilience4j</groupid><artifactid>resilience4j-spring-boot2</artifactid><version>1.7.1</version><!-- 建议使用 1.7.x+ 兼容 Spring Boot 2.7+/3.x --></dependency>
综上，@Bulkhead 同类调用失效不是 Bug，而是 Spring AOP 设计使然。坚持“切面能力只对代理调用生效”这一原则，合理划分职责边界（如拆分服务），即可稳定发挥 Resilience4j 的并发保护能力。
