当前位置：首页 > article >正文

理解JVM中的死锁:原因及解决方案

article 2024/11/20 2:23:57

在这里插入图片描述
死锁是并发应用程序中的常见问题。在此类应用程序中，我们使用锁定机制来确保线程安全。此外，我们使用线程池和信号量来管理资源消耗。然而，在某些情况下，这些技术可能会导致死锁。

在本文中，我们将探讨死锁、死锁出现的原因以及如何分析和避免潜在的死锁情况。

理解死锁

简单地说， 当两个或多个线程在等待另一个线程持有的另一个资源可用时互相阻塞时就会发生死锁 。

JVM 并非为从死锁中恢复而设计的。因此，根据这些线程的操作，当发生死锁时，整个应用程序可能会停滞，或者会导致性能下降。

死锁示例

为了说明死锁现象，让我们创建一个在两个账户之间转移资金的模拟：

private static void transferFunds(Account fromAccount, Account toAccount, BigDecimal amount) {
    synchronized (fromAccount) {
        System.out.println(Thread.currentThread().getName() + " acquired lock on " + fromAccount);
        synchronized (toAccount) {
            transfer(fromAccount, toAccount, amount);
        }
    }
}

public static void transfer(Account fromAccount, Account toAccount, BigDecimal amount) {
    if (fromAccount.getBalance().compareTo(amount) < 0)
        throw new RuntimeException("Insufficient funds.");
    else {
        fromAccount.withdraw(amount);
        toAccount.deposit(amount);
        System.out.println(Thread.currentThread()
                .getName() + " transferred $" + amount + " from " + fromAccount + " to " + toAccount);
    }
}

乍一看，上面的代码可能没有明显地表明 transferFunds() 方法如何导致死锁。似乎所有线程都以相同的顺序获取锁。但是，锁的顺序取决于传递给 transferFunds() 方法的参数的顺序。

在我们的例子中，当两个线程同时调用transferFunds() 方法时，可能会发生死锁，一个线程将资金从account1转移到account2，另一个线程将资金从account2转移到account1 ：

Thread thread1 = new Thread(() -> transferFunds(account1, account2, BigDecimal.valueOf(500)));
Thread thread2 = new Thread(() -> transferFunds(account2, account1, BigDecimal.valueOf(300)));

thread1.start();
thread2.start();

线程1获取**帐户 1的锁并等待帐户 2的锁，而线程 2持有**帐户 2的锁并等待帐户 1的锁。

修复死锁

为了修复示例中的死锁， 我们可以定义锁的顺序，并在整个应用程序中一致地获取它们 。这样，我们可以确保每个线程以相同的顺序获取锁。

引入对象排序的一种方法是利用它们的hashCode值。此外， 我们还可以使用System.identityHashCode ，它返回 hashCode() 方法的值 。

让我们修改我们的transferFunds()方法并使用**System.identityHashCode引入锁排序：

public static void transferFunds(final Account fromAccount, final Account toAccount, final BigDecimal amount) {
    int fromHash = System.identityHashCode(fromAccount);
    int toHash = System.identityHashCode(toAccount);

    if (fromHash < toHash) {
        synchronized (fromAccount) {
            System.out.println(Thread.currentThread().getName() + " acquired lock on " + fromAccount);
            synchronized (toAccount) {
                transfer(fromAccount, toAccount, amount);
            }
        }
    } else if (fromHash > toHash) {
        synchronized (toAccount) {
            System.out.println(Thread.currentThread().getName() + " acquired lock on " + toAccount);
            synchronized (fromAccount) {
                transfer(fromAccount, toAccount, amount);
            }
        }
    } else {
        synchronized (sameHashCodeLock) {
            synchronized (fromAccount) {
                System.out.println(Thread.currentThread().getName() + " acquired lock on " + fromAccount);
                synchronized (toAccount) {
                    transfer(fromAccount, toAccount, amount);
                }
            }
        }
    }
}

在上面的代码示例中，我们计算了fromAccount和toAccount的哈希码，并根据给定的值定义了锁顺序。

由于两个对象可以具有相同的哈希码，我们需要添加额外的逻辑并引入第三个sameHashCodeLock锁：

private static final Object sameHashCodeLock = new Object();

在else语句中，我们首先获取了sameHashCodeLock上的锁，确保一次只有一个线程获取Account对象的锁。这消除了死锁的可能性。

避免死锁方法

进一步讨论如何避免死锁。我们应该记住，如果我们的程序一次只获取一个锁，它就永远不会遇到锁排序死锁。

指定锁定时间

我们的系统从死锁中恢复的一种方法是使用 定时锁定尝试 。我们可以使用Lock接口中的 tryLock() 方法。在该方法中，我们可以设置超时，如果方法无法获取锁，则超时后返回失败。这样，线程就不会无限期地阻塞：

while (true) {
    if (fromAccount.lock.tryLock(1, SECONDS)) {
        System.out.println(Thread.currentThread().getName() + " acquired lock on " + fromAccount);
        try {
            if (toAccount.lock.tryLock(1, SECONDS)) {
                try {
                    transfer(fromAccount, toAccount, amount);
                } finally {
                    toAccount.lock.unlock();
                }
            }
        } finally {
            fromAccount.lock.unlock();
        }
    }

    SECONDS.sleep(10);
}

我们不应该忘记在finally块中调用 unlock() 方法。

使用线程转储检测死锁

最后，让我们看看如何使用线程转储和fastThread工具检测死锁。线程转储包含每个正在运行的线程的堆栈跟踪和锁定信息。

导致死锁的生成的线程转储的一部分如下所示：

"Thread-0":
  waiting to lock monitor 0x000060000085c340 (object 0x000000070f994f08, a com.tier1app.deadlock.Account),
  which is held by "Thread-1"

"Thread-1":
  waiting to lock monitor 0x0000600000850410 (object 0x000000070f991c90, a com.tier1app.deadlock.Account),
  which is held by "Thread-0"