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说：“This construct was designed for one thing and one thing only: resource management. It was not designed for locking.”

有一个单独的建议单独覆盖锁，但它没有到达任何地方。

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

无法在Java 7中向接口添加方法
创建实现正确接口的额外包装器对象的性能提升
对Lock作为文件句柄中不同类型资源的哲学反对意见（例如创建Lock并不需要调用lock方法）

您可以在the archive page上关注所有历史悠久的狂欢，例如this thread。

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

1 个答案: