java.util.concurrent.locks.Lock的AutoCloseable包装中的任何风险？

Question

通过Java 7中引入的try-with-resource ，我惊讶地发现Lock还没有被改装为AutoCloseable 。 它似乎相当简单，所以我自己添加如下：

class Lock implements AutoCloseable {
    private final java.util.concurrent.locks.Lock _lock;
    Lock(java.util.concurrent.locks.Lock lock) {
        _lock = lock;
        _lock.lock();
    }
    @Override 
    public void close() {
        _lock.unlock();
    }
}

这适用于AutoCloseableReentrantReadWiteLock类，用法如下：

try (AutoCloseableReentrantReadWiteLock.Lock l = _lock.writeLock()) {
    // do something
}        

由于这似乎是直接和规范使用自动关闭RAII我认为必须有一个很好的理由这不应该做。 有人知道吗？

Answer 1

在2009年2月/ 3月提出try-with-resources时，这是一个很大的争论。

该提案的作者Josh Bloch说：“ 这个结构只针对一件事，一件事：资源管理。它不是为锁定而设计的。 ”

有一个单独的提议单独涵盖锁，但它没有得到任何地方。

我认为没有涵盖锁的主要原因是：

• 无法在Java 7中向接口添加方法
• 创建一个实现正确接口的额外包装器对象的性能
• 对来自文件句柄的Lock是一种不同类型的资源的哲学反对（例如，创建Lock不需要调用lock方法）

您可以在归档页面上关注所有历史argy-bargy，例如此主题 。