05 | 一不小心就死锁了，怎么办？

synchronized(Account.class) 锁了Account类相关的所有操作。相当于文中说的包场了，只要与Account有关联，通通需要等待当前线程操作完成。while死循环的方式只锁定了当前操作的两个相关的对象。两种影响到的范围不同。

while循环是不是应该有个timeout，避免一直阻塞下去？

之前遇到死锁，我就是用资源id的从小到大的顺序去申请锁解决的

while(actr.apply(this, target)); --> while(!actr.apply(this, target)); 我感觉应该是这样，老师，我理解错了？

老师，请问一下，在实际的开发中，account对象应该是从数据库中查询出来的吧，假如A转B，C转B一起执行，那B的account对象如何保证是同一个对象，不太理解。。。

@阿官 我来回答下你的问题 以下是阿官的问题 ------------------------------------------------------- 老师，在破坏占用且等待的案例中，为何申请完两个账户的资源后还需要再分别锁定this和target账户呢？ ------------------------------------------------------- 因为还存在其他业务啊 比如客户取款 这个时候也是对全局变量balance做操作 如果不加锁 并发情况下会出问题 老师你看我说的对吗😄😄

老师为什么按序申请资源就可以破坏循环等待条件呢？这点没有看懂求解答

老师，感觉下面的代码也能避免死锁，并且能实现功能： void transfer(Account target, int amt){ boolean isTransfer = false; // 锁定转出账户 synchronized(this){ if (this.balance > amt) { this.balance -= amt; isTransfer = true; } if (!isTransfer) { return; } // 锁定转入账户 synchronized(target){ target.balance += amt; } } 反映到现实中的场景：服务员A拿到账本1先判断余额够不够，够的话先扣款，再等待其他人操作完账本2，才增加它的额度。 但是这样转账和到账就存在一个时差，现实生活中也是这样，转账不会立马到账，短信提醒24小时内到账，所谓的最终一致性。 老师帮忙看看这样实现会不会有啥其他问题？

存在性能差距，虽然申请的时候加锁导致单线程访问，但是hash判断和赋值时间复杂度低，而在锁中执行业务代码时间长很多。 申请的时候单线程，但是执行的时候就可以多线程了，这里性能提升比较明显 想问问老师，如何判断多线程的阻塞导致的问题呢？有什么工具吗

最常见的就是B转A的同时，A转账给B，那么先锁B再锁A，但是，另一个线程是先锁A再锁B，然而，如果两个线程同时执行，那么就是出现死锁的情况，线程T1锁了A请求锁B，此时线程T2锁了B请求锁A，都在等着对方释放锁，然而自己都不会释放锁，故死锁。 最简单的办法，就是无论哪个线程执行的时候，都按照顺序加锁，即按照A和B的id大小来加锁，这样，无论哪个线程执行的时候，都会先加锁A，再加锁B，A被加锁，则等待释放。这样就不会被死锁了。