Semaphore仅控制许可数量而不跟踪持有者，易因异常、遗漏release或异步场景导致许可泄漏；需配合try-finally、ThreadLocal绑定连接、超时获取及主动泄漏检测。
为什么直接用 Semaphore 做连接池容易漏归还
因为 Semaphore 只管“许可数量”，不跟踪谁拿了、谁该还。你 acquire() 之后如果发生异常、提前 return、或者忘了写 release()，许可就永远卡住，池子会逐渐枯竭。
典型错误现象：acquire() 阻塞不动，日志里没报错但新请求全卡住；或者运行几小时后突然所有 DB 操作超时。
- 必须把
acquire()和release()放在 try-finally 里，哪怕只有一行业务逻辑 - 不要在异步回调、线程池任务里直接操作
Semaphore，除非你能 100% 控制生命周期 - 避免在
finally块里再抛异常——它会吞掉原始异常，建议用try { ... } finally { if (permits > 0) semaphore.release(); }
怎么让 Semaphore 和真实连接绑定起来
单纯靠 Semaphore 无法知道哪个线程借了哪条连接。你需要额外维护一个映射：线程 ID → 连接对象，或用 ThreadLocal 存当前持有的连接。
使用场景：连接需要复用（比如事务期间不能换连接）、要支持超时中断、或需记录借用堆栈用于排查泄漏。
- 推荐用
ThreadLocal<Connection>+Semaphore组合：借的时候acquire()并存入ThreadLocal，还的时候从ThreadLocal取出并release() - 别把
Connection存进Semaphore的队列里——它不提供存储能力 - 如果连接创建开销大（比如 SSL 握手），记得在
acquire()后检查连接是否还活着，而不是无脑复用
Semaphore.tryAcquire(long, TimeUnit) 是唯一能防死锁的姿势
用无参 acquire() 等待许可，一旦下游数据库宕机或网络卡住，整个线程就永久挂起，拖垮整个服务。
性能影响：超时时间设太短（如 100ms）会导致频繁失败；设太长（如 30s）又掩盖真实问题。建议和 DB 驱动的 socketTimeout 对齐，通常是 5–10 秒。
- 永远优先用
tryAcquire(timeout, unit)，失败就快速返回或降级，别等 - 超时后记得调用
semaphore.drainPermits()或记录告警——说明池子长期饱和，不是瞬时抖动 - 不要在循环里反复
tryAcquire()不 sleep，这会打满 CPU
连接泄漏检测必须自己加，Semaphore 不提供任何钩子
Semaphore 不知道你借的是数据库连接，更不会主动 close、log、或触发 GC。泄漏只能靠你手动埋点。
容易被忽略的地方：连接被借出后，线程被中断（Thread.interrupt()）、JVM shutdown 钩子未触发、或 Spring 的 @Transactional 异常退出但没走完 finally。
- 给每次
acquire()打日志，带上Thread.currentThread().getId()和System.nanoTime() - 启动一个后台线程，定期扫描
ThreadLocal中存活超 30 秒的连接，强制归还并告警 - 别依赖
finalize()或Cleaner做兜底——它们不及时，且可能根本没机会执行
