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<long atomiclong></long>存桶，但必须定期清理过期桶（否则 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)——生命周期错位，每次请求都新建对象，限流形同虚设
真正难的从来不是写几行限流代码，而是说清楚“到底要挡住什么流量、挡住之后怎么反馈、挡不住时谁来兜底”。这些不定义清楚，算法只是纸面装饰。
