这些java线程是否在等待它获得的锁？答案

【问题标题】：Are these java threads waiting on the lock it acquires?这些java线程是否在等待它获得的锁？
【发布时间】：2018-12-05 10:14:23
【问题描述】：

我正在查看 jstack 日志，这就是我所看到的：

"com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#2" #250 守护进程 prio=5 os_prio=0 tid=0x00007f9de0016000 nid=0x7e54 可运行 [0x00007f9d6495a000] java.lang.Thread.State：可运行在 com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread.run(ThreadPoolAsynchronousRunner.java:534) - 锁定 0x00000006fa818a38>（com.mchange.v2.async.ThreadPoolAsynchronousRunner）

"com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#1" #249 daemon prio=5 os_prio=0 tid=0x00007f9de000c000 nid=0x7e53 等待监控入口 [0x00007f9d649db000] java.lang.Thread.State: BLOCKED (在对象监视器上) 在 java.lang.Object.wait（本机方法） - 等待 0x00000006fa818a38>（com.mchange.v2.async.ThreadPoolAsynchronousRunner）在 com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread.run(ThreadPoolAsynchronousRunner.java:534) - 锁定 0x00000006fa818a38>（com.mchange.v2.async.ThreadPoolAsynchronousRunner）

"com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#0" #248 daemon prio=5 os_prio=0 tid=0x00007f9de001a000 nid=0x7e52 等待监控入口 [0x00007f9d64a5c000] java.lang.Thread.State: BLOCKED (在对象监视器上) 在 java.lang.Object.wait（本机方法） - 等待 0x00000006fa818a38>（com.mchange.v2.async.ThreadPoolAsynchronousRunner）在 com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread.run(ThreadPoolAsynchronousRunner.java:534) - 锁定 0x00000006fa818a38>（com.mchange.v2.async.ThreadPoolAsynchronousRunner）

因此，在此日志中，这三个线程中的每一个都设法获得了相同的锁，而底部的两个线程实际上被阻塞等待相同的锁。

谁能给我解释一下这个堆栈日志是什么意思？

【问题讨论】：

标签： java multithreading synchronization deadlock jstack

【解决方案1】：

最后两个线程正在等待通过使用 ThreadPoolAsynchronousRunner 的实例作为监视器得到通知，所以它的来源看起来像这样：

synchronized(asyncRunner) {
    // ...
    asyncRunner.wait();
    // ...
}

只要您调用wait，asyncRunner 上的同步就会“释放”，即应用程序的其他部分可以进入在该实例上同步的块。在您的特定情况下，这似乎已经发生并且第一个线程的wait-call 返回并且它当前正在处理来自它的一些数据。您仍然会在线程转储中看到多个 locked-行，以显示代码当前位于 synchronized-block 中，但如前所述，调用 wait 时会释放“锁定”。

您在此处看到的线程转储技术在将并发包添加到 JDK 之前非常普遍，以避免昂贵的线程创建。你的线程转储看起来像这种实现。这是一个简单的实现，它看起来像“幕后”：

// class ThreadPoolAsynchronousRunner
private Deque<AsyncMessage> queue;

public synchronized void addAsyncMessage(AsyncMessage msg) {
    queue.add(msg);
    notifyAll();
}

public void start() {
    for (int i = 0; i < 4; i++) {
        PoolThread pt = new PoolThread(this);
        pt.start();
    }
}

如果添加了要处理的新消息，ThreadPoolAsynchronousRunner`` 会启动 PoolThreads 并执行 notifyAll。

// PoolThread

public PoolThread(ThreadPoolAsynchronousRunner parent) {
    this.parent = parent;
}

public void run() {
    try {
        while (true) {
            AsyncMessage  msg = null;
            synchronized(parent) {
                parent.wait();
                if (!parent.queue.isEmpty()) {
                    msg = queue.removeFirst();
                }
            }
            if (msg != null) {
                processMsg(msg);
            }
        }
    }
    catch(InterruptedException ie) {
        // exit
    }
}

notifyAll 将导致所有线程的所有wait-methods 返回，因此您必须检查父队列中是否仍然包含数据（有时wait 即使没有发生通知也会返回，因此您需要即使不使用notifyAll，也会进行此检查）。如果是这种情况，您将启动处理方法。您应该在 synchronized-block 之外执行此操作，否则您的异步处理类一次只处理一条消息（除非这是您想要的 - 但是为什么要运行多个 PoolThread-instances？）

【讨论】：

【解决方案2】：

只有 Thread-#2 成功地获得了对象锁并且它处于 RUNNABLE 状态。其他 2 个线程，即 Thread-#0 和 Thread-#1 正在等待 Thread-#2 释放该锁。只要Thread-#2持有锁，Thread-#0和Thread-#1就会保持锁定状态已屏蔽。

如果您有权访问源代码，则可以查看该代码，以确保锁定和解锁是否按正确顺序完成，并且仅在需要的部分代码中保持锁定。请记住，这 2 个线程不是处于 WAIT 状态，而是处于 BLOCKED 状态，这是 WAIT 状态之后的一个步骤，只是进入 WAIT 状态之前的一个步骤strong>RUNNABLE 状态，一旦锁定可用。

在这个日志sn-p中没有观察到问题。这还不是死锁场景。

【讨论】：

【解决方案3】：

我能看到和理解的是

Thread-#2 处于 Runnable 状态并已获得对象锁定

“com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#2” java.lang.Thread.State: 可运行

Thread-#1 和 Thread-#0 正在等待对象锁被释放，因此现在被阻塞。

“com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#1” “com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#0” java.lang.Thread.State：BLOCKED（在对象监视器上）在 java.lang.Object.wait（本机方法） - 等待

【讨论】：