AtomicInteger 不适合分布式限流，仅适用于单机轻量级计数；它缺乏时间窗口、分布式共享、阻塞策略及令牌桶语义，生产环境应选用 Resilience4j、Bucket4j 或 Spring Cloud Gateway + Redis 等专用限流组件。
AtomicInteger 在 Spring Security 中不适合直接用于分布式环境下的请求计数与限流，但在单机、轻量级场景中可作为简单计数器辅助实现基础限流逻辑，需配合合理设计避免线程安全与精度问题。
为什么 AtomicInteger 不能直接替代 RateLimiter
Spring Security 本身不内置限流组件，常需集成 Resilience4j、Bucket4j 或自研限流器。AtomicInteger 是 JVM 级原子整数，仅保证单机多线程下的递增/递减原子性，不具备以下关键能力：
- 时间窗口控制（如每秒最多 100 次请求）—— AtomicInteger 无法自动重置或滑动
- 分布式共享状态——集群多实例下各节点计数独立，无法协同限流
- 阻塞/等待/降级策略——它只提供 getAndIncrement，不支持限流时的 sleep、抛异常或返回 fallback
- 令牌桶或漏桶语义——无容量、速率、填充逻辑，只是个“加法器”
AtomicInteger 可用的轻量级计数场景
在单体应用、开发测试、或非核心接口的粗粒度统计中，AtomicInteger 可低成本记录请求频次，例如：
- 统计某接口当日总调用量（配合定时任务清零）
- 标记某用户连续失败登录次数（内存级，重启即失效，适合临时风控）
- 与 ThreadLocal 配合，做单请求链路内的操作计数（如重试次数）
示例：记录未认证请求次数（仅作监控，不用于拦截）
立即学习“Java免费学习笔记（深入）”；
private static final AtomicInteger anonRequestCounter = new AtomicInteger(0);
// 在自定义 Filter 或 HandlerInterceptor 中
if (!isAuthenticated(request)) {
int count = anonRequestCounter.incrementAndGet();
if (count % 100 == 0) {
log.warn("Anonymous request count reached: {}", count);
}
}
真正可靠的限流应使用专用组件
生产环境推荐以下方案，它们天然支持时间窗口、分布式协调与策略扩展：
- Resilience4j RateLimiter：基于信号量 + ScheduledExecutorService 实现滑动窗口，支持注解（@RateLimiter）和编程式调用，可对接 Redis 做集群共享
- Bucket4j：高性能令牌桶实现，原生支持 JCache、Hibernate、Redis 等后端，适合高并发限流
- Spring Cloud Gateway + Redis RateLimiter：网关层统一限流，基于 Lua 脚本保证 Redis 原子性，适合全站 API 控制
若坚持用 AtomicInteger 构建简易限流，必须手动维护时间戳+计数对，并定期清理过期桶 —— 这已接近手写滑动窗口，远不如直接用 Bucket4j 的 ConcurrentMapBasedBucket 稳定。
与 Spring Security 集成的关键注意点
在 SecurityFilterChain 中嵌入限流逻辑时，务必注意执行顺序与异常处理：
- 限流 Filter 应放在
UsernamePasswordAuthenticationFilter之前，避免未认证请求绕过限制 - 限流触发时抛出
ResponseStatusException(HttpStatus.TOO_MANY_REQUESTS)，确保被 Spring 的全局异常处理器捕获并返回 429 - 勿在
SecurityContext中存 AtomicInteger 实例——它不是线程安全容器，且 Context 生命周期与请求不完全对齐 - 若用 AOP 切限流逻辑，避免切在
@PreAuthorize之后，否则鉴权失败的请求可能漏统计
