Java为何允许初始化java.util.concurrent.Semaphore时使用负许可数

核心设计根源：实现层面没有额外的非负校验约束 #

首先要明确一个关键前提：Java支持负初始许可数，并非专门为了某类场景设计的特性，而是底层实现简化带来的自然结果。
Semaphore的许可数本质是依托AQS（AbstractQueuedSynchronizer）的state字段存储的，这个字段是一个普通的可读写volatile int，本身没有被强制要求必须存储非负值。
从运行逻辑上看，许可数本来就天然支持负值：当有线程排队等待许可时，AQS计算出的state值 = 可立即获取的许可数 - 排队等待的线程数，这种状态是完全正常的运行态，不需要做特殊异常处理。如果Semaphore在构造函数里硬卡“传入负许可数就抛非法参数异常”，反而和运行时的状态规则自相矛盾，还要额外增加校验分支，完全是不必要的开发成本。
所以从实现效率的角度，构造函数会直接把传入的permits值赋值给AQS的state，没有做任何非负校验，自然就支持了负初始值的操作。

实际可用的典型场景 #

这种无校验的宽松设计，虽然不是官方刻意规划的，但确实覆盖了几个顺滑的业务场景：

• 多阶段前置任务的放行控制
  如果业务需要等多个前置步骤全部完成，才能允许后续业务线程访问共享资源，不需要额外引入其他同步组件：
  比如需要等3个外部配置拉取完成后才开放接口访问，可以直接初始化new Semaphore(-3)，每完成一个配置拉取就调用一次release(1)，当3个拉取全部完成后，许可数就会从-3累计到0，最早在排队等许可的业务线程会被自然唤醒。
  这种方式和CountDownLatch的差异是：它不需要等所有计数清零才一次性放行所有线程，而是每攒够一个许可，就按顺序唤醒一个排队线程，灵活度更高。
• 预热流程的资源预留
  比如数据库连接池启动时，需要先完成3个预热连接的初始化（用来压测连通性、建立会话状态），等预热完成后再允许普通业务请求抢占连接。可以直接把Semaphore初始化为-3，预热流程每完成一个连接初始化就调用一次release(1)，等3个预热连接全部就绪，许可数回到0，后续普通请求就可以正常申请连接，整个流程不需要额外写逻辑区分预热流量和普通流量。

常见的认知误区 #

很多人觉得负初始许可是反常识的，本质是把“初始许可数”和“立即可用的许可数”的概念完全绑定死了：
你传入的初始值，本质只是给AQS的state设置了一个初始偏移量而已，和运行中因为排队线程导致state为负的逻辑没有任何区别。比如示例代码里，new Semaphore(-2)之后调用release(3)得到1个可用许可，本质等价于先初始化许可数为0，再调用release(1)——区别只是你提前把“需要累计多少个release操作才能达到可提供服务的状态”的偏移量，放在初始值里设置了而已。

补充提醒：JDK官方文档从来没有推荐过使用负初始值的写法，这属于实现简化带来的实用特性，不是官方背书的标准用法，实际生产中使用时一定要加好注释说明，避免后续维护者对初始化逻辑产生误解。

内容的提问来源于stack exchange，提问作者Tejaskumar