Semaphore核心是限流而非线程安全，许可数须严格等于实际可并发资源数；acquire/release须同线程成对执行；多许可下资源自身仍需线程安全保护；应配合超时与后台清理防资源滞留。
Java 中用 Semaphore 管理共享资源池时，核心不是“让资源本身线程安全”，而是“控制同时使用资源的线程数量”。它不替代 synchronized 或 Lock 对数据操作的保护，而是做第一道准入闸门——先限流，再配合其他机制保数据一致。
明确许可数与资源池容量的对应关系
初始化 Semaphore 时，许可数必须严格等于资源池中**真正可并发使用的资源实例数**。例如数据库连接池最大支持 10 个活跃连接，就应 new Semaphore(10)，而不是按线程池大小或预估流量随意设值。若许可数大于实际资源数，会导致获取许可的线程拿到空闲连接失败；若小于，则人为限制吞吐，浪费资源。
- 避免动态调整许可数（如运行时调用 reducePermits），除非有明确的弹性扩缩容策略且已验证其线程安全性
- 对有状态资源（如带会话的 HTTP 客户端），需确保每个获取许可的线程绑定到一个独立资源实例，不能多个线程复用同一实例
获取与释放必须成对、在同一线程内完成
Semaphore 的 release() 必须由 acquire() 的同一线程调用，否则可能引发许可泄漏或计数错乱。尤其在异常路径下，容易遗漏释放。
- 务必用 try-finally 或 try-with-resources（配合自定义 Closeable 封装）包裹 acquire 和业务逻辑
- 禁止跨线程释放：比如主线程 acquire，子线程 release —— 这会导致 AQS 内部状态异常，甚至死锁
- 避免在 finally 块中无条件 release：若 acquire 本身被中断（InterruptedException），尚未真正获得许可，此时 release 会非法增加许可数
多许可场景下，资源自身仍需独立线程安全
当许可数 > 1（即允许多个线程并行访问），Semaphore 只保证“最多 N 个线程能进门”，但进门后对共享资源的操作是否安全，完全取决于资源本身的实现。
立即学习“Java免费学习笔记（深入）”；
- 若资源是 ArrayList、HashMap 等非线程安全集合，即使受 Semaphore 保护，多个线程仍可能同时修改引发 ConcurrentModificationException 或数据丢失
- 正确做法：对资源内部状态加锁（synchronized / ReentrantLock），或改用线程安全类型（ConcurrentHashMap、CopyOnWriteArrayList）
- 二元信号量（new Semaphore(1)）可替代互斥锁用于简单临界区，但语义上更侧重“资源配额”，而非“所有权”
配合后台清理与超时机制防资源滞留
仅靠 acquire/release 不足以应对长任务、异常卡死或网络超时等导致资源长期被占用的情况。
- 为 acquire 设置超时（tryAcquire(long, TimeUnit)），避免线程无限等待，影响整体响应性
- 资源池中每个资源实例应记录最后使用时间，启动独立守护线程定期扫描，对闲置超时的资源执行 close() 并调用 semaphore.release()
- 若资源获取后需长时间持有（如长轮询连接），考虑使用带租期的令牌机制，而非单纯依赖 Semaphore 计数
