没有堆栈的Java "Thread-2“阻止终止

Question

我有一个非常复杂的java程序，它不会终止。eclipse调试器显示的线程可以挂起，但没有堆栈跟踪。它被称为“线程-2”。

这个线程的jstack -l输出是：

"Thread-2" #17 prio=5 os_prio=0 tid=0x00007f1268002800 nid=0x3342 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

   Locked ownable synchronizers:
    - None

我向Thread.start()添加了一个断点，但找不到一个名为"Thread-2“的线程。在创建了两个“AWT-事件队列”线程之后，线程就出现了。我不会在我的程序中手动创建任何线程。

在主线程和所有其他线程退出并释放JFrame之后，仍然存在以下线程：

Thread [AWT-EventQueue-0] (Running) 
Thread [Thread-2] (Running) 
Thread [DestroyJavaVM] (Running)    

挂起VM时，存在以下线程：

Daemon System Thread [Signal Dispatcher] (Suspended)    
Daemon System Thread [Finalizer] (Suspended)    
Daemon System Thread [Reference Handler] (Suspended)    
Daemon System Thread [Java2D Disposer] (Suspended)  
Daemon System Thread [AWT-XAWT] (Suspended) 
Thread [AWT-EventQueue-0] (Suspended)   
Thread [Thread-2] (Suspended)   
Thread [DestroyJavaVM] (Suspended)  

如何获得有关此线程的更多信息，或允许其终止？

编辑1:

根据eclipse视图的Dependency Hierarchy，我使用以下第三方库：

guava 17.0 [compile]
hamcrest-core 1.3 [test]
junit 4.11 [test]
log4j-api 2.0-beta9 [compile]
log4j-core 2.0-beta9 [compile]

编辑2:

按照https://stackoverflow.com/a/35128213/577485中的建议，向线程类的所有构造函数添加断点，我看到Thread-0和Thread-1是由log4j创建的，而不是Thread-2创建的。它仍然像以前一样出现，在构造它时没有触发断点。

编辑3:

现在越来越恐怖了。在线程上调用时，甚至连stop()方法都无法工作。我将它添加到https://stackoverflow.com/a/35128149/577485中给出的代码中。至少System.exit(int)还能工作。但正如在评论中所说的，我不想用这句话。

编辑4:

有关我系统的信息：

• 我正在运行Ubuntu15.10WILY的最新稳定版本。我启用了security、updates和backports repos。
• 我的JVM版本是：

java version "1.7.0_91" OpenJDK Runtime Environment (IcedTea 2.6.3) (7u91-2.6.3-0ubuntu0.15.10.1) OpenJDK 64-Bit Server VM (build 24.91-b01, mixed mode)

编辑5:

我用直接从jre-8u71-linux-x64下载的java.com java.com执行程序，但是错误仍然存在。jstack -l显示了相同的奇怪线程。请注意，该程序仍然是用较旧的java版本构建的。编辑:在用java8u72从oracle.com编译它之后，我得到了相同的行为。

编辑6:

我迭代了所有的线程字段，这是输出。我无法从这些字段中得到任何提示，线程甚至没有目标。

name: [C@6b67034
priority: 5
threadQ: null
eetop: 140274638530560
single_step: false
daemon: false
stillborn: false
target: null
group: java.lang.ThreadGroup[name=main,maxpri=10]
contextClassLoader: null
inheritedAccessControlContext: java.security.AccessControlContext@0
threadInitNumber: 3
threadLocals: null
inheritableThreadLocals: null
stackSize: 0
nativeParkEventPointer: 0
tid: 17
threadSeqNumber: 20
threadStatus: 5
parkBlocker: null
blocker: null
blockerLock: java.lang.Object@16267862
MIN_PRIORITY: 1
NORM_PRIORITY: 5
MAX_PRIORITY: 10
EMPTY_STACK_TRACE: [Ljava.lang.StackTraceElement;@453da22c
SUBCLASS_IMPLEMENTATION_PERMISSION: ("java.lang.RuntimePermission" "enableContextClassLoaderOverride")
uncaughtExceptionHandler: null
defaultUncaughtExceptionHandler: null
threadLocalRandomSeed: 0
threadLocalRandomProbe: 0
threadLocalRandomSecondarySeed: 0

编辑7:

向name字段Thread添加了一个观察点。它只被我的分析代码访问，而且似乎从来没有写过.

编辑8:

jstack -F -m为我的程序抛出一个错误：

Attaching to process ID 10973, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 25.71-b15
Exception in thread "main" java.lang.reflect.InvocationTargetException
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:497)
    at sun.tools.jstack.JStack.runJStackTool(JStack.java:140)
    at sun.tools.jstack.JStack.main(JStack.java:106)
Caused by: java.lang.RuntimeException: Unable to deduce type of thread from address 0x00007ff68000c000 (expected type JavaThread, CompilerThread, ServiceThread, JvmtiAgentThread, or SurrogateLockerThread)
    at sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:169)
    at sun.jvm.hotspot.runtime.Threads.first(Threads.java:153)
    at sun.jvm.hotspot.tools.PStack.initJFrameCache(PStack.java:200)
    at sun.jvm.hotspot.tools.PStack.run(PStack.java:71)
    at sun.jvm.hotspot.tools.PStack.run(PStack.java:58)
    at sun.jvm.hotspot.tools.PStack.run(PStack.java:53)
    at sun.jvm.hotspot.tools.JStack.run(JStack.java:66)
    at sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:260)
    at sun.jvm.hotspot.tools.Tool.start(Tool.java:223)
    at sun.jvm.hotspot.tools.Tool.execute(Tool.java:118)
    at sun.jvm.hotspot.tools.JStack.main(JStack.java:92)
    ... 6 more
Caused by: sun.jvm.hotspot.types.WrongTypeException: No suitable match    for type of address 0x00007ff68000c000
    at sun.jvm.hotspot.runtime.InstanceConstructor.newWrongTypeException(InstanceConstructor.java:62)
    at sun.jvm.hotspot.runtime.VirtualConstructor.instantiateWrapperFor(VirtualConstructor.java:80)
    at sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:165)
    ... 16 more

奇怪线程的类名是java.lang.Thread。

我不使用任何命令行参数来执行程序。添加-Dlog4j2.disable.jmx=true选项会给奇怪的线程命名Thread-1。

我将log4j更新为2.5，当给出-Dlog4j2.disable.jmx=true选项时，奇怪的线程现在有了名称Thread-0，而给出了-Dlog4j2.disable.jmx=true选项时的名称是Thread-1。

编辑9:

完全删除log4j，错误将持续存在。这个线程现在被称为Thread-0。

如果这有帮助的话，这里就是这个项目。

Answer 1

我不明白为什么Thread.start()上的断点不能工作，但您也可以尝试通过在线程构造函数或(内部) Thread.init()方法上设置断点来拦截线程>>creation<<。

线程具有名称Thread-2这一事实意味着它是由一个生成默认线程名的构造函数创建的。这表明它不是由JVM或标准Java类库创建的。它还缩小了可以用来创建它的构造函数。

我怎样才能得到关于这条线的更多信息..。

除了设置断点之外，我想不出任何办法。

..。或者让它终止？

如果您能够找到创建它的位置，则应该能够使用setDaemon(true)将其标记为守护进程线程。但是，这需要在线程启动之前完成。

另一种可能是通过遍历ThreadGroup树，然后在它上调用Thread.interrupt()来找到线程。( Thread.getAllStackTraces()是另一种跟踪线程对象的方法。)但是，不能保证线程会“尊重”中断并关闭。

最后，只需调用System.exit(...)即可。

更新

我提到过线程可能不尊重interrupt()，我并不奇怪stop()不能工作。(这是不可取的，甚至可能无法在某些平台上实现。)

但是，如果您已经成功地实现了真正找到神秘线程的代码，那么您可以仔细挖掘以查找Thread子类或实例化它的Runnable。如果你能打印出完全限定的类名，这将给你一个很大的线索，它的来源。(假设您在断点方面仍然没有成功，那么您可能需要使用“讨厌”反射从线程的私有target字段中提取runnable。)

Answer 2

不确定这是否足以满足您的需要，但是下面的代码将允许您尝试使用名称interrupt Thread：

    //Set of current Threads
    Set<Thread> setOfThread = Thread.getAllStackTraces().keySet();

    //Iterate over set to find yours
    for(Thread thread : setOfThread){
        if (thread.getName().equals("Thread-2")) {
            thread.interrupt();
            break;
        }
    }

另外，看看这个来自JavaSpecialists的JavaSpecialists，它试图根据Thread的构造函数调用安全管理器这一事实来识别线程的创建者。如果将自定义SecurityManager添加到系统中，则可以跟踪线程的发起者。

Answer 3

首先，您应该将_exit标志更改为volatile，因为它是从一个线程(您的主要方法)读取，然后由另一个线程(JCF/Swing事件处理程序)编写，所以您的主线程可能没有得到“新”值。具体而言:线程可能会将字段保存到CPU寄存器，而不是在循环时从内存中重新加载它。“易失性”会阻止这种行为：

private volatile boolean _exit;

但是，基于您的堆栈跟踪，我不认为这是您的问题，因为我们没有在其中看到您的主要方法。但无论如何，这都是应该做的，这只是很好的实践。

假设这不能修复它，我猜您的问题是，您至少有另外一个窗口(除了AgentFrame)没有被处理。在释放所有Windows之前，AWT线程不会停止。

将其放在主要方法的末尾：

System.out.println(Arrays.toString(Window.getWindows()))

我猜你会看到的不仅仅是你的DrawFrame。如果我猜的话，我会说UISettingsFrame在里面，没有感情。