awaituninterruptibly()是condition接口中不响应中断的阻塞等待方法，线程会持续等待直至被signal()唤醒或jvm终止，中断仅暂存状态而不影响等待过程。
awaitUninterruptibly 是什么
awaitUninterruptibly() 是 Condition 接口提供的一个阻塞等待方法，它的核心特点是：**不响应线程中断信号**。调用该方法的线程会一直等待，直到被 signal() 或 signalAll() 显式唤醒，或者 JVM 终止——中断（Thread.interrupt()）不会导致它提前退出或抛出异常。
为什么需要不响应中断的等待
某些业务场景中，线程必须完成关键协作步骤，不能因外部中断而中途退出等待逻辑。例如：
- 资源清理线程在释放共享句柄前，必须等到主任务彻底释放锁并发出“可回收”信号；
- 分布式协调中，本地代理线程需严格等待集群共识达成（如 ZooKeeper 的 watch 触发），中断不应导致状态错乱；
- 金融类系统中的对账线程，在等待上游结算结果期间，若被误中断可能导致账务不一致，需确保“等不到结果不退出”。
与 await() 的关键区别
对比标准 await()：
-
await()在等待中收到中断会立即抛出InterruptedException，调用方必须处理异常、恢复状态或传播中断； -
awaitUninterruptibly()完全屏蔽中断：中断状态会被暂存（Thread.interrupted()返回 true），但线程继续挂起；唤醒后可通过Thread.currentThread().isInterrupted()主动检查是否曾被中断。
注意：它仍要求调用前已持有对应 Lock，否则抛 IllegalMonitorStateException；唤醒后也仍需重新竞争并获取锁才能继续执行。
典型使用模式
正确写法必须包裹在 while 循环中，并置于 lock.lock() / finally unlock() 结构内：
Lock lock = new ReentrantLock();
Condition ready = lock.newCondition();
lock.lock();
try {
while (!isResourceAvailable()) {
ready.awaitUninterruptibly(); // 不因中断跳过检查
}
// 安全使用资源
} finally {
lock.unlock();
}
这种写法能避免虚假唤醒导致的逻辑错误，同时确保中断不会破坏条件检查的完整性。
使用时的注意事项
- 不要滥用：若业务本身需支持优雅关闭或超时熔断，应优先选
await(long, TimeUnit)或带中断处理的await()； - 中断状态不会丢失：唤醒后建议检查
Thread.interrupted()，决定是否在后续逻辑中主动退出或记录告警； - 无法替代超时控制：它不提供超时能力，长时间无 signal 可能导致线程永久挂起，必要时应配合监控或看门狗机制。
不复杂但容易忽略
