Spring 7 @ConcurrencyLimit死锁风险解析：递归调用与虚拟线程实践指南

Spring 7 引入了 @ConcurrencyLimit 注解，作为“虚拟线程时代”的流量控制安全阀。然而，近期一些开发者在使用中发现了由其引发的死锁问题，尤其是在递归调用场景下。这提醒我们，任何新工具都需要深入理解其原理与边界。

@ConcurrencyLimit：虚拟线程时代的流量闸门

@ConcurrencyLimit 旨在防止应用在虚拟线程环境下产生并发爆炸，它并非全新发明，而是对 Spring 早期 ConcurrencyThrottleInterceptor 的现代化封装。其核心是实现了一个基于对象监视器（Monitor）和 wait()/notify() 的简单并发控制器。

核心机制：ConcurrencyThrottleInterceptor

其底层拦截器的简化逻辑揭示了工作原理：

public class ConcurrencyThrottleInterceptor implements MethodInterceptor {
    private final Object monitor = new Object();
    private int concurrencyCount = 0;
    private int concurrencyLimit = 1;

    protected void beforeAccess() {
        if (this.concurrencyLimit > 0) {
            synchronized (this.monitor) {
                // 自旋等待，直到获取许可
                while (this.concurrencyCount >= this.concurrencyLimit) {
                    try {
                        this.monitor.wait(); // 阻塞等待
                    } catch (InterruptedException ex) {
                        Thread.currentThread().interrupt();
                        throw new IllegalStateException("Interrupted");
                    }
                }
                this.concurrencyCount++; // 占用槽位
            }
        }
    }
    protected void afterAccess() {
        if (this.concurrencyLimit >= 0) {
            synchronized (this.monitor) {
                this.concurrencyCount--; // 释放槽位
                this.monitor.notify();   // 唤醒等待线程
            }
        }
    }
    @Override
    public Object invoke(MethodInvocation invocation) throws Throwable {
        beforeAccess();
        try {
            return invocation.proceed();
        } finally {
            afterAccess(); // 确保释放
        }
    }
}

机制简洁：全局计数器配合经典的生产者-消费者模式。但关键在于，它不具备可重入性。

可重入性与递归调用的死锁陷阱

由于计数器不识别线程身份，同一个线程在已获取一个许可后，无法再次获取。这在递归或方法间循环调用时会导致死锁。

模拟死锁场景：

@Service
public class RiskyService {
    @ConcurrencyLimit(1) // 串行化限制
    public void process(int depth) {
        System.out.println("Depth: " + depth);
        if (depth > 0) {
            process(depth - 1); // 递归调用：这里会死锁！
        }
    }
}

执行流程：

Thread-1: process(3) -> 获得许可，计数器=1
Thread-1: process(2) -> 尝试获取许可，但计数器仍为1，进入while循环等待
Thread-1: wait() -> 线程自己将自己永久阻塞！

即使并发限制大于1，只要递归深度或循环调用链消耗完所有许可，同样会引发死锁。

解决方案：

1. 重构代码，解耦控制与逻辑：将业务逻辑抽离到无注解的内部方法中。

   @Service
   public class SafeService {
       @ConcurrencyLimit(1)
       public void process(int depth) {
           doProcess(depth); // 内部方法负责递归
       }
       private void doProcess(int depth) {
           System.out.println("Depth: " + depth);
           if (depth > 0) {
               doProcess(depth - 1); // 安全递归
           }
       }
   }

2. 避免使用：对于存在重入可能的方法，应避免使用@ConcurrencyLimit。

虚拟线程与wait()的优化

在Spring 7 与虚拟线程（Java 21+）结合时，wait()的行为得到优化：当虚拟线程被阻塞时，其底层的载体线程（Carrier Thread）会被释放，供其他虚拟线程使用。这使得在高并发限制下的阻塞等待成本极低。

@ConcurrencyLimit 最佳实践十则

1. 科学设定限制值：根据任务类型（CPU密集型、IO密集型）和下游服务能力设置，而非随意猜测。
2. 提升控制层级：将并发控制上提至服务编排层，避免在受控方法内同步调用其他受控方法，防止嵌套死锁。
3. 虚拟线程适配：在虚拟线程环境下，可设置远高于平台线程的限制（如200+）。
4. 增强可观测性：考虑自定义拦截器或结合AOP暴露当前并发数、等待线程数等指标。
5. 实现超时控制：@ConcurrencyLimit本身不支持超时，需配合SimpleAsyncTaskExecutor.setTaskTerminationTimeout()或自定义逻辑实现，防止无限等待。
6. 明确拒绝策略：配置执行器在达到限制时明确拒绝任务，而非无限排队。
7. 理解作用域：类级别的注解使所有方法共享许可池；方法级别则各自独立。
8. 进行充分测试：编写并发测试，验证限制是否实际生效及最大并发数是否符合预期。
9. 与Resilience4j对比选型：简单场景或虚拟线程专属优化可用@ConcurrencyLimit；需要令牌桶、动态配置等复杂特性时，应选择Resilience4j等专业库。
10. 虚拟线程专属配置：为@Async任务配置虚拟线程执行器，并匹配其并发限制。

    @Configuration
    @EnableAsync
    public class VirtualThreadConfig {
        @Bean
        public SimpleAsyncTaskExecutor virtualThreadExecutor() {
            SimpleAsyncTaskExecutor executor = new SimpleAsyncTaskExecutor();
            executor.setVirtualThreads(true);
            executor.setConcurrencyLimit(500);
            return executor;
        }
    }

总结

@ConcurrencyLimit 是Spring为高并发虚拟线程环境提供的一个轻量级安全工具，但它并非万能。其核心缺陷在于不支持可重入，在递归调用场景下极易引发死锁。

使用准则：

• 适用：保护数据库连接池、外部API等有限资源；虚拟线程环境下的防过载。
• 慎用/避免：方法存在递归或循环调用；需要复杂限流算法；需动态调整配置。

黄金法则：务必厘清方法调用链，避免重入；在虚拟线程环境中可大胆提高限制；组合使用@Async、@Transactional等注解时，必须进行严格测试。