为什么这个Java进程无法终止?

Mat*_*ard 11 java linux debugging

我在构建服务器上有一个间歇性问题,其中构建中的Java进程无法终止并且似乎永远运行(使用100%的CPU)永远(我已经看到它在周末运行了2天以上通常需要大约10分钟).kill -9 pid似乎是阻止这个过程的唯一方法.

我试过调用kill -QUIT pid这个过程,但它似乎没有产生任何到STDOUT的堆栈跟踪(也许它没有响应信号?).没有-F force选项的jstack似乎无法连接到正在运行的JVM,但是使用force选项它会产生下面包含的输出.

不幸的是,即使有了堆栈跟踪,我也看不到任何明显的进一步调查路径.

据我所知,它显示了两个运行Object.wait的'BLOCKED'线程(它们的堆栈似乎只包含核心Java代码,不包含我们的代码)和第三个没有堆栈输出的'IN_VM'.

我应采取哪些步骤来收集有关问题原因的更多信息(或者更好,我该如何解决)?

$ /opt/jdk1.6.0_29/bin/jstack -l -F 5546
Attaching to process ID 5546, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 20.4-b02
Deadlock Detection:

No deadlocks found.

Finding object size using Printezis bits and skipping over...
Thread 5555: (state = BLOCKED)

Locked ownable synchronizers:
    - None

Thread 5554: (state = BLOCKED)
 - java.lang.Object.wait(long) @bci=0 (Interpreted frame)
 - java.lang.ref.ReferenceQueue.remove(long) @bci=44, line=118 (Interpreted frame)
 - java.lang.ref.ReferenceQueue.remove() @bci=2, line=134 (Interpreted frame)
 - java.lang.ref.Finalizer$FinalizerThread.run() @bci=3, line=159 (Interpreted frame)

Locked ownable synchronizers:
    - None

Thread 5553: (state = BLOCKED)
 - java.lang.Object.wait(long) @bci=0 (Interpreted frame)
 - java.lang.Object.wait() @bci=2, line=485 (Interpreted frame)
 - java.lang.ref.Reference$ReferenceHandler.run() @bci=46, line=116 (Interpreted frame)

Locked ownable synchronizers:
    - None

Thread 5548: (state = IN_VM)

Locked ownable synchronizers:
    - None

(Java版本1.6.0更新29,在Scientific Linux 6.0版上运行)

更新:

跑步strace -f -p 894产生了看似无穷无尽的......

[pid   900] sched_yield()               = 0
[pid   900] sched_yield()               = 0
...
Run Code Online (Sandbox Code Playgroud)

然后当Ctrl-Cd

Process 894 detached
...
Process 900 detached
...
Process 909 detached
Run Code Online (Sandbox Code Playgroud)

jmap -histo 894不连接但jmap -F -histo 894返回...

Attaching to process ID 894, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 20.4-b02
Iterating over heap. This may take a while...
Finding object size using Printezis bits and skipping over...
Finding object size using Printezis bits and skipping over...
Object Histogram:

num       #instances    #bytes  Class description
--------------------------------------------------------------------------
1:      11356   1551744 * MethodKlass
2:      11356   1435944 * ConstMethodKlass
3:      914 973488  * ConstantPoolKlass
4:      6717    849032  char[]
5:      16987   820072  * SymbolKlass
6:      2305    686048  byte[]
7:      914 672792  * InstanceKlassKlass
8:      857 650312  * ConstantPoolCacheKlass
9:      5243    167776  java.lang.String
10:     1046    108784  java.lang.Class
11:     1400    87576   short[]
12:     1556    84040   * System ObjArray
13:     1037    64584   int[]
14:     103 60152   * ObjArrayKlassKlass
15:     622 54736   java.lang.reflect.Method
16:     1102    49760   java.lang.Object[]
17:     937 37480   java.util.TreeMap$Entry
18:     332 27960   java.util.HashMap$Entry[]
19:     579 27792   java.nio.HeapByteBuffer
20:     578 27744   java.nio.HeapCharBuffer
21:     1021    24504   java.lang.StringBuilder
22:     1158    24176   java.lang.Class[]
23:     721 23072   java.util.HashMap$Entry
24:     434 20832   java.util.TreeMap
25:     689 18936   java.lang.String[]
26:     238 17440   java.lang.reflect.Method[]
27:     29  16800   * MethodDataKlass
28:     204 14688   java.lang.reflect.Field
29:     330 13200   java.util.LinkedHashMap$Entry
30:     264 12672   java.util.HashMap
...
585:        1   16  java.util.LinkedHashSet
586:        1   16  sun.rmi.runtime.NewThreadAction$2
587:        1   16  java.util.Hashtable$EmptyIterator
588:        1   16  java.util.Collections$EmptySet
Total :     79700   8894800
Heap traversal took 1.288 seconds.

sud*_*ode 1

线程 5554 可能表明您有很多具有 Finalize 方法的对象,和/或 Finalize 方法存在一些问题。也许值得一看。

我不熟悉 jstack,但看起来它输出的信息比我更熟悉的线程转储的信息要少。尝试获取线程转储可能有用:kill -QUIT java_pid。请注意,转储将转到标准输出,这可能是控制台或日志文件,具体取决于您的设置。

如果很难弄清楚 stdout 被定向到哪里,并且假设它要去一个文件,您可以使用find最近的修改时间来识别候选文件。对此博文的评论中建议了这一点:

您可以在根目录运行 find[2] 命令并找出过去 x 秒内发生的变化。我通常使用 find 来帮助我访问过去 10 分钟内更改的所有日志,例如: find /var/tomcat -mmin -3 -print (打印出过去 3 天内在 /var/tomcat 下修改的所有文件分钟)。

请注意,如果您使用 JVM 运行-Xrs,这意味着SIGQUIT将不会安装信号处理程序,并且您将无法使用请求线程转储的方法。