1700451439
1700451440
不剥夺条件：线程已获得的资源在未使用完之前，不能强行剥夺。
1700451441
1700451442
循环等待条件：若干线程之间形成一种头尾相接的循环等待资源关系。
1700451443
1700451444
只有满足了这些条件才可能产生线程死锁，这也同时告诫我们如果要解决线程死锁问题，就必须从这四个条件入手，一般情况下可以按照以下两种方式来解决：
1700451445
1700451446
（1）避免或减少资源共享
1700451447
1700451448
一个资源被多个线程共享，若采用了同步机制，则产生的死锁可能性很大，特别是在项目比较庞大的情况下，很难杜绝死锁，对此最好的解决办法就是减少资源共享。
1700451449
1700451450
例如一个B/S结构的办公系统可以完全忽略资源共享，这是因为此类系统有三个特征：一是并发访问不会太高，二是读操作多于写操作，三是数据质量要求比较低，因此即使出现数据资源不同步的情况也不可能产生太大的影响，完全可以不使用同步技术。但是如果是一个支付清算系统就必须慎重考虑资源同步问题了，因为此类系统一是数据质量要求非常高（如果产生数据不同步的情况那可是重大生产事故），二是并发量大，不设置数据同步则会产生非常多的运算逻辑失效的情况，这会导致交易失败，产生大量的“脏”数据，系统可靠性将大大降低。
1700451451
1700451452
（2）使用自旋锁
1700451453
1700451454
回到前面的例子，线程A在等待线程B释放资源，而线程B又在等待线程A释放资源，僵持不下，那如果线程B设置了超时时间是不是就可以解决该死锁问题了呢？比如线程B在等待2秒后还是无法获得资源，则自行终结该任务，代码如下：
1700451455
1700451456
public void b2（）{
1700451457
1700451458
try{
1700451459
1700451460
//立刻获得锁，或者2秒等待锁资源
1700451461
1700451462
if（lock.tryLock（2，TimeUnit.SECONDS））{
1700451463
1700451464
System.out.println（“进入B.b2（）”）；
1700451465
1700451466
}
1700451467
1700451468
}catch（InterruptedException e）{
1700451469
1700451470
//异常处理
1700451471
1700451472
}finally{
1700451473
1700451474
//释放锁
1700451475
1700451476
lock.unlock（）；
1700451477
1700451478
}
1700451479
1700451480
}
1700451481
1700451482
上面代码中使用tryLock实现了自旋锁（Spin Lock），它跟互斥锁一样，如果一个执行单元要想访问被自旋锁保护的共享资源，则必须先得到锁，在访问完共享资源后，也必须释放锁。如果在获取自旋锁时，没有任何执行单元保持该锁，那么将立即得到锁；如果在获取自旋锁时锁已经有保持者，那么获取锁操作将“自旋”在那里，直到该自旋锁的保持者释放了锁为止。在我们的例子中就是线程A等待线程B释放锁，在2秒内不断尝试是否能够获得锁，达到2秒后还未获得锁资源，线程A则结束运行，线程B将获得资源继续执行，死锁解除。
1700451483
1700451484
对于死锁的描述最经典的案例是哲学家进餐（五位哲学家围坐在一张圆形餐桌旁，人手一根筷子，做以下两件事情：吃饭和思考。要求吃东西的时候停止思考，思考的时候停止吃东西，而且必须使用两根筷子才能吃东西），解决此问题的方法很多，比如引入服务生（资源调度）、资源分级等方法都可以很好地解决此类死锁问题。在我们Java多线程并发编程中，死锁很难避免，也不容易预防，对付它的最好办法是测试：提高测试覆盖率，建立有效的边界测试，加强资源监控，这些方法能使死锁无处遁形，即使发生了死锁现象也能迅速查找到原因，提高系统的可靠性。
1700451485
1700451486
1700451487
1700451488
[
上一页 ]
[ :1.700451439e+09 ]
[
下一页 ]