本文来自: PerfMa技术社区

PerfMa(笨马网络)官网

概述

之前写过关于类加载死锁的文章，消失的死锁，说的是类加载过程中发生的死锁，我们从线程dump里完全看不出死锁的迹象，但是确实发生了死锁，没了解的建议看看我前面的那篇文章

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

我们线上的现象是发现非常多的线程都卡死在同一个地方，也不是在做类加载，如果是死循环，那cpu肯定上去了，但是cpu并没有上去，因此比较诡异

PS：有人经常给我公众号发消息咨询问题，可消息最多只能保存最近5天的，而且只能回复最近2天的，有时候忘记回了想起要回的时候就不能再回复了，如果比较紧急，问题可以发到我邮箱里，我会抽时间看这些问题并回答，不过无法保证所有的问题都会回答，因为问的人确实有点多，精力也有限。。。

Demo

严格意义上说，这个Demo里提到的情况是其中一个简单的场景，和我们线上碰到的场景会有点出入，比这个会更复杂点，我后面也会提到那个场景

为了让问题能重现，我选择了一个最简单的办法，就是debug，一般情况下，并发导致的问题，通过debug都可以模拟出来，并发无非就是控制代码执行的先后顺序，debug显然可以做到这一点

我们上面定义了A，B两个类，他们相互依赖，并且都有一个静态块，在静态块里相互调用对方的某个静态方法，我们的测试类ABTest就是用两个线程分别取调用两个类的静态方法，那我们在A和B两个类的静态块里调用对方静态方法之前设置一个断点，比如说都在System.out.println()那里设置断点，当两个线程都停到断点处的时候，我们再过掉两个断点，你会发现一个奇怪的现象，这个进程并没有退出，也就是那两个线程都没有执行完，你看到堆栈如下：

这里你看下Thread状态是RUNNABLE，但是又是卡在Object.wait()处的，这里确实只能说是JVM里的一个bug吧，状态不一致。

Object.wait是哪里调的

从线程dump的线程栈来看完全看不出是调用了Object.wait，但是从线程输出来看确实有Object.wait，为了找出哪里调用了它，我们可以通过jstack -m <pid>来看，看到输出之后，你会觉得不可思议，确实有wait的逻辑

那这个逻辑从名字上来不难猜到是正在做类的初始化，那我们先来了解下类的初始化过程

类的初始化过程

当我们第一次主动调用某个类的静态方法就会触发这个类的初始化，当然还有其他的触发情况，类的初始化说白了就是在类加载起来之后，在某个合适的时机执行这个类的clinit方法，clinit方法是什么？比如我们在类里声明一段static代码块，或者有静态属性，javac会将这些代码都统一放到一个叫做clinit的方法里，在类初始化的时候来执行这个方法，但是JVM必须要保证这个方法只能被执行一次，如果有其他线程并发调用触发了这个类的多次初始化，那只能让一个线程真正执行clinit方法，其他线程都必须等待，当clinit方法执行完之后，然后再唤醒其他等待这里的线程继续操作，当然不会再让它们有机会再执行clinit方法，因为每个类都有一个状态，这个状态可以保证这一点。

当有个线程正在执行这个类的clinit方法的时候，就会设置这个类的状态为being_initialized，当正常执行完之后就马上设置为fully_initialized，然后才唤醒其他也在等着对其做初始化的线程继续往下走，在继续走下去之前，会先判断这个类的状态，如果已经是fully_initialized了说明有线程已经执行完了clinit方法，因此不会再执行clinit方法了。

当然如果执行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，于是也开始等待，这样就形成了互等的情况，造成了类死锁的现象。

更隐蔽的初始化死锁现象

这里提到的场景其实是我们线上的场景，这个情况不是很好模拟，比较难控制，当然debug jvm还是可以的

上述代码不一定能重现，不过我可以跟大家解释下可能死锁的情况，代码里我们主要定义了

• Iterator接口：这个接口里有个static属性，static方法，还有个default方法，这意味着这个Iterator接口有个clinit方法，里面主要是对这个static属性赋值

• AbstractIterator抽象类：没啥东西，就是实现Iterator接口罢了

• Test测试类：起了两个线程，分别new了一个AbstractIterator匿名子类实例以及调用Iterator的静态方法

ok，到此我要描述一个特殊的场景了，线程1执行会创建一个AbstractIterator匿名子类实例，此时会触发AbstractIterator的初始化，同时因为其实现了Iterator接口，而Iterator接口含有defalut方法，因此这个类会被标记是一个含有default方法的类，于是在设置完AbstractIterator的类状态为being_initialized之后，会递归遍历其父接口，如果某个接口有default方法，比如Iterator，那就先触发Iterator类的初始化动作，但是在触发这个动作之前，线程2执行Iterator.empty静态方法了，于是会触发对Iterator类的初始化动作，于是设置Iterator的类状态为being_initialized，然后开始执行其clinit方法，而在clinit方法里有创建AbstractIterator匿名子类的实例，于是就会想触发AbstractIterator的初始化，但是AbstractIterator已经被线程1设置为being_initialized了，于是就只能等了，同理，线程1因为要等Iterator的初始化完成而必须等待了，从而互锁现象再次形成

相比我们最早Demo里的场景最大的不同是我们看线程栈，只能看到一个线程在执行clinit方法，另外一个线程并还没有在支持clinit方法，因此这个线程卡在了初始化其父接口初始化的路上了，还没拿到执行clinit的机会。

总结

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

一起来学习吧：

PerfMa KO 系列课之 JVM 参数【Memory篇】

一次线上服务高 CPU 占用优化实践