性能文章>类初始化导致死锁>

类初始化导致死锁原创

2年前
845405

一张图简单描述死锁

image.png
如上图,Thread1 拿到了 object1,Thread2 拿到了 object2,但是现在 Thread1 需要拿到 object2 的锁才能继续往下,Thread2 又要拿到 object1 才能继续往下,于是哪个线程都无法得到满足继续往下来释放对方所需要的锁对象,从而造成了死锁。

概述

之前写过关于类加载死锁的文章“消失的死锁”,说的是类加载过程中发生的死锁,我们从线程dump里完全看不出死锁的迹象,但是确实发生了死锁,没了解的建议看看我公众号上相关的文章。

本文要说的是另外一个问题,之前在生产环境上碰到,是类初始化导致的死锁,恩,你没看错,确实是类初始化导致的死锁,我之前写过一篇文章,不可逆的类初始化过程,这篇文章可以助你了解类的初始化过程,另外也写过一篇JDK的sql设计不合理导致的驱动类初始化死锁问题,也是关于初始化死锁的,原因其实差不多,不过本文将这个问题描述的场景更加通用化了。

Demo

严格意义上说,这个Demo里提到的情况是其中一个简单的场景,和我们线上碰到的场景会有点出入,比这个会更复杂点。
image.png
为了让问题能重现,我选择了一个最简单的办法,就是debug,一般情况下,并发导致的问题,通过debug都可以模拟出来,并发无非就是控制代码执行的先后顺序,debug显然可以做到这一点

我们上面定义了A,B两个类,他们相互依赖,并且都有一个静态块,在静态块里相互调用对方的某个静态方法,我们的测试类ABTest就是用两个线程分别取调用两个类的静态方法,那我们在A和B两个类的静态块里调用对方静态方法之前设置一个断点,比如说都在System.out.println()那里设置断点,当两个线程都停到断点处的时候,我们再过掉两个断点,你会发现一个奇怪的现象,这个进程并没有退出,也就是那两个线程都没有执行完,你看到堆栈如下:
image.png
这里你看下Thread状态是RUNNABLE,但是又是卡在Object.wait()处的,这里确实只能说是JVM里的一个bug吧,状态不一致,我之前在InfoQ上发过一篇文章JVM Bug:多个线程持有一把锁,解释了这个状态不一致的问题。

Object.wait是哪里调的

从线程dump的线程栈来看完全看不出是调用了Object.wait,但是从线程输出来看确实有Object.wait,为了找出哪里调用了它,我们可以通过jstack -m <pid>来看,看到输出之后,你会觉得不可思议,确实有wait的逻辑
image.png
那这个逻辑从名字上来不难猜到是正在做类的初始化,那我们先来了解下类的初始化过程

类的初始化过程

当我们第一次主动调用某个类的静态方法就会触发这个类的初始化,当然还有其他的触发情况,类的初始化说白了就是在类加载起来之后,在某个合适的时机执行这个类的clinit方法,clinit方法是什么?比如我们在类里声明一段static代码块,或者有静态属性,javac会将这些代码都统一放到一个叫做clinit的方法里,在类初始化的时候来执行这个方法,但是JVM必须要保证这个方法只能被执行一次,如果有其他线程并发调用触发了这个类的多次初始化,那只能让一个线程真正执行clinit方法,其他线程都必须等待,当clinit方法执行完之后,然后再唤醒其他等待这里的线程继续操作,当然不会再让它们有机会再执行clinit方法,因为每个类都有一个状态,这个状态可以保证这一点
image.png
当有个线程正在执行这个类的clinit方法的时候,就会设置这个类的状态为being_initialized,当正常执行完之后就马上设置为fully_initialized,然后才唤醒其他也在等着对其做初始化的线程继续往下走,在继续走下去之前,会先判断这个类的状态,如果已经是fully_initialized了说明有线程已经执行完了clinit方法,因此不会再执行clinit方法了
image.png
当然如果执行clinit失败了,那我之前那篇不可逆的类初始化过程文章就着重讲了这种情况,可以去看看。
看到这里是否能解释了我们线上为什么会有那么多线程会卡在某一个地方了?因为这个类的状态是being_initialized,所以只能等啦

Demo现象解释

我们Demo里的那两个线程,从dump来看确实是死锁了,那这个场景当时是怎么发生的呢?线程1首先执行B.test(),于是会对B类做初始化,设置B的类状态为being_initialized,接着去执行B的clinit方法,但是在clinit方法里要去调用A.test方法,理论上此时会对A做初始化并调用其test方法,但是就在设置完B的类状态之后,执行其clinit里的A.test方法之前,线程2却执行了A.test方法,此时线程2会优先负责对A的初始化工作,即设置A类的状态为being_initialized,然后再去执行A的clinit方法,此时线程1发现A的类状态是being_initialized了,那线程1就认为有线程对A类正在做初始化,于是就等待了,而线程2同样发现B的类状态也是being_initialized,于是也开始等待,这样就形成了互等的情况,造成了类死锁的现象。

总结

类加载的死锁很隐蔽了,但是类初始化的死锁更隐蔽,所以大家要谨记在类的初始化代码里产生循环依赖,另外对于jdk8的defalut特性也要谨慎,因为这会直接触发接口的初始化导致更隐蔽的循环依赖

请先登录,感受更多精彩内容
快去登录吧,你将获得
  • 浏览更多精彩评论
  • 和开发者讨论交流,共同进步

为你推荐

类初始化导致死锁
一张图简单描述死锁 如上图,Thread1 拿到了 object1,Thread2 拿到了 object2,但是现在 Thread1 需要拿到 object2 的锁才能继续往下,Thread2 又要拿到 object1 才能继续往下
Java多线程——并发测试
编写并发程序时候,可以采取和串行程序相同的编程方式。唯一的难点在于,并发程序存在不确定性,这种不确定性会令程序出错的地方远比串行程序多,出现的方式也没有固定规则。那么如何在测试中,尽可能的暴露出这些问
Java多线程知识小抄集(一)
本文主要整理笔者遇到的Java多线程的相关知识点,适合速记,故命名为“小抄集”。本文没有特别重点,每一项针对一个多线程知识做一个概要性总结,也有一些会带一点例子,习题方便理解和记忆。 1.interr
今天,进程告诉我线程它它它它不想活了
上一篇文章我们解剖了进程和线程的本质,进程和线程的实现方式,这篇文章我们来探讨它们是如何通信的,进程告诉我说线程不想活了,我不管它死活,我只想知道我是谁?进程是怎么告诉我的?进程的出现和线程的死亡和我
实现线程的方式到底有几种?
这篇文章主要讲解实现线程的方式到底有几种?以及实现 Runnable 接口究竟比继承 Thread 类实现线程好在哪里?实现线程是并发编程中基础中的基础,因为我们必须要先实现多线程,才可以继续后续的一
记录一次Flink作业异常的排查过程
最近2周开始接手apache flink全链路监控数据的作业,包括指标统计,业务规则匹配等逻辑,计算结果实时写入elasticsearch. 昨天遇到生产环境有作业无法正常重启的问题,我负责对这个问题
通过生产者与消费者模型感受死锁
一. 实验目的及实验环境 1.实验目的通过观察、分析实验现象,深入理解产生死锁的原因,学会分析死锁的方法, 并利用 pstack、 gdb 或 core 文件分析( valgrind (DRD+Hel
Linux多线程应用性能分析
如今CPU的核心数越来越多, 在2019年你可以轻易买到超过50个核心的x86服务器CPU,一个中端台式机拥有8个执行线程也没什么好奇怪的。问题是我们怎样找到工作负载来“喂饱”那些相对饥饿的核。到目前
5
0