Java同步机制之死锁

姊妹篇《 Java同步机制之synchronized 》 姊妹篇《 Java同步机制之volatile

指两个或两个以上的进程在执行过程中,因争夺资源而造成的一种互相等待的现象,若无外力作用,它们都将无法推进下去。

先来看一则新闻:

《武器贸易条约》是联合国为监管八类常规武器的国际贸易制定的共同国际标准,该条约于2013年4月2日在联合国大会上通过。2013年6月3日在纽约联合国总部开放供所有国家签署,当天签署的国家超过60个。不过,美国、中国和俄罗斯这3个安理会常任理事国当天没有签约。后来,最大武器生产和出口国美国签署该条约,但未正式批准。中国和俄罗斯还未签署这一条约。2019年4月26日,美国总统特朗普在印第安纳州举行的美国步枪协会年会上宣布,《武器贸易条约》是一个“严重误导的条约”,美国将撤销在该条约上的签字。特朗普将要求国会参议院停止该条约的批准程序,使美国退出联合国《武器贸易条约》。

其实是这样的: 美国:我等俄罗斯先签了我就签; 俄罗斯:我等中国先签我了就签; 中国:我等美国先签了我就签;

Java同步机制之死锁

算了,不等了。因为死了。

代码示例

当一个线程永远的持有一个锁,并且其他线程线程都尝试获得锁时,那么它们将永远被阻塞。在线程A持有锁a并且想获得锁b时,线程B持有锁b并尝试获得a时,那么这两个线程将永远的等待下去。这种情况就是最简单的死锁形式:

public class TestDead {
    private Object a;
    private Object b;

    public TestDead(Object a, Object b) {

        this.a = a;
        this.b = b;
    }

    public void funOne(){
        synchronized (a){
            System.out.println("finOne");
            try {
                Thread.sleep(5);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            funTwo();
        }
    }
    public void funTwo(){
        synchronized (b){
            System.out.println("finTwo");
            try {
                Thread.sleep(5);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            funOne();
        }
    }

}

TestDead testDead = new TestDead(new Object(), new Object());
new Thread(new Runnable() {
            @Override
            public void run() {
                testDead.funOne();
            }
        }).start();
new Thread(new Runnable() {
            @Override
            public void run() {
                testDead.funTwo();
            }
        }).start();
复制代码

程序的运行结果如下:

Java同步机制之死锁

上面的代码会造成线程的假死,在没有外力作用下。两个线程会永远处于阻塞的状态,等待一把永远不可以释放的锁。

产生死锁的必要条件

  • 互斥条件:指进程对所分配到的资源进行排它性使用,即在一段时间内某资源只由一个进程占用。如果此时还有其它进程请求资源,则请求者只能等待,直至占有资源的进程用毕释放。
  • 占有且等待:指进程已经保持至少一个资源,但又提出了新的资源请求,而该资源已被其它进程占有,此时请求进程阻塞,但又对自己已获得的其它资源保持不放。
  • 不可强行占有:指进程已获得的资源,在未使用完之前,不能被剥夺,只能在使用完时由自己释放。
  • 循环等待条件:指在发生死锁时,必然存在一个进程——资源的环形链,即进程集合{P0,P1,P2,···,Pn}中的P0正在等待一个P1占用的资源;P1正在等待P2占用的资源,……,Pn正在等待已被P0占用的资源。

这四个条件是死锁的必要条件,只要系统发生死锁,这些条件必然成立,而只要上述条件之一不满足,就不会发生死锁。

死锁的避免与诊断

与许多其他并发危险一样,死锁造成的影响很少会立刻呈现出来。如果一个类可能发生死锁,并不意味这每次都会发生死锁,而是只表示有可能。当死锁发生时,往往是在最糟糕的时刻——在高负载情况下。 上文中的代码锁产生的死锁可以通过 查看是否存在嵌套的锁获取操作 来检查是否存在死锁的可能。但有时候获取多个锁的操作并不会这么明显。

要避免出现死锁的问题,只需要破坏四个条件中的任何一个就可以了:

  • 打破互斥条件。即允许进程同时访问某些资源。当然,这种方法试用范围并不广,因为有的资源不允许并发访问,或者存在线程安全问题。
  • 打破占有且等待条件。可以通过规定在任何情况下,一个线程获取一个锁之后,必须归还了锁之后才能请求另一锁
  • 打破不可抢占条件。除非线程自己还钥匙,否则线程会一直占有钥匙,是形成不可抢占条件的原因。允许进程强行从占有者那里夺取某些资源。就是说,当一个进程已占有了某些资源,它又申请新的资源,但不能立即被满足时,它必须释放所占有的全部资源,以后再重新申请。
  • 打破循环等待条件。采用这种策略,即把资源事先分类编号,按号分配,可以强制规定任何线程取锁的顺序。

其他活跃性危险

尽管死锁是最常见的活跃性危险,但在并发中还存在一些其他的活跃性危险,包括:饥饿、活锁等

饥饿:当线程由于无法访问它所需要的资源而不能继续执行时,就发生了饥饿。最常见的引发饥饿的资源就是CPU的时钟周期。 如果对线程的优先级使用不当,或者在持有锁时进行一些无法结束的操作(无限循环),就有可能产生饥饿,因为其他需要这个锁的线程永远无法得到它。

活锁:我为它赋予了一个充满神话色彩的名字 西西弗斯锁 ,西西弗斯神话 这是另一种形式的活跃性问题,尽管它不会阻塞线程,但也不能继续向下执行,因为线程将不断重复执行相同的操作,而且总会失败。 当多个相互协作的线程都对彼此进行响应从而修改各自状态,并使任何一个线程都无法执行时,就会发生活锁。 活锁通常发生在处理事务的代码中:如果不能成功的处理某个消息,那么消息处理机制将回滚整个事务,并将它重新放置在队列的开头。因此,处理事务的代码将被反复调用,并返回相同的错误结果,虽然处理消息的线程没有被阻塞,但也无法执行下去。

小结

死锁(以及其他活跃性问题)是一个非常严重的问题,因为当它出现的时候,除了中止应用程序之外没有其他任何方法可以修复这种故障。在设计时应 确保线程在获取多个锁时采用一致性的顺序

原文 

https://juejin.im/post/5d655cc26fb9a06ace525f8b

本站部分文章源于互联网,本着传播知识、有益学习和研究的目的进行的转载,为网友免费提供。如有著作权人或出版方提出异议,本站将立即删除。如果您对文章转载有任何疑问请告之我们,以便我们及时纠正。

PS:推荐一个微信公众号: askHarries 或者qq群:474807195,里面会分享一些资深架构师录制的视频录像:有Spring,MyBatis,Netty源码分析,高并发、高性能、分布式、微服务架构的原理,JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源,目前受益良多

转载请注明原文出处:Harries Blog™ » Java同步机制之死锁

赞 (0)
分享到:更多 ()

评论 0

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址