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

长话短说，一些同事正在运行一个相当旧的设置（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 ?? ()

我从核心收集到的唯一有价值的信息是大多数线程 被屏蔽了（我离成为 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的debuginfo，我猜现在openjdk可以提供该信息？

提前致谢。

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

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

-XX:OnError="<cmd args>"

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