死锁，java多线程中最头痛的问题之一

说一个曾今遇到的‘故事’，说是有这么一个功能：玩家需要新增一个体力消耗点，这个体力消耗点主要是用于特殊副本关卡的体力消耗使用。已消耗的体力点是每日跨天重置的，消耗通过统一的上限值控制，而这个上限值是可变的，上限值加成公式是：体力点上限 = 玩家当前等级*一个固定比例值 + 玩家当前社团等级*另一个固定比例值。由于体力点上限的加成是通过两个等级变化量来控制的，所以为了保证两个等级变化与上限值变化的一致性，代码中在对体力上限值进行修改时分别对玩家等级变化和社团等级变化加了悲观锁（synchronized）

伪代码：

//玩家等级发生变化时，对体力上限进行修改，为保证数据一致性，同时锁住社团等级
                    synchronized (playerLevel){
                        synchronized (unionLevel){
                            areHp[0] = playerLevel * playerRatio + unionLevel * unionRatio;
                        }
                    }



//社团等级发生变化时，对体力上限进行修改，为保证数据一致性，同时锁住玩家等级
                    synchronized (unionLevel){
                        synchronized (playerLevel){
                            areHp[0] = playerLevel * playerRatio + unionLevel * unionRatio;
                        }
                    }

在某些情况下，这个代码也是可运行的，内网测试人员较少时，社团等级或玩家等级单一变化时，
 但如果发生在线上，假如某个玩家社团和玩家等级同时发生了变化，那么玩家线程和社团线程就可能同时发生上述两个请求，如此两个线程互相持有对方需访问的资源，这自然就造成了死锁。

而这作为一个引子，不过是引发一下大家的思考，为的是进一步探究死锁的根源，以及发生后的处理方案。

死锁：是指多进程（或线程）在运行过程中，因争夺资源而造成的一种僵局，处于这种情况下，若无外力作用，它们将无法向前推荐。

例如：有两个线程 A 和 B，有两个锁 x 和 y。

        线程A按照先获取 x锁再获取 y锁的顺序执行，

        线程B按照先获取 y锁再获取 x锁的顺序执行，

两个线程同时执行，最后就会变成线程A等待线程B手中的y锁，线程B等待线程A手中的x锁。

而产生死锁的原因无非两点：竞争资源 和 进程（线程）间推进顺序非法。

1、竞