对于Lock.lock和Lock.unlock，我们将如何使用“最终尝试”

Question

请考虑以下代码。为了防止IndexOutOfBoundsException调用listIterator，我们使用读取器锁检索基于索引的iteartor，在stockCodes上写入操作时使用写入锁。

注意，我们没有使用任何锁定机制来使用listIterator来迭代，因为它来自CopyOnWriteArrayList。不需要锁定，因为不会抛出ConcurrentModificationException。

// stockCodesReaderLock is reader lock from java.util.concurrent.locks.ReadWriteLock
// stockCodes is CopyOnWriteArrayList
// Acquire iterator in a safe way.
stockCodesReaderLock.lock();
final int stockCodesSize = stockCodes.size();
if (currIndex < stockCodesSize) {
    listIterator = stockCodes.listIterator(currIndex);
}
stockCodesReaderLock.unlock();

我在想，我是否应该使用try/finally块，因为我看不到出现异常的任何机会。如果必须使用try/finally，我应该使用(A)还是(B)

我有什么需要吗？

(A)

try {
    stockCodesReaderLock.lock();
    final int stockCodesSize = stockCodes.size();
    if (currIndex < stockCodesSize) {
        listIterator = stockCodes.listIterator(currIndex);
    }
} finally {
    stockCodesReaderLock.unlock();
}

(B)

stockCodesReaderLock.lock();
try  {
    final int stockCodesSize = stockCodes.size();
    if (currIndex < stockCodesSize) {
        listIterator = stockCodes.listIterator(currIndex);
    }
} finally {
    stockCodesReaderLock.unlock();
}

Answer 1

其他受访者是对的:您应该始终使用，使用“尝试/最后”。

关于(A)或(B)是否正确，Sun似乎在JavaDoc of ReentrantReadWriteLock中推荐(B) (搜索“最终”以查看它)。我认为这是因为如果lock()方法失败，它可能会抛出一个异常:例如，JavaDoc表示它将在相同线程递归获取锁超过65535次的情况下抛出一个Error。

Answer 2

这是很好的防御性编程。如果您的代码发生了更改，因此无论出于任何原因(包括OutOfMemoryError)，主体都会抛出一个异常，那么您将很高兴没有将锁留在卡住状态。

我个人支持(B) --如果lock()方法本身要抛出异常，那么它仍然是平衡的。但在实践中我不认为这有多重要。