Java调用Lock.lock()未用lockInterruptibly()为何仍触发中断？

你的核心认知偏差是混淆了「锁获取等待阶段的中断响应规则」和「线程拿到锁之后运行阶段的中断响应规则」，两者的作用范围完全不同。 #

核心概念澄清 #

1. lock() 所谓的「不响应中断」仅作用于锁争抢阻塞阶段 #

ReentrantLock.lock()方法的不响应中断特性，有严格的生效场景：

• 仅当线程执行到lock()方法、因为锁被其他线程持有，处于阻塞排队等锁的状态时，收到中断信号不会抛出异常、不会退出等待，会一直阻塞直到拿到锁，拿到锁后会保留线程的中断标记交给后续业务代码处理。
• 一旦线程已经成功拿到锁、退出了lock()方法，后续执行的任何业务逻辑怎么响应中断，和lock()方法没有任何关系。

你的测试代码完全没有触发lock()的等锁阻塞场景：子线程启动后第一时间就拿到了锁（主线程当时正处于Thread.sleep(1000)状态，没有和它抢锁），等你在主线程调用t.interrupt()的时候，子线程早就跑完了lock()逻辑，正阻塞在Thread.sleep(5000)这行——而sleep方法本身就是会立即响应中断、抛出InterruptedException的方法，你捕获到的异常是sleep抛的，和锁的中断机制没有关联。

如果要验证lock()的不响应中断特性，需要构造「线程卡在lock()等锁阶段被中断」的场景，参考代码：

public static void main(String[] args) throws InterruptedException {
    Lock l = new ReentrantLock();
    // 主线程先持有锁不释放，让子线程后续争抢锁时必然阻塞
    l.lock();
    Thread t = new Thread(() -> {
        System.out.println("子线程尝试获取锁，进入阻塞等待");
        l.lock(); // 会一直阻塞在这里等锁
        try {
            System.out.println("子线程成功拿到锁");
        } finally {
            l.unlock();
        }
    });
    t.start();
    Thread.sleep(1000); // 确认子线程已经卡在lock()等待阶段
    t.interrupt();
    System.out.println("已向等锁的子线程发送中断信号");
    t.join(2000); // 等待2秒观察子线程状态
    // 输出为true，证明lock()等锁时没有响应中断退出，仍然在阻塞
    System.out.println("子线程当前存活状态：" + t.isAlive()); 
}

作为对比，把上面代码里的l.lock()换成l.lockInterruptibly()，子线程在等锁时收到中断信号会立即抛出InterruptedException退出等待，不需要等拿到锁。

2. 不存在「真正不可中断的线程」 #

Java的中断是协作式信号机制，没有任何方法能让线程完全不接收中断信号：

• 所谓「不响应中断」只是某段代码的实现逻辑选择：比如lock()等锁时遇到中断不抛异常继续等，只是方法层面的处理策略，不是线程本身被设置成了不可中断。
• 线程拿到锁之后执行的代码，不管是sleep、wait、阻塞IO还是其他业务逻辑，要不要响应中断、怎么处理中断，都由对应代码的实现决定，和之前拿锁用的是lock()还是lockInterruptibly()无关。
• 就算你写一个完全不判断中断标记的死循环，也只是代码逻辑忽略了中断信号，内核依然可以把中断标记传递给线程，不存在物理上无法被中断的用户态线程。

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