java try finally unlock 成语

Question

Javadoc 和一些答案 (Threads - Why a Lock has to be followed by try and finally) 指出：

在大多数情况下，应使用以下成语：

 Lock l = ...;
 l.lock();
 try {
     // access the resource protected by this lock
 } finally {
     l.unlock();
 }

我在标准 Java 库中看到了这种习惯用法的示例。 这是我使用它的例子。字段 acc1 和 acc2 代表银行帐户的一个众所周知的示例。主要约束是 acc 的值的总和 - 它应该是 0。

public class Main {
    int acc1;
    int acc2;

    ReadWriteLock lock = new ReentrantReadWriteLock();

    public int readSum() {
        lock.readLock().lock();
        try {
            return acc1 + acc2;
        } finally {
            lock.readLock().unlock();
        }
    }

    public void transfer() {
        lock.writeLock().lock();
        try {
            acc1--; // constraint is corrupted
                    // exception throwed here
            acc2++; // constraint is regained
        } finally {
            lock.writeLock().unlock();
        }
    }
}

我理解在读取情况下使用成语：如果在读取方法中抛出异常，其他线程仍然可以读取/写入一致的资源。但是如果在写方法中抛出异常，读方法可以读取不一致的资源。

为什么读取不一致的值比无限锁等待更可取？ 为什么 Java 库的作者更喜欢这种行为？

Answer 1

您可以回滚或向用户提供一些警告信息，但如果程序被阻止，您将无能为力。

我同意你所说的data consistency。在没有任何回滚操作或警告的情况下解锁 finally 部分是很危险的。

Answer 2

您在这里混淆了不同的概念。有：

1. 锁定，防止死锁，然后
2. 另一个维度，我们称之为“数据完整性”。

要点：这两者基本上是正交的。您正在解决其中一个问题并不能神奇地为您解决另一个问题！

即使您查看自己的示例，也会发现您在那里放置了 try/finally。但是那里没有catch！ 不惜一切代价 含义：如果抛出一些异常，该异常仍然被抛出，并且一些捕手将不得不处理它。

换句话说：如果您的“锁定”代码可能会遇到异常，那么您有责任以最有意义的方式处理它。

而且，从“系统”的角度来看：当您获得无限期锁定时，迟早会降低整个系统的性能。如果您遇到该异常一次，那么您将更频繁地遇到它。所以，很有可能你很快就会用完线程/锁；你的整个应用程序都会受到影响。这正是可以破坏分布式基础设施的问题——一个组件停止处理传入的请求。

长话短说：无限锁等待是您要防止的，因为它会严重影响您的应用程序的运行能力！

最后：当然，这是关于不同需求的平衡。但是，例如：假设您的在线商店丢失了您刚刚从购物车中删除商品的信息。是的，这对客户来说很烦人。但是比较一下：整个在线购物应用程序停止处理请求；因为锁定问题。哪个问题会对您的业务造成更大的伤害？