如何排查定位java中的死锁
一、服务死锁，Linux 遇难题
在当今数字化时代，微服务架构凭借其高可扩展性、灵活性和易于维护等优势，成为了众多企业构建大型应用系统的首选架构模式。当我们将微服务部署在 Linux 服务器上时，有时会遭遇令人头疼的死锁问题。死锁一旦发生，就如同给微服务的运行按下了 “暂停键”，会导致服务无法正常响应，严重影响系统的可用性和稳定性，进而对业务造成不良影响。
例如，在一个电商系统中，订单微服务和库存微服务可能会同时访问共享的数据库资源。如果订单微服务在处理订单时先获取了订单表的锁，然后试图获取库存表的锁来更新库存；而库存微服务在处理库存调整时先获取了库存表的锁，接着又试图获取订单表的锁来关联订单信息。当这两个操作并发执行时，就有可能出现死锁，导致订单无法创建，库存也无法更新，用户在下单时会一直等待，严重影响购物体验。
面对这样的困境，快速准确地排查和解决死锁问题显得尤为重要。而 JPS（Java Virtual Machine Process Status Tool）和 Jstack（Java Stack Trace）命令，就像是两把锋利的 “宝剑”，为我们在 Linux 环境下排查微服务死锁提供了有力的支持 。接下来，就让我们深入了解如何使用这两个命令来排查死锁问题。
二、死锁揭秘：原因与场景剖析
（一）死锁形成原因
-
系统资源不足：系统中的资源是有限的，当多个线程或进程竞争这些有限的资源时，如果资源的数量无法满足所有线程或进程的需求，就可能导致死锁。例如，在一个多线程的数据库应用中，多个线程同时请求数据库连接资源，如果数据库连接池中的连接数量有限，当所有连接都被占用时，新的线程请求连接就会被阻塞，若这些线程在等待连接的同时又持有其他资源不释放，就有可能引发死锁。
-
进程推进顺序不当：进程在运行过程中，请求和释放资源的顺序不合理，也会导致死锁的发生。比如线程 A 先获取了资源 X，然后尝试获取资源 Y；而线程 B 先获取了资源 Y，接着尝试获取资源 X。如果这两个线程并发执行，就会出现相互等待的情况，从而产生死锁。
-
资源分配不当：资源分配算法不合理或者资源分配过程中出现错误，也可能引发死锁。例如，在一个分布式系统中，不同节点上的进程对共享资源的分配没有进行有效的协调，导致某些进程获取了过多的资源，而其他进程却无法获取到必要的资源，进而引发死锁。
（二）死锁产生的必要条件
-
互斥条件：指资源在某一时刻只能被一个线程或进程所使用，其他线程或进程若要使用该资源，必须等待其被释放。例如，打印机在打印任务时，同一时间只能为一个进程服务，其他进程需要等待打印机完成当前任务后才能使用。
-
请求和保持条件：一个线程或进程在请求新资源的同时，会保持对已获得资源的占有。例如，线程 A 已经获取了资源 X，在请求资源 Y 时，它不会释放资源 X，若资源 Y 被其他线程占用，线程 A 就会处于阻塞状态，但依然持有资源 X。
-
不剥夺条件：线程或进程已获得的资源，在未使用完之前，不能被其他线程或进程强行剥夺，只能由持有该资源的线程或进程自行释放。比如，某个线程获得了一个文件的写锁，在它完成写操作并释放锁之前，其他线程无法强行获取该写锁。
-
环路等待条件：多个线程或进程之间形成一种头尾相接的循环等待资源关系。例如，线程 A 等待线程 B 释放资源 Y，线程 B 等待线程 C 释放资源 Z，而线程 C 又等待线程 A 释放资源 X，这样就形成了一个循环等待的环路，导致死锁。
（三）死锁出现的场景
-
多个线程彼此申请对方资源：这是最常见的死锁场景之一。假设有两个线程 T1 和 T2，T1 持有资源 R1，然后试图获取 T2 持有的资源 R2；同时，T2 持有资源 R2，并试图获取 T1 持有的资源 R1。由于双方都在等待对方释放自己所需的资源，从而陷入死锁。例如，在一个图形绘制程序中，线程 T1 负责绘制图形的轮廓，持有画笔资源 R1，在绘制填充颜色时需要获取颜料资源 R2；而线程 T2 负责填充颜色，持有颜料资源 R2，在绘制轮廓时需要获取画笔资源 R1，若它们同时执行，就可能出现死锁。
-
单个线程申请新资源时产生死锁：当一个线程已经持有一些资源，在申请新的资源时，如果新资源被其他线程占用，而该线程又不释放已持有的资源，就可能导致死锁。比如，一个线程在处理事务时，已经获取了数据库的部分锁，在需要获取更多锁来完成事务时，由于其他线程持有这些锁，该线程就会陷入等待，同时它又不释放已持有的锁，从而引发死锁。
三、工具登场：JPS 与 Jstack 介绍
（一）JPS 命令详解
JPS 命令是 Java Development Kit（JDK）提供的一个工具，主要用途是列出 JVM 进程（Java 虚拟机进程）的信息。在排查服务死锁问题时，它是我们获取目标 Java 进程 ID 的重要手段 。在开发和调试 Java 应用程序时，使用 JPS 命令可以显示正在运行的 Java 程序的进程 ID（PID）以及其他相关信息，如程序的完整类名，即 Java 主类类名。
JPS 命令的基本语法为：jps [ options ] [ hostid ] ，其中 option 参数用于指定不同的选项，hostid 参数用于指定要查询的远程主机。如果不指定任何选项，直接执行 jps 命令，它会列出当前系统中所有的 Java 进程 ID 以及对应的主类名。例如，在 Linux 系统中打开终端，进入到项目所在目录，执行 jps 命令，可能会得到如下输出：
12345 MainClass
12346 Jps
上述输出中，12345 是运行 MainClass 的 Java 进程 ID，12346 是当前执行 jps 命令的进程 ID。
常用的选项有：
-l：显示完整的包名和应用程序主类名。比如执行 jps -l ，输出可能为：
12345 com.example.demo.MainClass
12346 sun.tools.jps.Jps
这样我们就能更清晰地看到 Java 进程对应的完整类名。
-m：显示完整的包名、应用程序主类名和虚拟机的启动参数。执行 jps -m ，输出示例如下：
12345 com.example.demo.MainClass --param1 value1 --param2 value2
12346 sun.tools.jps.Jps -Dapplication.home=/usr/local/jdk1.8.0_291 -Xms8m
通过这个选项，我们可以了解 Java 进程启动时传入的参数。
-v：显示虚拟机的启动参数和 JVM 命令行选项。执行 jps -v ，输出可能是：
12345 com.example.demo.MainClass -Xmx512m -Xms256m -XX:MaxPermSize=256m
12346 sun.tools.jps.Jps -Dapplication.home=/usr/local/jdk1.8.0_291 -Xms8m
这有助于我们查看 Java 进程的 JVM 配置参数。
-q：只显示进程 ID，不显示类名和主类名。执行 jps -q ，输出结果类似：
12345
12346
这种方式在只需要获取进程 ID 时非常简洁高效。
（二）Jstack 命令详解
Jstack 是 Java 虚拟机自带的一种堆栈跟踪工具，它的主要用途是生成 Java 虚拟机当前时刻的线程快照。线程快照是当前 Java 虚拟机内每一条线程正在执行的方法堆栈的集合，通过分析这个快照，我们可以定位线程出现长时间停顿的原因，比如线程间死锁、死循环、请求外部资源导致的长时间等待等。在排查微服务死锁问题时，Jstack 命令起着关键作用，它能够帮助我们深入了解线程的运行状态和方法调用情况，从而找出死锁的根源。
Jstack 命令的基本语法为：jstack [ options ] pid ，其中 options 是可选参数，pid 是要分析的 Java 进程 ID。常用的选项有：
- -l：Long listing，会打印出额外的锁信息，在发生死锁时可以用 jstack -l pid 来观察锁持有情况。当我们怀疑微服务出现死锁时，使用这个选项可以获取更详细的锁相关信息，例如：
jstack -l 12345
执行上述命令后，输出结果中会包含每个线程持有的锁以及等待获取的锁的详细信息，这对于判断是否存在死锁以及死锁的具体情况非常有帮助。
- -m：mixed mode，不仅会输出 Java 堆栈信息，还会输出 C/C++ 堆栈信息（比如 Native 方法）。如果 Java 程序中调用了本地方法，使用这个选项可以查看本地方法的堆栈信息，有助于全面分析问题，命令示例如下：
jstack -m 12345
- -F：Force a stack dump when jstack [-l] pid does not respond。当正常的请求不被响应时，强制输出堆栈信息。在某些情况下，目标 Java 进程可能处于无响应状态，此时使用 -F 选项可以强制获取线程堆栈信息，例如：
jstack -F 12345
通过 Jstack 命令获取到的线程堆栈信息中，包含了丰富的内容，如线程的状态（RUNNABLE、BLOCKED、WAITING 等）、线程正在执行的方法、方法的调用栈以及锁的持有和等待情况等。这些信息对于我们排查死锁问题至关重要，能够帮助我们准确地定位到死锁发生的位置和原因。
四、实战演练：排查死锁步骤
（一）复现死锁：Java 代码示例
下面是一段导致死锁的 Java 代码示例，通过这段代码可以清晰地看到线程是如何竞争资源并最终导致死锁的。
public class DeadLockExample {
private static final Object lock1 = new Object();
private static final Object lock2 = new Object();
public static void main(String[] args) {
Thread thread1 = new Thread(() -> {
synchronized (lock1) {
System.out.println("Thread 1: Holding lock1");
try {
Thread.sleep(1000); // 让线程1持有lock1一段时间，确保线程2有机会获取lock2
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println("Thread 1: Waiting for lock2");
synchronized (lock2) {
System.out.println("Thread 1: Holding lock1 and lock2");
}
}
});
Thread thread2 = new Thread(() -> {
synchronized (lock2) {
System.out.println("Thread 2: Holding lock2");
try {
Thread.sleep(1000); // 让线程2持有lock2一段时间，确保线程1有机会获取lock1
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println("Thread 2: Waiting for lock1");
synchronized (lock1) {
System.out.println("Thread 2: Holding lock1 and lock2");
}
}
});
thread1.start();
thread2.start();
}
}
在这段代码中，thread1 首先获取了 lock1 ，然后睡眠 1 秒，这期间 thread2 有机会获取 lock2 。接着，thread1 试图获取 lock2 ，而 thread2 试图获取 lock1 ，由于双方都持有对方需要的资源且不释放，从而形成了死锁。
（二）使用 JPS 查找进程 ID
将上述 Java 代码打包成一个可执行的 JAR 文件，然后部署到 Linux 服务器上运行。在 Linux 终端中，使用 jps 命令来查找正在运行的 Java 进程 ID。假设我们将这个 JAR 文件命名为 deadlock-demo.jar ，运行命令如下：
java -jar deadlock-demo.jar
运行后，打开新的终端，执行 jps 命令：
jps
输出结果可能如下：
12345 DeadLockExample
12346 Jps
这里的 12345 就是运行 DeadLockExample 类的 Java 进程 ID，我们后续排查死锁就需要用到这个 ID。
（三）使用 Jstack 分析线程堆栈
得到 Java 进程 ID 后，使用 jstack 命令来分析线程堆栈信息，从而定位死锁。执行命令如下：
jstack -l 12345
其中，-l 选项表示输出额外的锁信息，这对于分析死锁非常有帮助。命令执行后，会输出大量的线程堆栈信息，我们重点关注与死锁相关的部分。以下是可能的输出结果（为了突出重点，进行了简化）：
Found one Java-level deadlock:
=============================
"Thread-1":
waiting to lock monitor 0x00007f85a8003ae8 (object 0x00000007d6aa2c98, a java.lang.Object),
which is held by "Thread-0"
"Thread-0":
waiting to lock monitor 0x00007f85a8006168 (object 0x00000007d6aa2ca8, a java.lang.Object),
which is held by "Thread-1"
Java stack information for the threads listed above:
===================================================
"Thread-1":
at DeadLockExample.lambda$main$1(DeadLockExample.java:22)
- waiting to lock <0x00000007d6aa2c98> (a java.lang.Object)
- locked <0x00000007d6aa2ca8> (a java.lang.Object)
at java.lang.Thread.run(Thread.java:748)
"Thread-0":
at DeadLockExample.lambda$main$0(DeadLockExample.java:12)
- waiting to lock <0x00000007d6aa2ca8> (a java.lang.Object)
- locked <0x00000007d6aa2c98> (a java.lang.Object)
at java.lang.Thread.run(Thread.java:748)
Found 1 deadlock.
从输出结果中可以看到，Thread-1 正在等待获取 Thread-0 持有的锁（0x00000007d6aa2c98 ），而 Thread-0 正在等待获取 Thread-1 持有的锁（0x00000007d6aa2ca8 ），这就形成了死锁。同时，还可以看到死锁发生的具体代码行，如 DeadLockExample.java:22 和 DeadLockExample.java:12 ，这为我们进一步排查和解决死锁问题提供了关键线索。
五、总结与展望
在本次死锁排查过程中，我们首先通过一个简单的 Java 代码示例复现了死锁问题，然后借助 JPS 命令快速准确地获取到了目标 Java 进程 ID，为后续的分析工作奠定了基础。接着，使用 Jstack 命令对线程堆栈进行分析，成功找到了死锁的关键信息，包括死锁的线程、持有的锁以及等待获取的锁等，从而清晰地定位到了死锁的根源。
死锁问题对系统的正常运行危害极大，它不仅会导致服务中断，影响用户体验，还可能造成资源的浪费和系统性能的下降。因此，在开发和部署服务时，避免死锁的发生至关重要。为了预防死锁，我们可以采取多种措施。在代码编写阶段，要确保所有线程以相同的顺序获取锁，避免嵌套锁的使用，减少锁的持有时间。在资源分配方面，合理规划资源的使用和分配，避免资源的过度竞争和不合理分配。同时，可以使用一些高级的同步工具，如 ReentrantLock、Semaphore 等，它们提供了更灵活的同步控制，有助于降低死锁发生的风险。此外，定期对系统进行性能测试和死锁检测，及时发现并解决潜在的死锁问题也是非常必要的。
随着架构的不断发展和应用场景的日益复杂，死锁问题可能会以更加隐蔽和复杂的形式出现。未来，我们需要不断探索和研究新的死锁检测和预防技术，结合人工智能、大数据分析等新兴技术，实现对死锁问题的智能预测和自动处理，进一步提升微服务系统的稳定性和可靠性。