Java死锁原理、复现与检测：从JConsole到命令行工具

死锁的形成原理

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

其核心产生场景通常包含以下循环依赖：
当线程A持有对象A的锁，并试图获取对象B的锁；同时线程B持有对象B的锁，并试图获取对象A的锁。此时双方都持有对方需要的资源且都不释放，从而形成死锁。

第1步：编写导致死锁的示例代码

为了直观理解，我们可以通过嵌套 synchronized 块来构建一个标准的死锁模型。下面代码中，线程t2先获取objectA锁再尝试获取objectB锁，而线程t1则相反，这种顺序不一致极易引发死锁。

@Slf4j
public class ThreadTest {
    private static Object objectA = new Object();
    private static Object objectB = new Object();

    public static void main(String[] args) throws InterruptedException {
        // 线程t2的顺序：先A后B
        Thread t2 = new Thread(()->{
            synchronized (objectA){
                log.debug("线程t2获取到了objectA");
                try { Thread.sleep(100); } catch (InterruptedException e) {}
                synchronized (objectB){
                    log.debug("线程t2获取到了objectB");
                }
            }
        },"t2");

        // 线程t1的顺序：先B后A
        Thread t1 = new Thread(()->{
            synchronized (objectB){
                log.debug("线程t1获取到了objectB");
                try { Thread.sleep(100); } catch (InterruptedException e) {}
                synchronized (objectA){
                    log.debug("线程t1获取到了objectA");
                }
            }
        },"t1");

        t2.start();
        t1.start();
    }
}

注意：在实际运行中，可能需要加入适当的 Thread.sleep 来增加线程切换时进入关键区的概率，以确保能稳定复现死锁现象。

JConsole图形化检测死锁

JDK自带了JConsole可视化工具，能够实时监控JVM性能并自动检测死锁。这是最直观的检测方式之一。

第2步：启动JConsole并连接进程

在Windows系统中，可以通过搜索“jconsole”直接启动该程序。启动后会列出本地运行的所有Java进程。

选择当前正在运行的Java项目名称，点击“连接”。如果系统提示安全警告，选择“不安全连接”即可进入监控界面。

第3步：查看线程状态

在左侧菜单栏点击“线程”，右侧将显示当前进程中所有线程的详细信息。你可以观察到线程的状态（如RUNNABLE、BLOCKED、WAITING等）。

第4步：执行死锁检测

在“线程”界面的顶部工具栏中，找到并点击“检测死锁”按钮。JConsole会自动分析当前线程的锁依赖关系。

第5步：分析检测结果

如果检测到死锁，下方会出现红色警示区域，详细列出参与死锁的线程ID、所在类以及锁的具体信息。这能帮助你快速定位是哪段代码导致了阻塞。

jstack命令行检测死锁

对于服务器环境或缺乏图形界面的Linux系统，可以使用JDK提供的 jstack 工具在线程运行时捕获堆栈快照进行分析。

第6步：获取Java进程PID

打开IDEA控制台Terminal或使用系统终端，输入 jps 命令查看当前所有的Java进程ID。找到你的主类名称对应的进程ID。

第7步：导出线程堆栈信息

输入命令 jstack <进程号>。该命令会输出该进程下所有线程的详细堆栈信息。由于输出内容较多，建议结合管道符过滤或直接保存文件：

jstack <pid> > thread_dump.txt

在输出的末尾部分，寻找类似于 Possible deadlock detected 的提示。如果没有明确提示，可以向下滚动查找包含 BLOCKED 状态的线程，观察它们的 locked <地址> 是否形成了闭环等待。

经典案例：哲学家就餐问题

哲学家就餐问题是操作系统和资源管理中的经典死锁模型。假设五位哲学家围坐在圆桌旁，每两人之间放有一根筷子。哲学家需要同时拿起左手和右手的两根筷子才能吃饭。

第8步：模拟死锁场景

在所有哲学家的逻辑完全对称的情况下（例如大家都先拿左边的筷子），会导致每个人都持有一根筷子并等待下一根，从而形成死锁。

以下是简化为四人的代码实现。注意这里Philosopher类的 run 方法中，同步块的嵌套顺序一致（先right后left），但若初始化时传入的左右筷子引用使得最终加锁顺序形成环路，依然会死锁。

@Slf4j
class Philosopher extends Thread{
    private String name;
    private Chopsticks left;
    private Chopsticks right;

    public Philosopher(String name, Chopsticks left, Chopsticks right) {
        super(name);
        this.name = name;
        this.left = left;
        this.right = right;
    }

    @Override
    public void run() {
        while(true){
            // 注意加锁顺序的一致性可能导致死锁
            synchronized (right){
                synchronized (left){
                    eat(name);
                }
            }
        }
    }

    private void eat(String name){
        log.debug(name + "正在吃饭");
    }
}

配合四个Chopsticks对象的交替分配，如代码所示的李云龙、赵刚等四人逻辑，测试结果显示程序确实陷入了线程死锁，所有哲学家都在等待对方放下筷子。

总结

避免死锁的最佳策略是规范锁的申请顺序，确保所有线程按相同的顺序获取资源，或者使用带超时的锁尝试机制（如 ReentrantLock.tryLock）。当生产环境出现线程挂起时，熟练掌握JConsole和jstack工具是排查此类问题的关键技能。以上就是Java多线程死锁详解的详细内容，更多关于Java并发编程检测方法的资料请关注本站其它相关文章！