semaphore核心是“配额准入”而非锁资源，许可数须贴合真实承载能力：数据库连接池设为最大活跃连接数且不超服务端上限，cpu密集型按公式估算，io密集型需压测验证；公平性依场景选，默认非公平提升吞吐，关键链路用公平防超时；必须tryacquire超时+finally release，且需与数据库锁等协同保障原子性。
Semaphore 在 Java 中处理资源池并发冲突，核心不是“锁住资源”，而是“配额准入”——它不干预资源内部状态，只控制同时能进入操作阶段的线程数量。用对策略，才能既防过载，又保吞吐。
许可数必须贴合真实资源容量
初始许可值不是业务上限，而是后端资源的实际承载能力映射：
- 数据库连接池：设为连接池最大活跃连接数，且不能超过数据库服务端允许的并发连接上限（例如 MySQL 默认 max_connections=151，实际可用需预留管理连接）
- CPU 密集型任务：参考公式 许可数 ≈ CPU 核心数 × (1 + 平均等待时间 / 平均计算时间)，避免线程空转争抢 CPU
- IO 密集型任务（如 HTTP 调用、文件读写）：可设为 CPU 核心数的 2–5 倍，但必须通过阶梯压测验证——比如从 5 → 20 → 50 许可逐步加压，观察平均等待时间与错误率拐点
公平性要按场景切换，不默认开 true
公平模式（new Semaphore(10, true)）保证 FIFO 排队，非公平模式（默认）允许插队，二者性能差异显著：
- API 网关限流、缓存穿透防护等高吞吐短任务 → 选非公平模式，吞吐提升 15%–30%，延迟波动可控
- 支付扣款、库存预占等关键链路 → 启用公平模式，防止某请求因持续被插队而超时失败
- 注意：公平模式会增加 AQS 队列维护开销，高争用下获取许可耗时可能上升 2–5 倍
批量申请 + 超时兜底，避免阻塞雪崩
单次 acquire(1) 效率低，无超时阻塞风险高：
- 对批量资源操作（如一次写入 3 条 DB 记录），用
acquire(3)一次性申请，减少同步次数和上下文切换 - 绝不裸调
acquire()，必须用tryAcquire(timeout, unit)，超时建议设为 50–200ms；超时后走降级逻辑（返回缓存、默认值或告警） - release() 必须放在 finally 块中，确保异常、中断或提前 return 时许可仍能归还，否则许可永久泄漏，后续所有线程卡死在 acquire
信号量只是闸门，不是原子保障
它只管“有多少人能进门”，不管“进门后干了什么”。资源池本身若存在竞态，还需叠加其他机制：
- 秒杀库存场景：仅靠
new Semaphore(100)会超卖，必须组合数据库行锁或乐观锁（如UPDATE item SET stock = stock - 1 WHERE id = ? AND stock > 0） - 连接池场景：Semaphore 控制“取连接”的并发数，但连接复用、失效检测、空闲回收仍由连接池自身（如 HikariCP）负责
- 切忌把信号量当 ReentrantLock 用——它不提供重入、不保证临界区内变量一致性
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
