acquireUninterruptibly适合做不可中断排队限制器，因为它忽略中断信号持续阻塞直至获取许可，保障后台批处理等必须执行完的任务不被意外中断，但需注意中断状态会延迟恢复、不可与acquire混用、须严格配对release且性能略低。
acquireUninterruptibly 为什么适合做不可中断排队限制器
它直接忽略线程中断信号，持续阻塞直到拿到许可，避免任务因 Thread.interrupt() 被意外踢出队列。这对后台批处理、日志刷盘、数据库连接池预热等「必须执行完」的场景很关键——你不想让一个正在归档日志的任务因为上游超时就被半途扔掉。
但要注意：它不等于“永不响应中断”，只是把中断状态暂存，获取许可后会重新设置 Thread.currentThread().interrupt()。如果你在 acquireUninterruptibly() 后没检查中断状态，就可能丢失信号。
和 acquire() 混用会导致排队逻辑失效
一旦混用，队列行为就不可预测：调用 acquire() 的线程可能被唤醒并抛出 InterruptedException，而 acquireUninterruptibly() 的线程还在傻等。结果是许可数没错，但等待队列里既有可中断线程也有不可中断线程，调度顺序混乱，甚至出现“插队”假象。
实操建议：
- 整个限制器生命周期只用
acquireUninterruptibly()（包括初始化、重试、兜底逻辑） - 如果必须响应中断（比如上层有 cancel 接口），就别用这个方法，改用带 try-catch 的
acquire()+ 自定义重入逻辑 - 构造
Semaphore时显式传true：newSemaphore(5, true)，确保 FIFO，否则公平性无法保障，不可中断语义也会打折扣
释放许可时忘记调用 release() 是最隐蔽的泄漏点
acquireUninterruptibly() 不抛异常，但也不自动配对 release()。一旦某条路径（比如 catch 块里没写 release()，或 finally 里漏了）导致许可未归还，后续所有线程都会永久卡住。
安全写法只有两种：
- 用 try-finally，且
release()必须写在 finally 块最外层 - 用 try-with-resources 包装一个自定义
AutoCloseable类，close()内部调用semaphore.release()
示例片段：
semaphore.acquireUninterruptibly();
try {
// 执行受控任务
} finally {
semaphore.release(); // 这行不能少，也不能放在 if 或 catch 里
}
高并发下 acquireUninterruptibly 的性能其实比 acquire() 略低
因为每次被 park 前都要检查并清除中断状态，再在 unpark 后恢复，多两次 volatile 写。在每秒几万次争抢的场景里，这个开销可观。
如果你的“不可中断”只是业务语义（比如不想被 HTTP 超时打断），而非系统级可靠性要求，可以考虑用 acquire(1, timeout, TimeUnit) 配合足够长的超时（如 30 分钟）+ 重试，反而更轻量、可观测性更好。
真正需要 acquireUninterruptibly() 的，往往是那些连 JVM Shutdown Hook 都要等它跑完的任务——这种地方，多那几个纳秒的开销，根本不是问题。
