本文来自 PerfMa社区，欢迎关注公众号
一张图简单描述死锁
如上图，Thread1 拿到了 object1，Thread2 拿到了 object2，但是现在 Thread1 需要拿到 object2 的锁才能继续往下，Thread2 又要拿到 object1 才能继续往下，于是哪个线程都无法得到满足继续往下来释放对方所需要的锁对象，从而造成了死锁。
概述
之前写过关于类加载死锁的文章“消失的死锁”，说的是类加载过程中发生的死锁，我们从线程dump里完全看不出死锁的迹象，但是确实发生了死锁，没了解的建议看看我公众号上相关的文章。
本文要说的是另外一个问题，之前在生产环境上碰到，是类初始化导致的死锁，恩，你没看错，确实是类初始化导致的死锁，我之前写过一篇文章，不可逆的类初始化过程，这篇文章可以助你了解类的初始化过程，另外也写过一篇JDK的sql设计不合理导致的驱动类初始化死锁问题，也是关于初始化死锁的，原因其实差不多，不过本文将这个问题描述的场景更加通用化了。
Demo
严格意义上说，这个Demo里提到的情况是其中一个简单的场景，和我们线上碰到的场景会有点出入，比这个会更复杂点。
为了让问题能重现，我选择了一个最简单的办法，就是debug，一般情况下，并发导致的问题，通过debug都可以模拟出来，并发无非就是控制代码执行的先后顺序，debug显然可以做到这一点
我们上面定义了A，B两个类，他们相互依赖，并且都有一个静态块，在静态块里相互调用对方的某个静态方法，我们的测试类ABTest就是用两个线程分别取调用两个类的静态方法，那我们在A和B两个类的静态块里调用对方静态方法之前设置一个断点，比如说都在System.out.println()那里设置断点，当两个线程都停到断点处的时候，我们再过掉两个断点，你会发现一个奇怪的现象，这个进程并没有退出，也就是那两个线程都没有执行完，你看到堆栈如下：
这里你看下Thread状态是RUNNABLE，但是又是卡在Object.wait()处的，这里确实只能说是JVM里的一个bug吧，状态不一致，我之前在InfoQ上发过一篇文章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，于是也开始等待，这样就形成了互等的情况，造成了类死锁的现象。
总结
类加载的死锁很隐蔽了，但是类初始化的死锁更隐蔽，所以大家要谨记在类的初始化代码里产生循环依赖，另外对于jdk8的defalut特性也要谨慎，因为这会直接触发接口的初始化导致更隐蔽的循环依赖
推荐阅读
FGC实战：如何用Idea揪出开源组件调用System.gc导致频繁FGC
来源：oschina
链接：https://my.oschina.net/PerfMa/blog/3212399