在 Java 中，是否有必要在 InterruptedException 之后调用 unlock，还是应该避免 unlock？答案

【问题标题】：In Java, is it necessary to call unlock after a InterruptedException, or should unlock be avoided?在 Java 中，是否有必要在 InterruptedException 之后调用 unlock，还是应该避免 unlock？
【发布时间】：2014-02-20 16:34:54
【问题描述】：

在下面的代码sn-p中，我不确定是否在InterruptedException之后设置locked为false：

private static Lock lock = new ReentrantLock(true);

void foo() {
    final long timeout = 30;
    boolean locked = false;
    try {
        locked = lock.tryLock(timeout, TimeUnit.SECONDS);
        // Do time consuming work that might be interrupted
        // ...
        // ...
    } catch (InterruptedException e1) {
        locked = false;  // Is this correct????
    } finally {
        if( locked) {
            lock.unlock();
        }
    }
}

编辑：我在原始示例中省略了“可能被中断的耗时工作”，所以看起来我是在询问 tryLock 的用法，而不是在线程中断的情况下会发生什么。那么如果锁被授予了，那么线程就被中断了。这会自动释放锁，还是必须在finally 子句中发生？

Edit2：看来我对 Java 中的线程中断有误解。如果在该线程上调用了Thread.interrupt()，则Thread.interrupted() 为真，而不是引发InterruptedException，除非包含以下代码：

if (Thread.interrupted()) {
    throw new InterruptedException();
}

这会引发我担心的模棱两可的 InterruptedException。所以看起来这里的教训是，如果你正在使用 trylock(timeout)，那么不要抛出 InterruptedException。

【问题讨论】：

locked = false; 在 catch 块中是多余的。
查看我的编辑，其中实现了锁定，但线程中断了。
如果包含Edit2中在线程中断情况下抛出InterruptedException的代码，那么在catch块中设置locked = false将是一个非常糟糕的主意。

标签： java locking mutex

【解决方案1】：

既然你没有成功锁上锁，那么你不应该解锁它。

【讨论】：

这似乎是正确的。我在想，如果线程在获得锁后被中断，那么就会发生 InterruptedException。但事实并非如此。