相关疑难解决方法(0)

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

来自C++背景,我是RAII模式的忠实粉丝.我已经广泛使用它来处理内存管理和锁管理以及其他用例.

使用Java 1.7,我看到我可以使用try-with-resources模式来创建RAII模式.

我使用RAII创建了一个示例应用程序并且它可以工作,但是我看到java中的编译器警告.

样品申请

try(MyResource myVar = new MyResource(..))
{
    //I am not using myVar here 
}

我收到以下错误

warning: [try] auto-closeable resource node is never referenced in body of corresponding try statement

我理解警告,这意味着我应该在try块中使用变量,我不需要一直这样做.

看看这个我假设Java并没有真正支持RAII,我可能误用了仅用于资源管理的功能,而不是C++中的RAII等价物.

几个问题:

1. 我的理解是否正确？
2. 忽视这些警告有多大风险？
3. 如何通过蚂蚁忽略这些警告？
4. 我有一个简单的方法来克服这个问题吗？

for 4我正在考虑将构造函数调用拆分为更简单的构造函数和像这样的实例方法

try(MyResource myVar = new Resource())
{
   myvar.Initialize()
   ....

}

这解决了编译器的问题,但从设计的RAII中获取了本质.