Java Semaphore reducePermits能否用不释放的acquireUninterruptibly替代

reducePermits()的设计初衷 #

首先要明确：reducePermits()本身是protected方法，从访问权限就能看出来，它不是给普通业务代码直接调用的公共API，是JDK为同步组件扩展预留的原子操作，核心价值是无阻塞、无归属地直接修改全局许可计数：

• 它不会走许可获取的排队、校验逻辑，不管当前剩余多少许可，直接原子性扣减指定数量的总许可，哪怕扣完总许可数是负数也不会阻塞、不会报错，修改是即时生效的。
• 扣减的许可不会和任何线程绑定，不需要某个线程专门“持有”这些被减掉的许可，没有额外的线程状态开销，后续如果要恢复许可数，直接调整总计数即可，不需要追踪许可归属。
  JDK内部就靠这个方法实现同步组件逻辑，比如CyclicBarrier的屏障重置、部分自定义限流组件的动态缩容，都是用这个方法做无副作用的许可调整。

拿许可不release的方式能不能替代？ #

完全不等价，绝大多数场景下根本没法用，核心差异有三个：

• 会出现不可控的阻塞：如果你要缩减的许可数大于当前剩余可用许可，acquireUninterruptibly()会直接阻塞调用线程，直到其他线程释放足够的许可才能继续。举个实际例子：假设Semaphore总许可5个，已经被业务线程占了4个，只剩1个可用，你现在要缩减3个总许可。用reducePermits直接把总许可改成2就完事，等现有4个许可逐步释放后，最多只会再放1个线程进入，最终效果就是总许可2，全程不卡任何线程。但你要是用acquire拿3个许可，现在只剩1个，调用缩减逻辑的线程会直接堵在这，不知道什么时候才能凑够3个许可，缩减动作的生效时间完全不可控。
• 许可归属语义错误：acquire拿到的许可是和调用线程绑定的，如果你后续要扩容加回许可，还得专门找到持有这些“被吞掉”许可的线程手动释放，维护成本极高，一旦线程意外销毁，这些许可就彻底丢了。而reducePermits改的是全局计数，没有线程绑定问题，调整起来非常灵活。
• 公平模式下会破坏排队规则：如果用的是公平Semaphore，acquire操作必须进等待队列按顺序拿许可，本来排在前面等待的业务线程会先拿到许可，你要做的缩减动作根本没法按预期时间生效，甚至可能导致许可数越减越乱。而reducePermits直接操作全局状态，不需要排队，原子性生效，不会干扰现有等待队列的顺序。

关于Striped信号量无法实现reducePermits的问题 #

你遇到的问题本质是Striped的实现机制导致的：不管是懒加载的弱引用版本还是普通版本，Striped对外都没有暴露内部分段Semaphore的实例访问入口，弱引用版本的分段Semaphore甚至可能在内存不足时被回收，下次访问再重新创建默认许可数的实例，就算你靠反射临时拿到所有分段实例改了许可数，后续实例重建后配置就会失效，根本没法稳定生效。
如果确实需要动态调整Striped信号量的许可，可行的方案只有两个：

• 不用Guava提供的现成Striped，自己实现分段信号量，用强引用持有每个分段的Semaphore实例，自定义子类暴露许可调整的方法，遍历所有段做原子调整即可。
• 如果一定要用Guava的Striped，就放弃动态缩容的设计，要么初始化时就把许可数设成足够小的值，要么在业务上层做一层额外的许可控制，不要依赖Striped本身的计数做动态调整。

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