aqs中锁获取的中断响应取决于方法：acquireinterruptibly立即且唤醒时均响应中断；acquire不响应，仅延迟恢复中断状态；tryacquirenanos支持超时与中断响应。

在 Java AQS（AbstractQueuedSynchronizer）中，获取锁时对线程中断的响应方式取决于你调用的是哪种获取方法：是否可响应中断，以及中断发生时机（是在等待队列中阻塞时，还是在尝试获取锁的瞬态过程中）。

可中断获取：acquireInterruptibly

这是 AQS 提供的、明确支持响应中断的锁获取方式。它会在以下两个关键点检查中断状态：

• 进入等待前：先尝试 tryAcquire，若失败，则将当前线程构造成 Node 加入同步队列；此时若线程已被中断（Thread.interrupted() 返回 true），直接抛出 InterruptedException，不入队。
• 在队列中挂起等待时：调用 LockSupport.park(this) 阻塞后，一旦被中断唤醒，会再次检查中断状态，并在后续出队/清理逻辑中抛出异常，而不是静默忽略或继续等待。

也就是说，acquireInterruptibly 是“**立即响应 + 唤醒响应**”双保险，确保中断不会被吞掉。

不可中断获取：acquire

acquire 方法默认**不响应中断**。即使线程在 park 期间被中断，AQS 也仅将其标记为“已中断”，但不会抛异常，而是继续循环尝试获取锁（通过 shouldParkAfterFailedAcquire 和 parkAndCheckInterrupt）。注意：parkAndCheckInterrupt 会返回中断状态，但 acquire 的主循环中并未处理该返回值——它只把它当作一个“是否曾被中断过”的信号，最终在获取成功后，才通过 selfInterrupt() 补上一次中断（即恢复中断状态），但不会提前退出。

所以使用 acquire 时，中断只是被“延迟传递”，线程仍会一直等到拿到锁为止。

Alibabacloud Sdk Client Initialization For Java

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

超时获取：tryAcquireNanos

该方法既支持超时，也支持响应中断。内部逻辑融合了 acquireInterruptibly 的中断检查和基于纳秒的自旋+park 策略。只要在等待过程中任意时刻检测到中断，就立即抛出 InterruptedException，并取消剩余等待。

典型场景如 ReentrantLock.lockInterruptibly() 就是基于 acquireInterruptibly；而 lock.tryLock(timeout, unit) 则对应 tryAcquireNanos。

自定义同步器中的注意事项

如果你继承 AQS 实现自己的同步组件，需特别注意：

• 不要在 tryAcquire 中屏蔽中断：该方法应尽量轻量、无阻塞；若需等待，应交由 AQS 主流程处理，而非自己调用 park 或忽略 Thread.interrupted()。
• 中断响应策略要统一：公开的 acquire 方法（如 lock() / lockInterruptibly()）应严格对应底层 AQS 调用，避免语义错乱（例如对外声称可中断，内部却用 acquire）。
• 清理工作要可靠：当中断导致节点提前退出等待时，AQS 会自动执行 cancelAcquire，将节点设为 CANCELLED 并从队列中剔除。你的 tryAcquire 不必手动清理，但需确保状态变更（如计数器、条件判断）与该清理逻辑兼容。

不复杂但容易忽略。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南