排查1：查看系统资源情况
主要发现此刻CPU均突然增长，swap内存也有所增长但是并非资源耗尽的情况。此刻想到了Linux进行OOM-killer机制。
排查2:查核系统内核是否触发oom机制。
日志：/var/log/message --一般oom信息这里会找到，但是排查没有相关kill和内存信息。参考命令dmesg
了解：https://www.oracle.com/technetwork/articles/servers-storage-dev/oom-killer-1911807.html
排查3：java应用程序触发的oom
这个找了应用本身的log，发现并没有“java.lang.OutOfMemoryError: Java heap space”等信息
可查看JVM参数 -XX:+HeapDumpOnOutOfMemoryError 和 -XX:HeapDumpPath及是否产生相关dump，如果有则可
http://blog.51cto.com/renzhiyuan/2288355 之前分享的工具分析。 --本次查核没有，则继续分析。
排查4：JVM的bug导致
当jvm出现致命错误时，会生成一个错误文件 hs_err_pid.log。
参考：https://my.oschina.net/xionghui/blog/498785
重要信息：“SIGSEGV(0xb)”表示jvm crash时正在执行jni代码，而不是在执行java或者jvm的代码，如果没有在应用程序里手动调用jni代码，那么很可能是JIT动态编译时导致的该错误。其中SIGSEGV是信号名称，0xb是信号码，pc=0x00007fb8b18fdc6c指的是程序计数器的值，pid=191899是进程号，tid=140417770411776是线程号。
于是~基本确认是bug问题~~
原文：http://blog.51cto.com/renzhiyuan/2313938