semaphore管理“许可”而非“权限”，通过可配置计数器控制并发访问临界区的线程数，需精准包围高成本操作、设合理许可数、配超时与自动释放、避免空转和泄漏，并可结合失败统计实现简易熔断。
Semaphore不是分配“权限”，而是管理“许可”——它通过一个可配置的计数器，控制同一时刻能进入临界区的线程（或协程）数量，从而防止资源过载，提升整体吞吐与稳定性。关键不在于“锁住一切”，而在于精准围住真正耗资源的操作，并配以超时、熔断和自动释放机制。
许可数设置：参考下游容量，留出缓冲余量
许可数直接决定并发上限，设得太小会闲置资源，设得太大则失去限流意义。
- 典型参考值：若数据库连接池最大为20，Semaphore可设为15～18；若第三方API限流为100 QPS，可按单次调用耗时反推合理并发数（例如平均响应200ms，则理论峰值约5并发）
- 避免硬编码：在配置中心管理 permits 值，支持运行时动态调整
- 注意 maxCount 约束（如 C# 的 SemaphoreSlim）：初始化时指定的 initialCount 不能超过 maxCount，否则抛异常
作用范围要窄：只包围核心资源操作
把 acquire/release 放在整个请求入口，等于让校验失败、参数错误等无效请求也占着许可，造成许可空转浪费。
- 正确做法：参数校验、日志记录、鉴权等轻量逻辑放在 acquire 之前；仅在调用远程服务、执行 SQL、写文件等高成本动作前后加许可控制
- 示例（Java）：校验通过 → acquire() → 查询DB → release() → 组装响应
- 异步场景（Python asyncio / C#）：优先使用 async with semaphore 或 await WaitAsync()，确保上下文自动释放
必须带超时 + finally 保障释放
无超时的 acquire() 可能导致线程/协程无限等待，最终拖垮线程池或事件循环。
- 推荐用 tryAcquire(timeout, unit)（Java）或 WaitAsync(timeout)（C#）：超时建议 100–300ms，超时后快速失败并返回降级结果（如缓存、默认值）
- release() 必须放在 finally 块或 async with 中：哪怕业务逻辑抛异常，也要归还许可，否则引发许可泄漏，逐步导致所有线程阻塞
- 禁用 acquireUninterruptibly()：它忽略中断信号，不利于系统优雅停机和故障隔离
配合失败统计实现简易熔断
Semaphore 本身不熔断，但可以低成本构建“失败驱动”的开关机制。
- 用 AtomicInteger 或线程安全计数器，统计最近60秒总请求数与失败数
- 触发条件示例：失败率 ≥50% 且总请求数 ≥20 → 切换为 OPEN 状态
- OPEN 状态下直接拒绝新请求（跳过 acquire），30秒后进 HALF-OPEN，只放行1–2个试探请求；成功则恢复，失败则重置计时器
