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

Question

随着try-with-resourceJava 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我认为必须有一个很好的理由这不应该做.有人知道吗？

Answer 1

这是try-with-resources2009年2月/ 3月提出的一个大辩论.

该提案的作者Josh Bloch说:" 这个结构只针对一件事,一件事:资源管理.它不是为锁定而设计的. "

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

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

• 无法在Java 7中向接口添加方法
• 创建一个实现正确接口的额外包装器对象的性能
• 哲学上反对Lock从文件句柄中获取不同类型的资源(例如,创建a Lock不需要调用该lock方法)

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