000, sa_flags=0x00000000
SIGINT: SIG_IGN, sa_mask[0]=0x00000000, sa_flags=0x00000000
SIGTERM: [libjvm.so+0x8210d0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGQUIT: [libjvm.so+0x8210d0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
此部分内容为Linux特有的内容，主要描述针对信号所使用的处理程序。
系统信息
日志最后一大部分是操作系统相关的内容，也是整个文件当中最直观的部分，主要包含操作系统版本、CPU信息和内存概要。
操作系统
OS:Red Hat Enterprise Linux Server release 7.0 (Maipo)
uname:Linux 3.10.0-514.el7.x86_64 #1 SMP Wed Oct 19 11:24:13 EDT 2016 x86_64
libc:glibc 2.17 NPTL 2.17
rlimit: STACK 8192k, CORE infinity, NPROC infinity, NOFILE 65536, AS infinity
load average:6.02 5.99 5.89
此部分内容为针对操作系统的基本信息和运行中的平均负载情况。
内存信息
Memory: 4k page, physical 131862044k(14543760k free), swap 33554428k(33531212k free)
/proc/meminfo:
MemTotal: 131862044 kB
MemFree: 14543760 kB
MemAvailable: 120724836 kB
Buffers: 1584 kB
Cached: 107254088 kB
......
HugePages_Surp: 0
Hugepagesize: 2048 kB
DirectMap4k: 378736 kB
DirectMap2M: 133838848 kB
内存部分在文件中实际分了两部分，这里我们放在一起展示，因为篇幅原因内存详情只展示开头和结尾的部分，这部分主要包含系统运行时的内存使用情况，这里有个问题，我们的应用跑在容器之中，分配的容器内存只有8G，但这里获取到的内存则是整台宿主机的内存。
CPU信息
CPU:total 32 (1 cores per cpu, 1 threads per core) family 6 model 6 stepping 3, cmov, cx8, fxsr, mmx, sse, sse2, sse3, tsc
/proc/cpuinfo:
# 此处省略掉每个CPU核心的描述信息
CPU信息部分包括概览以及对每个核心的描述，因为篇幅原因省略掉了，此处和内存存在同样的问题，容器内的应用获取到了宿主机的CPU信息。
总结
通过查询相关资料，对JVM致命错误日志内容有了初步的了解，在学习的过程中发现了以下几个疑点：
- 崩溃时正在通过JNI方式调用SetByteArrayRegion这个方法进行数组处理，通过堆栈信息可以看到是在调用RemoteTCPConnection.receive()时报的错，而这个类是我们引用的MQ中的方法，后续需要对相关的代码进行排查，确定使用的版本是否正常，相关代码是否存在问题。
- 在查看堆内存和事件部分可以得知，在崩溃时内存中新生代的使用率已经达到了100%，在事件中也触发了ParallelGCFailedAllocation，考虑是不是因为在调用RemoteTCPConnection.receive()时出现了内存溢出问题。
- 容器内的应用在获取硬件信息时获取到了宿主机的硬件信息，这个地方会有一个隐患，java默认使用物理内存的一半来作为虚拟机的内存，如果说在使用java时没有手动设定
Xmx参数，也就意味着该进程使用的内存可能会远大于容器的内存。此份日志文件中可以看到设置的-Xmx=8192m，但实际我们给容器分配的内存也是8G，而另外的应用中使用的Tomcat并没有设置此参数。
- 在排查问题时还发现JDK 7本身与容器存在兼容性问题，网上的资料建议使用JDK 8u131以后的版本，但是博主未在JDK 8u131的更新日志中发现相关内容，倒是在8u191的更新日志中找到了，目前计划将JDK更新至8u201，同时使用G1垃圾回收器，验证能不能解决之前出现的GC问题。
以上是排查过程中发现的问题，本人水平有限，可能问题定位不准确，这份总结仅供各位参考，实际的问题还需要多方面的排查和验证。
