Semaphore控制API调用易失效，因其仅限制放行数量，不感知网络超时或异常；若acquire后未及时release（如调用超时、异常中断），许可被长期占用，导致实际并发远低于预期，甚至耗尽线程池。
为什么直接用 Semaphore 控制 API 调用容易失效
信号量本身不感知网络延迟、超时或失败重试——它只管“放行数量”，不管“请求是否真正完成”。如果下游 API 响应慢或超时，acquire() 后没及时 release()，许可会被长期占用，实际并发数远低于预期，甚至导致线程池耗尽。
常见错误写法：
Semaphore sem = new Semaphore(10); sem.acquire(); // 可能阻塞 callThirdPartyApi(); // 这里超时？异常？没 release 就完蛋了 sem.release(); // 永远执行不到
- 必须把
acquire()和release()放在try-finally中，确保释放 - 不要在
acquire()后做任何可能抛异常且未捕获的逻辑，否则finally里的release()无法兜底 - 避免用
acquireUninterruptibly()：一旦线程被中断（如 Spring 的@Async超时），会永久卡住
带超时和自动清理的 Semaphore 调用模板
核心是用 tryAcquire(long timeout, TimeUnit) 防止无限等待，并把 release() 移到 finally 最外层。
Semaphore sem = new Semaphore(5);
boolean acquired = false;
try {
acquired = sem.tryAcquire(3, TimeUnit.SECONDS); // 等最多 3 秒
if (!acquired) {
throw new RuntimeException("API concurrency limit exceeded");
}
String result = callThirdPartyApi(); // 实际 HTTP 调用
return result;
} finally {
if (acquired) {
sem.release(); // 成功 acquire 后才 release，安全
}
}
-
tryAcquire返回false表示没拿到许可，此时绝不能调用release() - HTTP 调用本身也得设超时（如 OkHttp 的
connectTimeout、readTimeout），否则信号量等到了，但请求还在 hang - 如果下游支持批量接口，优先用单次批量请求替代多次串行调用，减少信号量争用
如何让限流策略适配不同下游服务的 SLA
一个 Semaphore 实例无法动态调整许可数。硬编码 new Semaphore(10) 会让变更依赖重启，也不利于灰度或熔断。
- 用
AtomicInteger+Semaphore组合实现运行时调整许可数： - 每次
acquire()前检查当前许可数是否变化，若变化则重建Semaphore（注意旧实例上残留的许可要 drain） - 更稳妥的做法：用
ConcurrentHashMap按服务名隔离信号量，比如"payment-api"和"notify-sms"各自独立限流 - 别把
Semaphore当作熔断器用——它不记录失败率。失败过多时，应配合CircuitBreaker（如 Resilience4j）降级，而不是死撑着抢许可
与 Spring Cloud Gateway 或 Sentinel 的关键区别
Semaphore 是纯内存、无中心、无统计的轻量控制，适合单 JVM 内部限流；但它没法做集群限流、QPS 统计、实时监控或动态规则推送。
- 如果你的服务部署在多个节点，
Semaphore只能保证单机不超限，整体仍可能压垮下游 - Spring Cloud Gateway 的
RequestRateLimiter或 Sentinel 的FlowRule依赖 Redis 或 Nacos，能跨节点协同，但引入额外组件和延迟 - 折中方案：单机用
Semaphore做快速 fail-fast，再加一层中心化限流兜底——两者不是替代关系，而是分层防御
信号量真正的价值不在“多准”，而在“多快”：毫秒级抢占/释放，零序列化开销。但这也意味着它对调用链路的每个环节都要求严格——漏掉一次 release，就等于悄悄少了一个可用许可，而你很难立刻发现。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
