java.util.concurrent.locks.Lock的AutoCloseable包裝中存在風險？

隨着在Java 7中引入的try-with-resource，我驚訝地發現Lock未被改裝成AutoCloseable。這似乎是很簡單的，所以我下面增加它自己：java.util.concurrent.locks.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我在想這不應該是有一個很好的理由。有人知道嗎？

來源

2013-05-15 Miserable Variable

@rxg我將恢復大部分編輯，我的驚喜不是當它被引入時，但最近當我用它來鎖 –

沒有probs，但你能修復AutoCloseable的鏈接嗎？ – rxg

這是當try-with-resources在2月/ 2009年3月提出了一個很大的爭論

喬希布洛赫，該提案的作者，他表示「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。

來源

2013-06-11 11:49:21 rxg

謝謝你的信息;對我來說，鎖似乎是一種資源，但也許有一些我缺少的東西。在Spring世界工作，從包裝器中獲得的性能是無關緊要的。 –

@MisrableVariable：鎖是一種資源，至少對我和Dijkstra（：D）來說，參見例如。 [銀行家的算法描述]（http://en.wikipedia.org/wiki/Banker's_algorithm#Resources）。沒有必要每次都創建一個新對象（你只需要一個具有「close」方法的東西並且可以多次使用它）。 – maaartinus

@maaartinus恐怕我不明白你在說什麼。如果你有一個close方法，那麼你還需要一個open方法，這是create類爲Lock類所做的。 –

java.util.concurrent.locks.Lock的AutoCloseable包裝中存在風險？

回答

相關問題