• 死锁仅在满足所有四个 Coffman 条件时发生：互斥、持有并等待、无抢占和循环等待。如果破坏其中任何一个，死锁就无法形成。
• synchronized 块和 ReentrantLock 都容易发生死锁——问题不在于语法，而在于获取锁的方式。
• 使用带超时的 tryLock() 是一种避免死锁的方法，尽管它会增加重试的额外逻辑——您需要根据生产需求来考虑这一点。
• jstack、JConsole、VisualVM 和 ThreadMXBean 等工具都能以各自的方式检测死锁。选择合适的工具可以在排查问题时节省时间。
• 死锁和活锁都会导致线程无法取得进展，但有一个关键区别：活锁线程持续运行并使用 CPU (RUNNABLE)，而死锁线程则在锁上等待 (BLOCKED)。
• 如果您在 JDK 21+ 中使用 virtual threads，请注意使用 synchronized 时可能出现的“pinning”。为避免问题，请在 virtual thread 内阻塞的任何代码中使用 ReentrantLock。

从外部看，死锁表现为一个健康的进程停止了所有活动：CPU 使用率降至接近零，没有新的日志输出出现，请求要么无限排队，要么开始超时。没有异常、没有错误消息，也没有来自 JVM 的信号。应用仍在运行；它只是没有取得进展。

死锁的最小设置需要两个线程和两个共享资源。线程 A 持有资源 1 并等待资源 2；线程 B 持有资源 2 并等待资源 1。在生产环境中，死锁通常涉及更多线程和更复杂的依赖图，这也是为什么它们在测试环境中难以重现的原因：锁获取的确切交错必须在正确时刻发生。

慢应用与死锁应用的不同在于，慢应用继续产生日志输出且 CPU 至少部分活跃。死锁应用不产生新的日志输出，CPU 保持平稳，且 jstack 在每次连续转储中显示相同的线程处于 BLOCKED 状态。这种组合——平稳 CPU、无日志进展和稳定的 BLOCKED 线程集——是区分死锁与普通缓慢的诊断信号。

要更广泛地了解 Java 如何管理对共享状态的并发访问，请参阅 thread safety in Java 教程。

只有当所有四个 Coffman 条件同时满足时，死锁才会发生。这对于预防死锁很重要：移除任何一个条件都会使该代码路径不可能发生死锁。

互斥

资源一次只能由一个线程持有。synchronized 块和 ReentrantLock 通过设计强制执行互斥并发。如果资源可以被多个线程并发访问而无需独占所有权，则此条件不成立，也就无法形成死锁。

持有并等待

一个线程在阻塞等待获取另一个锁时，至少持有一个锁。嵌套的 synchronized 块会直接创建此条件。在下面的三线程示例中，线程 t1 持有 obj1 的 monitor，同时等待 obj2 的 monitor。

不可抢占

JVM 无法强制从线程中移除锁。持有 monitor 的线程在退出 synchronized 块或调用 wait() 之前不会释放它。没有调度器机制可以代表等待线程回收已持有的锁。

循环等待

线程在等待关系中形成一个循环。线程 t1 等待由 t2 持有的锁，线程 t2 等待由 t3 持有的锁，而 t3 等待由 t1 持有的锁。这种资源分配循环使得情况永久化：循环中的任何线程都无法获取所需的锁，因为持有它的线程本身也在等待。

下表将每个 Coffman 条件映射到下一节三线程 synchronized 示例中的具体代码行：

使用 synchronized 的 Java 中最直接的死锁示例涉及嵌套锁和循环获取顺序。三个线程各自获取一个对象监视器，然后尝试获取第二个，形成循环等待条件。

package com.example.threads;

public class ThreadDeadlock {

    public static void main(String[] args) throws InterruptedException {
        Object obj1 = new Object();
        Object obj2 = new Object();
        Object obj3 = new Object();

        // t1 持有 obj1，想要 obj2
        // t2 持有 obj2，想要 obj3
        // t3 持有 obj3，想要 obj1  <-- 完成循环等待条件
        Thread t1 = new Thread(new SyncThread(obj1, obj2), "t1");
        Thread t2 = new Thread(new SyncThread(obj2, obj3), "t2");
        Thread t3 = new Thread(new SyncThread(obj3, obj1), "t3");

        t1.start();
        Thread.sleep(5000);
        t2.start();
        Thread.sleep(5000);
        t3.start();
    }
}

class SyncThread implements Runnable {
    private final Object obj1;
    private final Object obj2;

    public SyncThread(Object o1, Object o2) {
        this.obj1 = o1;
        this.obj2 = o2;
    }

    @Override
    public void run() {
        String name = Thread.currentThread().getName();
        System.out.println(name + " acquiring lock on " + obj1);
        synchronized (obj1) {               // 互斥；从这里开始持有并等待
            System.out.println(name + " acquired lock on " + obj1);
            work();
            System.out.println(name + " acquiring lock on " + obj2);
            synchronized (obj2) {           // 循环等待：每个线程的 obj2 都被下一个线程持有
                System.out.println(name + " acquired lock on " + obj2);
                work();
            }
            System.out.println(name + " released lock on " + obj2);
        }
        System.out.println(name + " released lock on " + obj1);
        System.out.println(name + " finished execution.");
    }

    private void work() {
        try {
            Thread.sleep(30000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}

// 预期输出（程序不会终止）：
t1 acquiring lock on java.lang.Object@6d9dd520
t1 acquired lock on java.lang.Object@6d9dd520
t2 acquiring lock on java.lang.Object@22aed3a5
t2 acquired lock on java.lang.Object@22aed3a5
t3 acquiring lock on java.lang.Object@218c2661
t3 acquired lock on java.lang.Object@218c2661
t1 acquiring lock on java.lang.Object@22aed3a5
t2 acquiring lock on java.lang.Object@218c2661
t3 acquiring lock on java.lang.Object@6d9dd520

三个线程各自获取第一个锁后，都尝试获取第二个锁。由于每个第二个锁都被另一个线程持有，所有线程都无限期阻塞。程序永远不会打印“finished execution.”。

读取线程转储

对阻塞进程运行 jstack <pid> 会生成线程转储。识别死锁的部分如下所示：

Found one Java-level deadlock:
=============================
"t3":
  waiting to lock monitor 0x00007fb0a1074b08 (object 0x000000013df2f658, a java.lang.Object),
  which is held by "t1"
"t1":
  waiting to lock monitor 0x00007fb0a1010f08 (object 0x000000013df2f668, a java.lang.Object),
  which is held by "t2"
"t2":
  waiting to lock monitor 0x00007fb0a1012360 (object 0x000000013df2f678, a java.lang.Object),
  which is held by "t3"

Found 1 deadlock.

关键字段是 waiting to lock 和 which is held by。每个条目都指明了阻塞的线程以及持有它所需锁的线程。沿着链条追踪会揭示循环：t1 等待 t2，t2 等待 t3，t3 等待 t1。循环中的每个线程在其状态行中都显示 BLOCKED (on object monitor)。

ReentrantLock 来自 java.util.concurrent.locks，它提供与 synchronized 相同的互斥保证，但需要显式调用 lock() 和 unlock()。显式调用使得锁获取顺序在代码中可见，这有助于审阅者发现不安全的顺序，但仅靠可见性并不能防止死锁。如果两个线程以相反顺序获取同一对锁，无论如何都会形成死锁。

当你需要定时锁尝试（tryLock）、可中断获取（lockInterruptibly）或多个条件队列（newCondition()）时，优先选择 ReentrantLock 而非 synchronized。对于简单的互斥，synchronized 更简洁，且忘记调用 unlock() 的风险更小。

使用 ReentrantLock 的死锁场景

import java.util.concurrent.locks.ReentrantLock;

public class ReentrantLockDeadlock {

    private static final ReentrantLock lockA = new ReentrantLock();
    private static final ReentrantLock lockB = new ReentrantLock();

    public static void main(String[] args) {
        Thread t1 = new Thread(() -> {
            lockA.lock();
            try {
                System.out.println(Thread.currentThread().getName() + " acquired lockA");
                sleep(100);
                lockB.lock();       // 在这里无限期阻塞：Thread-2 持有 lockB
                try {
                    System.out.println(Thread.currentThread().getName() + " acquired lockB");
                } finally {
                    lockB.unlock();
                }
            } finally {
                lockA.unlock();
            }
        }, "Thread-1");

        Thread t2 = new Thread(() -> {
            lockB.lock();
            try {
                System.out.println(Thread.currentThread().getName() + " acquired lockB");
                sleep(100);
                lockA.lock();       // 在这里无限期阻塞：Thread-1 持有 lockA
                try {
                    System.out.println(Thread.currentThread().getName() + "
如何在 Java 中检测死锁

检测死锁需要使用能够检查 JVM 运行时线程状态的工具，或者查询运行时线程管理 API 的代码。
jstack
jstack 是 JDK 中包含的命令行实用工具。它通过 PID 附加到运行中的 JVM 进程，并将完整的线程转储打印到 stdout。

jstack <pid>


// 预期输出（转储末尾的相关部分）：
Found one Java-level deadlock:
=============================
"t3":
  waiting to lock monitor 0x00007fb0...658 (a java.lang.Object),
  which is held by "t1"
...
Found 1 deadlock.

滚动到输出的末尾，查找 Found N Java-level deadlock 块。每个条目标识了被阻塞的线程、它正在等待的锁地址，以及当前持有该锁的线程。循环中的每个线程在其状态行显示 BLOCKED (on object monitor)。循环读取每个 which is held by 链可以揭示完整的循环等待。

jstack 可以检测 synchronized monitor 和扩展 AbstractOwnableSynchronizer 的 java.util.concurrent locks（包括 ReentrantLock）上的死锁。它不需要对应用程序进行代码更改。

JConsole
JConsole 是随 JDK 提供的图形化 JMX 监控工具。使用 JConsole 检测死锁的步骤：

在终端启动 JConsole：jconsole
从本地进程列表连接到运行中的 Java 进程。
打开 Threads 选项卡。
点击面板底部的 Detect Deadlock 按钮。


Name: Thread-1
State: BLOCKED
Blocked on: java.lang.Object@6d9dd520 (owned by Thread-2)

Name: Thread-2
State: BLOCKED
Blocked on: java.lang.Object@22aed3a5 (owned by Thread-1)

Deadlock detected.

这个面板直接映射到 jstack 转储中的 waiting to lock 和 which is held by 字段，因此两种工具通过不同的界面产生等效的诊断信息。
如果存在死锁，JConsole 会将相关线程高亮为红色，并显示每个线程的堆栈跟踪，以及它正在等待的锁和持有该锁的线程名称。该报告等同于 jstack 的死锁部分，但以可视化列表形式呈现，这在需要快速在多个被阻塞线程之间导航而无需解析原始文本时非常有用。
VisualVM
VisualVM 提供线程时间线，可以一目了然地显示死锁模式。连接到进程后：

打开 Threads 选项卡。
查找显示为红色的线程（阻塞状态）。在三线程死锁中，三个红色条同时出现并保持红色，没有向前移动。
点击任何被阻塞的线程查看其堆栈跟踪和它正在等待的锁。
VisualVM 还在线程视图中显示 Deadlock detected! 通知横幅，当它自动识别循环时。


Thread-1  [BLOCKED]  waiting for lock held by Thread-2
Thread-2  [BLOCKED]  waiting for lock held by Thread-1

Deadlock detected!

VisualVM 的线程时间线显示线程进入 BLOCKED 状态的时刻，这有助于识别死锁是持久的还是间歇性的。
线程时间线特别适用于区分死锁（线程永久红色）和临时锁争用（线程短暂红色然后恢复绿色）。
ThreadMXBean：程序化检测
来自 java.lang.management 的 ThreadMXBean 允许您从运行中的应用程序内部检测死锁。这对于监控端点、后台看门狗线程或长时间运行服务中的自动化健康检查非常有用。

import java.lang.management.ManagementFactory;
import java.lang.management.ThreadInfo;
import java.lang.management.ThreadMXBean;

public class DeadlockDetector {

    public static void main(String[] args) throws InterruptedException {
        Object lockA = new Object();
        Object lockB = new Object();

        Thread t1 = new Thread(() -> {
            synchronized (lockA) {
                System.out.println("Thread-1 acquired lockA");
                sleep(100);
                synchronized (lockB) {
                    System.out.println("Thread-1
如何在 Java 中防止死锁

预防策略通过使至少一个 Coffman 条件无法满足来实现。以下每种策略针对特定条件，并解释其工作原理。
避免嵌套锁
同时获取多个锁会产生持有并等待条件。消除嵌套锁获取可以完全移除该代码路径的死锁风险。
下面重构后的 run() 方法在获取 obj2 之前释放 obj1，因此没有线程会同时持有两者：

public void run() {
    String name = Thread.currentThread().getName();
    System.out.println(name + " acquiring lock on " + obj1);
    synchronized (obj1) {
        System.out.println(name + " acquired lock on " + obj1);
        work();
    }
    System.out.println(name + " released lock on " + obj1);
    System.out.println(name + " acquiring lock on " + obj2);
    synchronized (obj2) {
        System.out.println(name + "
Deadlock 与 Livelock：关键区别

livelock 与 deadlock 的关键区别在于线程状态：在 livelock 中，线程处于 RUNNABLE 状态并消耗 CPU；在 deadlock 中，线程处于 BLOCKED 状态且不消耗 CPU。在 livelock 中，线程处于活跃执行状态，并对彼此的状态变化做出响应。它们不断根据对方线程的行为改变自身状态，但这些反应相互抵消，导致没有工作完成。线程并未阻塞；它们忙于无所事事。
下面的示例使用两个 Worker 对象，每个对象都有一个 active 标志。当一个 worker 检测到另一个处于活跃状态时，它会将自己的标志设置为非活跃，短暂等待，然后重新设置为活跃并重试。由于两个 worker 完全镜像此行为并同时重新激活，双方均无法取得进展。示例中设置了 6 次迭代上限，以便程序终止并观察到该模式；若无此上限，循环将永不退出。

public class LivelockExample {

    static class Worker {
        private volatile boolean active = true;
        private final String name;

        Worker(String name) { this.name = name; }

        void work(Worker other) {
            int count = 0;
            // 没有这个上限，循环将永不退出：每次这个 worker 让步时，
            // 另一个已经重新激活并再次阻塞进展。
            while (count < 6) {
                if (other.active) {
                    System.out.println(name + ": other worker is active, stepping aside");
                    this.active = false;
                    sleep(50);
                    this.active = true;
                    count++;
                } else {
                    System.out.println(name + ": path is clear, proceeding");
                    return;
                }
            }
            System.out.println(name + ": gave up after " + count + " attempts");
        }
    }

    public static void main(String[] args) throws InterruptedException {
        Worker w1 = new Worker("Worker-1");
        Worker w2 = new Worker("Worker-2");

        Thread t1 = new Thread(() -> w1.work(w2), "t1");
        Thread t2 = new Thread(() -> w2.work(w1), "t2");

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

    static void sleep(long ms) {
        try { Thread.sleep(ms); } catch (InterruptedException e) { Thread.currentThread().interrupt(); }
    }
}


// 预期输出（livelock：线程不断相互让步；
// 顺序因调度器而异）：
Worker-1: other worker is active, stepping aside
Worker-2: other worker is active, stepping aside
Worker-1: other worker is active, stepping aside
Worker-2: other worker is active, stepping aside
Worker-1: other worker is active, stepping aside
Worker-2: other worker is active, stepping aside
...
Worker-1: gave up after 6 attempts
Worker-2: gave up after 6 attempts

与 deadlock 不同，在整个 livelock 过程中，两个线程均处于 RUNNABLE 状态并持续消耗 CPU；没有线程处于 BLOCKED 状态等待 monitor。




Deadlock
Livelock




定义
线程永久阻塞，每个线程等待另一个线程持有的锁
线程活跃运行但无进展；每个线程对对方的状态做出反应


线程状态
BLOCKED
RUNNABLE


CPU 使用率
接近零（线程未执行）
高（线程持续执行但无有效工作）


检测方法
jstack, JConsole, VisualVM, ThreadMXBean.findDeadlockedThreads()
无 JVM 级检测器；需通过性能分析或手动分析线程活动


解决策略
打破四个 Coffman 条件之一
添加随机性或指数退避以打破同步响应模式