如何分析Java核心转储？

我在RHEL6上的Tomcat中使用最新的Oracle Java Server JRE（1.8.091）运行了几个传统的Java Web应用程序。在过去的几周里，我在4个实例上总共发生了7次JVM崩溃，没有明显的时间模式或哪个实例崩溃。为了找出原因，我启用了核心转储

最近的崩溃产生了一个内核转储，但我似乎无法通过标准Java工具（如jstack和jmap）获得任何信息：

[root@c6e6c1b0b90e core-dump]# jstack -J-d64 /usr/jdk/jdk1.8.0_91/bin/java core.24182 
Attaching to core core.24182 from executable /usr/jdk/jdk1.8.0_91/bin/java, please wait...
Error attaching to core file: Can't attach to the core file
sun.jvm.hotspot.debugger.DebuggerException: Can't attach to the core file
    at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.attach0(Native Method)
    at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.attach(LinuxDebuggerLocal.java:286)
    at sun.jvm.hotspot.HotSpotAgent.attachDebugger(HotSpotAgent.java:673)
    at sun.jvm.hotspot.HotSpotAgent.setupDebuggerLinux(HotSpotAgent.java:611)
    at sun.jvm.hotspot.HotSpotAgent.setupDebugger(HotSpotAgent.java:337)
    at sun.jvm.hotspot.HotSpotAgent.go(HotSpotAgent.java:304)
    at sun.jvm.hotspot.HotSpotAgent.attach(HotSpotAgent.java:156)
    at sun.jvm.hotspot.tools.Tool.start(Tool.java:191)
    at sun.jvm.hotspot.tools.Tool.execute(Tool.java:118)
    at sun.jvm.hotspot.tools.JStack.main(JStack.java:92)
    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:498)
    at sun.tools.jstack.JStack.runJStackTool(JStack.java:140)
    at sun.tools.jstack.JStack.main(JStack.java:106)

我在gdb方面的成功有限，因为我可以检查回溯和帧，但调试符号不可用，并且似乎没有太多信息可用于指出问题的根源：

(gdb) bt
#0  0x00000036186325e5 in raise () from /lib64/libc.so.6
#1  0x0000003618633dc5 in abort () from /lib64/libc.so.6
#2  0x00007fe7462f8aa5 in os::abort(bool) () from /usr/jdk/jdk1.8.0_91/jre/lib/amd64/server/libjvm.so
#3  0x00007fe746497593 in VMError::report_and_die() () from /usr/jdk/jdk1.8.0_91/jre/lib/amd64/server/libjvm.so
#4  0x00007fe7462fe2cf in JVM_handle_linux_signal () from /usr/jdk/jdk1.8.0_91/jre/lib/amd64/server/libjvm.so
#5  0x00007fe7462f4a63 in signalHandler(int, siginfo*, void*) () from /usr/jdk/jdk1.8.0_91/jre/lib/amd64/server/libjvm.so
#6  <signal handler called>
#7  0x00007fe745f9d655 in G1ParScanThreadState::copy_to_survivor_space(InCSetState, oopDesc*, markOopDesc*) () from /usr/jdk/jdk1.8.0_91/jre/lib/amd64/server/libjvm.so
#8  0x00007fe745f9e20b in G1ParScanThreadState::trim_queue() () from /usr/jdk/jdk1.8.0_91/jre/lib/amd64/server/libjvm.so
#9  0x00007fe745f78af7 in G1ParEvacuateFollowersClosure::do_void() () from /usr/jdk/jdk1.8.0_91/jre/lib/amd64/server/libjvm.so
#10 0x00007fe745f84623 in G1ParTask::work(unsigned int) () from /usr/jdk/jdk1.8.0_91/jre/lib/amd64/server/libjvm.so
#11 0x00007fe7464b762f in GangWorker::loop() () from /usr/jdk/jdk1.8.0_91/jre/lib/amd64/server/libjvm.so
#12 0x00007fe7462f9f78 in java_start(Thread*) () from /usr/jdk/jdk1.8.0_91/jre/lib/amd64/server/libjvm.so
#13 0x0000003618a07aa1 in start_thread () from /lib64/libpthread.so.0
#14 0x00000036186e8aad in clone () from /lib64/libc.so.6

(gdb) frame 7
#7  0x00007fe745f9d655 in G1ParScanThreadState::copy_to_survivor_space(InCSetState, oopDesc*, markOopDesc*) () from /usr/jdk/jdk1.8.0_91/jre/lib/amd64/server/libjvm.so
(gdb)

（gdb）bt
#0 0x00000036186325e5，在/lib64/libc.so.6的raise（）中
#1 0x0000003618633dc5位于/lib64/libc.so.6的abort（）中
#在/usr/jdk/jdk1.8.091/jre/lib/amd64/server/libjvm.so中的os:：abort（bool）（）中的2 0x00007fe7462f8aa5
#VMError:：report_and_die（）（）中的3 0x00007fe746497593来自/usr/jdk/jdk1.8.0_91/jre/lib/amd64/server/libjvm.so
#4 0x00007fe7462fe2cf在/usr/jdk/jdk1.8.0\u 91/jre/lib/amd64/server/libjvm.so的JVM\u handle\u linux\u信号（）中
#来自/usr/jdk/jdk1.8.0_91/jre/lib/amd64/server/libjvm.so的信号处理器（int，siginfo*，void*）（）中的5 0x00007fe7462f4a63
#6  
#G1ParScanThreadState中的7 0x00007fe745f9d655:：从/usr/jdk/jdk1.8.0_91/jre/lib/amd64/server/libjvm.so将_复制到_survivor_空间（InCSetState，oopDesc*，markOopDesc*）（）
#G1ParScanThreadState:：trim_queue（）（）中的8 0x00007fe745f9e20b来自/usr/jdk/jdk1.8.091/jre/lib/amd64/server/libjvm.so
#9/usr/jdk/jdk1.8.0_91/jre/lib/amd64/server/libjvm.so中G1ParEvacuateFollowersClosure:：do_void（）（）中的0x00007fe745f78af7
#G1ParTask:：work（unsigned int）中的10 0x00007fe745f84623来自/usr/jdk/jdk1.8.091/jre/lib/amd64/server/libjvm.so
#11 0x00007fe7464b762f位于/usr/jdk/jdk1.8.091/jre/lib/amd64/server/libjvm.so的GangWorker:：loop（）中
#12 0x00007fe7462f9f78在/usr/jdk/jdk1.8.0_91/jre/lib/amd64/server/libjvm.so的java_start（Thread*）（）中
#13 0x0000003618a07aa1，位于/lib64/libpthread.so.0中的start_线程（）中
#/lib64/libc.so.6中的克隆（）中的14 0x00000036186e8aad
（gdb）第7帧
#G1ParScanThreadState中的7 0x00007fe745f9d655:：从/usr/jdk/jdk1.8.0_91/jre/lib/amd64/server/libjvm.so将_复制到_survivor_空间（InCSetState，oopDesc*，markOopDesc*）（）
（gdb）

因此，我的问题是：

我如何使用jstack/jmap分析核心转储

我可以和gdb进一步深入吗？（这不是我的专长）

这对我来说就像一个JVM bug。我怎样才能证实呢

---

谢谢。

我的具体案例似乎与这个JDK bug有关：它表明JVM由于堆中的损坏而发生故障。遗憾的是，我还没有找到崩溃的原因，也没有找到如何分析导致的内核转储