悲剧的根源---死锁

但凡使用到了锁，就需要考虑死锁这样一个东西。

死锁的出现不是偶然的，下面我们举一个例子来看一下：

void transfer(DeadLock target,int amt) {

// 锁定转出账户

synchronized (this) {//1 先锁定本对象因为对于两个对象来说，this都是本身，所以各自先占有了本身，就会出现死锁

// 锁定转入账户

synchronized (target) {//2 在锁定需要的对象假如这两个对象互相需要，就会出现死锁

if (this.balance >= amt) {

this.balance -= amt;

target.balance += amt;

System.out.println(balance);

}

}

}

}

观察上面的代码：我们可以看到在加粗的部分，如果此时账号A对账号B转账，账号B也在对账号A转账，这个时候，账号A获得了锁，也就是本身，他就会去尝试获得账号B这个锁，但是在此时，账号B也获得了锁，也是它本身，然后它尝试去获得锁A，这个时候，两个线程都尝试获取对方的锁，但是是获取不到的，那么就出现死锁问题了。

这里归一下死锁出现的四种原因：

1：互斥，共享资源 X 和 Y只能被同一个线程占有。（这是synchronized的性质，无法避免）。

2：占有且等待：线程A已经获得了X资源，在等待Y资源时一直占有X资源不释放。

3：其他线程无法抢占线程A已占有的资源。

4：循环等待，线程 T1 等待线程 T2 占有的资源，线程 T2 等待线程 T1 占有的资源，就是循环等待。

未来解决死锁问题，我们现在又两种解决办法。

针对第二种引起死锁的原因，我们可以引入一个更高级的角色，类似图书馆管理员的角色，只有当一次性申请所有资源的时候，才能成功。

针对第三种原因，我们可以让获得锁对象根据顺序排序，不管是哪一个对象，都首先去获得Id小的哪一个锁，这样就不会出现两个线程获得的锁不一样的情况了：

// 转账

void transfer(SolveMethodByLoop target,int amt) {// 这样就能保证，不管是哪一个对象，先申请的都是同一个锁,相较于破坏破坏占有且等待条件，时间好了很多

SolveMethodByLoop left =this;// 1

SolveMethodByLoop right = target;// 2

if (this.id > target.id) {// 3

left = target;// 4

right =this;// 5

}// 6

// 锁定序号小的账户

synchronized (left) {

// 锁定序号大的账户

synchronized (right) {

if (this.balance > amt) {

this.balance -= amt;

target.balance += amt;

}

}

}

}