java - 使用 jmap(1.5) 从 java 核心转储中提取信息

Question

长话短说，一些同事正在运行一个非常旧的设置(x86_64 中的 oc4j jdk1.5.6)和一个恰好是关键任务的应用程序。他们最近尝试部署应用程序的新版本，但一旦他们这样做，java 进程就会抛出核心转储并死掉。

问题是，核心转储似乎没问题，gdb可以打开它们，但是jmap和其他工具拒绝处理它们:

# /usr/java/jdk1.5.0_06/bin/jmap /usr/java/jdk1.5.0_06/bin/java core
Attaching to core core from executable /usr/java/jdk1.5.0_06/bin/java, please wait...
Error attaching to core file: Can't attach to the core file

较新的版本抛出异常:

# jdk1.6.0_45/bin/jmap /usr/java/jdk1.5.0_06/bin/java core
Attaching to core core from executable /usr/java/jdk1.5.0_06/bin/java, please wait...
Exception in thread "main" java.lang.reflect.InvocationTargetException
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at sun.tools.jmap.JMap.runTool(JMap.java:179)
        at sun.tools.jmap.JMap.main(JMap.java:110)
Caused by: sun.jvm.hotspot.runtime.VMVersionMismatchException: Supported versions are 20.45-b01. Target VM is 1.5.0_06-b05
        at sun.jvm.hotspot.runtime.VM.checkVMVersion(VM.java:224)
        at sun.jvm.hotspot.runtime.VM.<init>(VM.java:287)
        at sun.jvm.hotspot.runtime.VM.initialize(VM.java:357)
        at sun.jvm.hotspot.bugspot.BugSpotAgent.setupVM(BugSpotAgent.java:594)
        at sun.jvm.hotspot.bugspot.BugSpotAgent.go(BugSpotAgent.java:494)
        at sun.jvm.hotspot.bugspot.BugSpotAgent.attach(BugSpotAgent.java:348)
        at sun.jvm.hotspot.tools.Tool.start(Tool.java:169)
        at sun.jvm.hotspot.tools.PMap.main(PMap.java:67)
        ... 6 more

gdb 提供的信息很少没有符号:

Reading symbols from /usr/java/jdk1.5.0_06/bin/java...(no debugging symbols found)...done.

[New Thread 9841]
[New Thread 31442]
[New Thread 31441]
...
Core was generated by `/usr/java/jdk1.5.0_06/bin/java -server -XX:+UseConcMarkSweepGC -XX:MaxHeapFreeR'.
Program terminated with signal 6, Aborted.
#0  0x0000003bbf030285 in ?? ()
(gdb) bt
#0  0x0000003bbf030285 in ?? ()
#1  0x0000003bbf031d30 in ?? ()
#2  0x0000000000000000 in ?? ()

我从核心收集到的唯一有值(value)的信息是大多数线程被封锁(我远不是一个 gdb 大师):

  35 Thread 10093  0x0000003bbfc0b1c0 in pthread_cond_timedwait@@GLIBC_2.3.2 ()
   from /lib64/libpthread.so.0
  34 Thread 10097  0x0000003bbfc0b1c0 in pthread_cond_timedwait@@GLIBC_2.3.2 ()
   from /lib64/libpthread.so.0
  33 Thread 10099  0x0000003bbfc0b1c0 in pthread_cond_timedwait@@GLIBC_2.3.2 ()
   from /lib64/libpthread.so.0

此外，我不知道它是否真的相关。该应用程序几乎总是负载很重，我敢打赌，已经存在一些锁争用，但由于它是另一个团队的应用程序，我对此知之甚少。

我想这是不可能的，但是我们可以做些什么来获取 Java 线程转储或类似的东西吗？ Sun 曾经提供 jdk 的调试信息吗，我猜现在 openjdk 可用吗？

提前致谢。

更新:另一个团队在没有从核心转储中获取信息的情况下解决了这个问题，只是在测试系统中成功复制问题后通过反复试验。我仍然对这件事很感兴趣:如何调试 jmap 无法处理的古老 java 核心转储，它可能对 future 有值(value)的信息，尽管似乎没有解决该问题的方法。可能是 JVM 内存损坏了，这就是 jmap 无法处理它的原因。

Answer 1

您可以在启动应用程序时添加以下 JVM 选项，这将允许您在发生致命 JVM 错误时运行您指定的任何命令:

-XX:OnError="<cmd args>"

例如，您可以运行一个命令(或脚本)来执行某些操作，例如获取堆或线程转储。