Java接口限流核心是控制单位时间请求量，常用计数器、滑动窗口、漏桶、令牌桶四种算法；实际多结合Spring Boot+Redis或Sentinel实现，单机推荐Guava RateLimiter，微服务推荐Spring Cloud Gateway或Sentinel。
Java中做接口限流，核心是控制单位时间内请求的通过数量，防止系统被突发流量压垮。常用方式有计数器、滑动窗口、漏桶、令牌桶四种算法，实际项目中多结合Spring Boot + Redis或Sentinel实现，兼顾性能与分布式支持。
计数器算法（简单但有临界问题）
在固定时间窗口内统计请求数，超限则拒绝。实现最轻量，适合单机低并发场景。
- 用ConcurrentHashMap或AtomicInteger记录每个接口+时间窗口的计数
- 每次请求检查当前窗口计数是否小于阈值，是则+1并放行，否则拒绝
- 注意：窗口切换瞬间可能出现双倍流量（如0:59:59和1:00:00各放行一次上限），需配合其他机制规避
滑动窗口算法（更精准的时间切分）
把时间窗口进一步拆成多个小格子（如1秒分10格），只统计最近N个格子的总请求数。比计数器平滑，能更好应对流量毛刺。
- 可用Redis的ZSET或SortedSet存储时间戳，请求时插入当前毫秒时间并清理过期项
- 用LRUMap或环形数组在内存中实现也可，适合单机高吞吐场景
- Spring Cloud Gateway内置的RequestRateLimiter就是基于Redis+滑动窗口
令牌桶算法（允许短时突发，推荐生产使用）
系统以恒定速率向桶中添加令牌，请求需获取令牌才能执行。桶满则丢弃多余令牌，未满则可积累，支持可控的突发流量。
立即学习“Java免费学习笔记（深入）”；
- Guava RateLimiter是内存级令牌桶的经典实现，适合单机限流
- 分布式环境下可用Redis+Lua脚本模拟：用INCRBY维护剩余令牌数，配合EXPIRE设置过期时间
- 注意预热问题——冷启动时桶为空，首次请求可能被拒，可设初始令牌数或延迟加载
集成方案推荐（Spring Boot常用组合）
不建议从零手写限流逻辑，优先选用成熟组件：
- 单体应用：@EnableAspectJAutoProxy + 自定义注解 + AOP拦截，内部用RateLimiter或AtomicLong计数
- 微服务网关层：Spring Cloud Gateway + Redis + RequestRateLimiter，配置简单、天然支持集群
- 全链路治理：接入Sentinel，支持QPS/线程数/响应时间等多维度限流，控制台实时配置、动态生效
- 高性能API服务：Netty + 自研滑动窗口（如用LongAdder+时间轮），减少锁竞争和GC压力
基本上就这些。选哪种取决于你的部署架构、精度要求和运维成本。单机起步用Guava，上云或微服务直接上Sentinel或Gateway，别为了“造轮子”耽误上线节奏。
