这段代码使用ReentrantReadWriteLock是否正确？

Question

我熟悉在一个账户和另一个账户之间转账时使用同步的并发示例，例如，两个账户的锁定是按账号顺序进行的，这样就不会发生死锁。

我想探索使用Reenter antReadWriteLock，因为在我看来，这将允许帐户对象的客户端进行并发读取，前提是没有客户端更新该对象。

我已经编写了代码并对其进行了测试，它似乎可以工作，但看起来有点难看，例如，Account类暴露其锁对象看起来有点奇怪，但它似乎必须这样做？还想知道是否有我没有发现的潜在bug。

getBalance（）方法在确保内存可见性方面做得对吗？

在getBalance（）中，try中的“return”看起来很难看，但是必须在锁仍然存在时读取balance字段吗？

private ReentrantReadWriteLock lock = new ReentrantReadWriteLock();

public void writeLock(){
    lock.writeLock().lock();
}
public void readLock(){
    lock.readLock().lock();
}
public void writeUnlock(){
    lock.writeLock().unlock();
}
public void readUnlock(){
    lock.readLock().unlock();
}

public void transferToSafe(Account b, BigDecimal amount){

    Account firstAccountToLock=null;
    Account secondAccountToLock=null;

    // Let the smaller account always get the first lock
    if (this.getAccountNo() < b.getAccountNo()){
        firstAccountToLock = this;
        secondAccountToLock = b;
    }
    else {
        firstAccountToLock = b;
        secondAccountToLock = this;
    }
    try {
        firstAccountToLock.writeLock();

        try {
            secondAccountToLock.writeLock();

            this.subtractFromBalance(amount);
            b.addToBalance(amount);

        }
        finally {
            secondAccountToLock.writeUnlock();
        }
    }
    finally {
        firstAccountToLock.writeUnlock();
    }
}

public BigDecimal getBalance(){
    try {
        this.readLock();
        return balance;
    }
    finally {
        this.readUnlock();
    }
}

Answer 1

您的锁顺序看起来很好，死锁预防机制也很好，但有两个建议是关于subtractFromBalance和addToBalance以确保正确性（您的代码可能已经这样做了）

>

在subtratFromBalance和addToBalance中进行验证，例如，如果量大于subtratFromBalance的当前余额，则抛出一个IllegalArgumentExctive或其他任何值（我假设不允许负余额）。您可能会在之前进行此验证，但您也需要在获得锁后进行验证。

在subtractFromBalance和addToBalance中的写锁上调用isHeldByCurrentThread，如果锁未保持，则引发异常。

如果您能够承受数据中的暂时不一致，那么您可以完全消除读锁定：使用原子参考