Helidon并发限制模块中AIMD实现的内存泄漏问题分析

问题背景

在Helidon 4.1.x版本中，其并发限制模块(Concurrency Limit)引入了一个新的AIMD(Additive Increase/Multiplicative Decrease)算法实现。该算法本应提供动态调整并发请求限制的能力，但在实际使用中却出现了严重问题：当并发请求数达到初始限制后，系统会持续返回503错误，无法处理后续请求。

问题现象

开发团队在使用Helidon构建的Spectra UCP示例中进行测试时，配置了以下AIMD参数：

• 最小限制(min-limit): 5
• 最大限制(max-limit): 10
• 初始限制(initial-limit): 5
• 超时时间(timeout): 2秒
• 回退比率(backoff-ratio): 0.8

当仅使用5个并发用户测试时，系统就开始出现503服务不可用错误。这表明并发限制机制没有按预期工作，请求无法被正确处理。

根本原因分析

通过深入代码分析，发现问题出在AimdLimitImpl类的实现上。该类使用Semaphore来控制并发请求数量，但在以下关键环节存在缺陷：

1. 信号量获取与释放不匹配：tryAcquire()方法成功获取信号量后，没有在请求处理完成后正确释放信号量
2. Token实现不完整：AimdToken虽然实现了dropped()、ignore()和success()方法，但这些方法都没有调用semaphore.release()
3. 并发计数器管理混乱：currentRequests和concurrentRequests两个计数器之间的关系不清晰

这种设计缺陷导致一旦初始的5个信号量被获取，系统就无法再处理新请求，因为信号量永远不会被释放。

解决方案

开发团队提出了以下修复方案：

1. 修改AimdToken构造函数：将Semaphore实例传递给Token对象
2. 完善Token生命周期方法：在所有结束方法(dropped/ignore/success)中都添加semaphore.release()
3. 优化计数器管理：确保并发计数器与信号量状态同步

修改后的关键代码如下：

private final Semaphore semaphore;

private AimdToken(Supplier<Long> clock, AtomicInteger concurrentRequests,Semaphore semaphore) {
    startTime = clock.get();
    currentRequests = concurrentRequests.incrementAndGet();
    this.semaphore = semaphore;
}

@Override
public void dropped() {
    semaphore.release();
    updateWithSample(startTime, clock.get(), currentRequests, false);
}

@Override
public void ignore() {
    concurrentRequests.decrementAndGet();
    semaphore.release();
}

@Override
public void success() {
    concurrentRequests.decrementAndGet();
    semaphore.release();
    updateWithSample(startTime, clock.get(), currentRequests, true);
}

修复效果

应用上述修改后：

1. 信号量能够被正确释放
2. 系统可以持续处理请求而不会出现503错误
3. AIMD算法能够根据实际负载动态调整并发限制

经验总结

这个案例提醒我们在实现资源管理组件时需要注意：

1. 资源获取和释放必须严格配对
2. 所有可能的执行路径都要考虑资源释放
3. 并发控制组件的状态管理需要特别谨慎
4. 充分的测试覆盖各种边界条件非常重要

对于使用Helidon 4.1.x版本的开发者，建议检查是否使用了AIMD并发限制功能，并考虑应用此修复或升级到包含此修复的后续版本。