Semaphore许可数应根据目标资源真实容量设定，如数据库连接池为5则设为5，需预留10%~20%余量，动态资源应换用Resilience4j等限流器。
Semaphore 初始化时 permits 数设多少才合理
信号量的许可数不是随便填的，它直接决定最多几个线程能同时进入临界区。设得太小，吞吐上不去；设太大，起不到限流作用，甚至可能压垮下游资源。
常见误判是照搬线程池大小（比如 Executors.newFixedThreadPool(10) 就配 new Semaphore(10)），但这两者语义不同：线程池控制的是“执行者数量”，而 Semaphore 控制的是“持有某类资源的并发数”。比如数据库连接池只有 5 个连接，那 Semaphore 就该设为 5，哪怕你开了 20 个线程。
- 查清目标资源的真实容量（如 Redis 连接数、HTTP 客户端最大连接、文件句柄上限）
- 考虑突发流量，可预留 10%~20% 余量，但别盲目放大
- 如果资源是动态伸缩的（如云数据库连接池自动扩缩），
Semaphore就不适合——得换用更灵活的限流器（如Resilience4j RateLimiter）
acquire() 和 tryAcquire() 的关键区别在哪
这两个方法看着像，但阻塞行为和错误处理逻辑完全不同，选错会导致线程卡死或请求无声失败。
acquire() 会一直阻塞直到拿到许可，除非被中断；而 tryAcquire() 立即返回 boolean，拿不到就走 else 分支——这才是做超时/降级的正确姿势。
立即学习“Java免费学习笔记（深入）”；
- 不要在定时任务或响应敏感服务里用
acquire()，没设超时等于埋雷 - 要用带超时的版本：
tryAcquire(long timeout, TimeUnit unit)，超时后必须显式处理失败逻辑（如返回 429、走缓存、抛业务异常） -
acquireUninterruptibly()更危险：连Thread.interrupt()都无法打断，JVM 停机时可能 hang 住
释放许可时忘记调用 release() 会怎样
这是最隐蔽也最致命的问题：不 release，许可数永远不归还，后续所有线程都在 acquire() 上阻塞，应用逐渐假死。
根本原因不是语法错误，而是控制流分支遗漏——比如异常路径、return 提前退出、或者用了 try-with-resources 却没把 Semaphore 包进去（它不实现 AutoCloseable）。
- 必须把
release()放在finally块里，哪怕只有一行代码也要包住 - 别信“我这段逻辑肯定不会异常”，网络 IO、NPE、OOM 都可能发生在 acquire 之后、release 之前
- 可以封装工具方法，例如
withPermit(sem, () -> { /* do work */ })，内部确保 release
公平模式（fair = true）真的有必要开吗
默认非公平，新线程可能插队抢到刚释放的许可；设成公平后，按等待顺序分发，但性能下降 10%~30%，且不能完全避免饥饿（比如持续高并发下，后面排队的线程可能永远等不到）。
绝大多数场景不需要开公平模式。它只在极少数业务语义强制要求“先到先得”时才有意义，比如订单号生成、库存扣减这种对顺序敏感的操作。
- Web 请求、日志写入、缓存更新——这些都不需要公平，吞吐优先
- 开启后记得压测对比 QPS 和 P99 延迟，别凭感觉
- 即使开了公平，也不能替代分布式锁；多 JVM 实例间仍需外部协调（如 Redis + Lua）
实际用的时候，最常出问题的不是怎么写，而是没想清楚「这个信号量到底在保护什么资源」。一上来就 new Semaphore(10)，结果发现 10 是数据库连接数，但业务里还有 3 个线程在同时读文件、2 个在调第三方 API——全挤在同一个信号量下，反而造成无关操作互相阻塞。
