java.util.concurrent.locks.Locks.Lock 的 AutoCloseable 包装器中存在任何风险吗？

java try-with-resources raii auto-close

2022-09-02 13:14:23

随着在Java 7中引入的资源试用，我惊讶地发现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，我认为一定有充分的理由不应该这样做。有人知道吗？

答案 1

这是2009年2月/3月提出的一场大辩论。try-with-resources

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

有一个单独的提案要单独覆盖锁，但它没有得到任何进展。

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

无法在 Java 7 中向接口添加方法
创建实现正确接口的额外包装器对象的性能损失
哲学上反对成为与文件句柄不同的资源（例如，创建a不需要调用该方法）LockLocklock

您可以在存档页面上关注所有历史的argy-bargy，例如这个线程。

答案 2