semaphore 在 java 中模拟无状态虚拟连接池控制第三方接口调用，仅适用于同步阻塞型调用；需用非公平模式初始化，许可数依下游 sla 与压测结果设定；调用时必须 tryacquire 超时获取并在 finally 中 release，实现流量削峰与资源保护。
Java 中用 Semaphore 结合连接池思想控制第三方接口调用，并不是简单“加个 acquire”，而是要模拟一个轻量级、无状态的“虚拟连接池”——它不管理真实连接对象，只管控同一时刻有多少线程能真正发起调用，从而保护下游接口不被压垮。
明确适用前提：只用于同步阻塞型调用
你的调用逻辑必须满足：整个请求发起、等待响应、解析结果都在同一线程内完成。比如用 RestTemplate + HttpURLConnection 或 OkHttp 同步客户端；
不能用于 WebClient（Reactor）、Feign 的异步回调、或封装了 CompletableFuture 的调用——否则 acquire() 会卡在 IO 线程上，拖垮整个线程池。
初始化：非公平模式 + 合理许可数
用 new Semaphore(n, false) 显式声明非公平模式，避免公平队列带来的吞吐损失和长尾延迟。
许可数 n 不是拍脑袋定的，建议按以下方式收敛：
- 先设为下游接口承诺的并发上限（如对方 SLA 写明“最大并发 20”）
- 压测时观察其响应时间 P99 和错误率：若 P99 超过 800ms 或 5xx 升高，就下调 n
- 同时监控本端线程池活跃线程数和排队任务数，确保不堆积也不闲置
调用流程：超时获取 + 必然释放
每次调用前必须用 tryAcquire(timeout, unit)，超时时间设为下游接口 P99 的 1.2~1.5 倍（例如 P99 是 600ms，就设 750ms）。
一旦超时，直接走降级逻辑（返回缓存、空值或 fallback 接口），绝不阻塞等待。
release() 必须放在 finally 块中，哪怕发生 IOException、JSON 解析异常、甚至 OOM，也要保证许可归还。
配合连接池思想的典型结构
你不需要维护 Connection 对象，但可以抽象出“许可即连接”的语义：
- acquire() → 相当于“从池中借出一个调用额度”
- 成功调用并拿到响应 → “使用完毕”
- finally 中 release() → “归还额度，供他人复用”
这种模型天然支持突发流量削峰：超出许可的请求会快速失败或降级，不会堆积线程或耗尽本地资源。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
