如何诊断或检测Java静态初始化程序中的死锁 [英] How to diagnose or detect deadlocks in Java static initializers

问题描述

（在Java中使用静态初始化器是否是一个好主意超出了这个问题的范围。）

(Whether using static initializers in Java is a good idea is out of scope for this question.)

我在Scala应用程序中遇到死锁，我认为是由编译类中的互锁静态初始化器引起的。

I am encountering deadlocks in my Scala application, which I think are caused by interlocking static initializers in the compiled classes.

我的问题是如何检测和诊断这些死锁 - 我发现死锁的普通JVM工具没有在涉及静态初始化程序块时似乎工作。

My question is how to detect and diagnose these deadlocks -- I have found that the normal JVM tools for deadlocks do not seem to work when static initializer blocks are involved.

这是一个简单的示例Java应用程序，它在静态初始化程序中死锁：

Here is a simple example Java app which deadlocks in a static initializer:

public class StaticDeadlockExample implements Runnable
{
    static
    {
        Thread thread = new Thread(
                new StaticDeadlockExample(),
                "StaticDeadlockExample child thread");
        thread.start();
        try {
            thread.join();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }

    public static void main(String[] args)
    {
        System.out.println("in main");
    }

    public static void sayHello()
    {
        System.out.println("hello from thread " + Thread.currentThread().getName());
    }

    @Override
    public void run() {
        StaticDeadlockExample.sayHello();
    }
}

如果启动此应用程序，它会死锁。死锁时的堆栈跟踪（来自 jstack ）包含以下两个死锁线程：

If you launch this app, it deadlocks. The stack trace at time of deadlock (from jstack) contains the following two deadlocked threads:

"StaticDeadlockExample child thread" prio=6 tid=0x000000006c86a000 nid=0x4f54 in Object.wait() [0x000000006d38f000]
   java.lang.Thread.State: RUNNABLE
    at StaticDeadlockExample.run(StaticDeadlockExample.java:37)
    at java.lang.Thread.run(Thread.java:619)

   Locked ownable synchronizers:
    - None

"main" prio=6 tid=0x00000000005db000 nid=0x2fbc in Object.wait() [0x000000000254e000]
   java.lang.Thread.State: WAITING (on object monitor)
    at java.lang.Object.wait(Native Method)
    - waiting on <0x000000004a6a7870> (a java.lang.Thread)
    at java.lang.Thread.join(Thread.java:1143)
    - locked <0x000000004a6a7870> (a java.lang.Thread)
    at java.lang.Thread.join(Thread.java:1196)
    at StaticDeadlockExample.<clinit>(StaticDeadlockExample.java:17)
    at java.lang.Class.forName0(Native Method)
    at java.lang.Class.forName(Class.java:169)
    at com.intellij.rt.execution.application.AppMain.main(AppMain.java:116)

   Locked ownable synchronizers:
    - None

我的问题如下：

1. 为什么第一个线程标记为RUNNABLE，当它实际上在等待锁定时？我可以以某种方式检测到该线程的真实状态吗？


2. 为什么两个线程都没有被标记为拥有任何（相关）锁，实际上一个持有静态的初始化锁，另一个是等待吗？我可以以某种方式检测静态初始化程序锁定所有权吗？

推荐答案

我试过这个例子用< a href =http://jada.cs.unibo.it/demo.html =nofollow noreferrer>我的工具，它也无法将此检测为死锁。在与jconsole调试器稍作挣扎并重新运行该示例几次后，我注意到初始线程被标记为RUNNABLE因为它是可运行的，这里的问题是由于启动的线程访问静态成员，此操作在静态初始化程序块完成后排队（此语义在 JVM规范，但似乎是这种情况。）

I have tried this example with my tool and it also fails in detecting this as a deadlock. After struggling a bit with the jconsole debugger and re-running the example a couple of times I noticed that the initial thread is marked as RUNNABLE because it is runnable, the problem here is that since the launched thread access to a static member, this operation is queued after the finishing of the static initializer block (this semantic is not clear in the JVM specification, however it seems to be the case).

静态初始化程序没有完成，因为在这个奇怪的例子中是一个连接操作强制它等待线程终止，但是我注意到这个排队操作没有根据JVM规范明确地或隐式地获取锁。也许这不应该被视为死锁本身，因为如果run方法的主体包含无限循环，情况也是如此。

The static initializer does not finish because in this bizarre example a join operation forces it to wait for the thread termination, however I remark that this "queued" operation does not grab a lock explicitly nor implicitly according to the JVM specification. Perhaps this shouldn't be considered a deadlock per se as it would be the same case if the body of the run method contains an infinite loop.

这篇关于如何诊断或检测Java静态初始化程序中的死锁的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！