Semaphore限流算法实现教程

有志者，事竟成！如果你在学习文章，那么本文《基于Semaphore的简单限流算法实现》，就很适合你！文章讲解的知识点主要包括，若是你对本文感兴趣，或者是想搞懂其中某个知识点，就请你继续往下看吧~

Semaphore常被误用为“伪限流”因其仅控制并发数而非单位时间请求数，不自动释放许可且无时间窗口感知，易因未配对调用acquire/release导致许可泄漏、线程阻塞或QPS失控。

用 Semaphore 做限流，为什么常被误用成“伪限流”

因为 Semaphore 控制的是并发数，不是单位时间请求数——它不自动释放许可，也不感知时间窗口。你 acquire() 一次，就占一个坑，直到你显式 release() 或者发生异常没兜住，这个坑就一直空不回来。

常见错误现象：Semaphore 的许可数明明设了 10，但压测发现 QPS 超过 10，甚至到几百；或者服务跑半天后突然卡死，日志里满屏 InterruptedException 或线程阻塞在 acquire()。

• 必须在 try-finally 里配对调用 acquire() 和 release()，漏掉 release() 就等于内存泄漏（许可泄漏）
• 别用 acquireUninterruptibly() 掩盖中断问题，它会让线程彻底失去响应能力
• 如果业务逻辑可能超时，得用带超时的 tryAcquire(long timeout, TimeUnit unit)，否则阻塞线程池会耗尽
• Semaphore 适合保护下游资源（如 DB 连接池、HTTP 客户端连接），不适合做 API 层的“每秒最多 100 次”这种滑动窗口限流

原子计数器 + 时间窗口：手写最简滑动窗口限流的致命细节

用 AtomicLong 记当前窗口内请求数，配合时间戳判断是否跨窗——听起来简单，但实际极易出错。核心问题不在计数，而在“窗口怎么切”。

常见错误现象：限流阈值忽高忽低，比如设了每秒 5 次，结果某秒放行 8 次，下秒又只让过 2 次；或者高并发下计数器突增，远超预期。

• 别用 System.currentTimeMillis() 做窗口键——它精度低（毫秒级）、可能回拨，会导致窗口错乱；改用 System.nanoTime() 算相对偏移，再映射到秒级桶
• 窗口不能靠“清零”实现，要靠“桶滚动”。例如每秒一个桶，用 long windowId = System.nanoTime() / 1_000_000_000 当前窗口 ID，用 ConcurrentHashMap 存桶，但必须定期清理过期桶（否则 OOM）
• incrementAndGet() 后立刻检查是否超限，但要注意：超限后不能直接拒绝——得先确认这个请求确实属于该窗口（避免因时钟漂移或重试导致误判）
• 单机可用，但集群下完全失效；想跨节点限流，得上 Redis + Lua（如 INCR 配 EXPIRE），否则各节点各自为政

Redis + Lua 实现原子限流：为什么非得用 Lua 脚本

因为 INCR 和 EXPIRE 两步操作不具备原子性。如果先 INCR 再 EXPIRE，中间进程崩溃或网络断开，key 就永久存在，限流彻底失效。

使用场景：微服务网关层、API 门面、需要集群统一视图的限流点。

• Lua 脚本必须把 key、maxCount、expireSec 作为参数传入，不要硬编码；脚本里用 redis.call('INCR', KEYS[1])，再用 redis.call('EXPIRE', KEYS[1], ARGV[2]) 确保原子
• 注意 Redis 的 EXPIRE 对已存在的 key 不会重置 TTL，所以首次 INCR 后必须确保 EXPIRE 成功；更稳妥是用 SET key value EX seconds NX 初始化，但需拆成多步，反而难保原子
• 返回值建议设计为：-1=超限，0=初始化成功，>0=当前计数；客户端根据返回值决定放行或拒绝，别依赖状态码或异常
• 别用 redisTemplate.execute() 直接传字符串脚本——容易注入；Spring Boot 2.6+ 推荐用 DefaultRedisScript 预编译 + 参数绑定

选 Semaphore 还是原子计数器？看你的瓶颈在哪

这不是个“哪个更好”的问题，而是“你在防什么”的问题。限流目标错了，算法再漂亮也白搭。

性能影响明显：高并发下 AtomicLong.incrementAndGet() 比 Semaphore.tryAcquire() 更轻量，但前者不阻塞，后者能天然削峰；而 Redis 方案延迟固定在 1–2ms，但吞吐受网络和 Redis 性能制约。

• 保护本地资源（如文件句柄、计算线程池）→ 用 Semaphore，重点管住并发数
• 控制单机 API 频率（如用户每分钟发 10 条消息）→ 用原子计数器 + 时间窗口，重点管住时间维度
• 全局策略（如全站每秒最多 1 万次搜索）→ 必须用 Redis + Lua，否则节点间无法协同
• 别在 Controller 层直接 new Semaphore(10)——生命周期错位，每次请求都新建对象，限流形同虚设

真正难的从来不是写几行限流代码，而是说清楚“到底要挡住什么流量、挡住之后怎么反馈、挡不住时谁来兜底”。这些不定义清楚，算法只是纸面装饰。

终于介绍完啦！小伙伴们，这篇关于《Semaphore限流算法实现教程》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布文章相关知识，快来关注吧！