可能的原因：
1)系统OOM Killer //grep kill /var/log/messages,查看kill时对应的内存占用total-vm,anon-rss,file-rss
2)人为的kill  //history |grep -i kill
3)代码代用system.exit() //反查代码
4)JVM自身bug //DirectMemory 的默认大小是64M，而JDK6之前和JDK6的某些版本的SUN JVM，存在一个BUG，在用-Xmx设定堆空间大小的时候，也设置了DirectMemory的大小。加入设置了-Xmx2048m，那么jvm最终可分配的内存大小为4G多一些，是预期的两倍。
解决方式是设置jvm参数-XX:MaxDirectMemorySize=128m，指定DirectMemory的大小。
5)内存问题    //内存不足，比如申请一个大的对象的时间。不能及时gc
6)native stack溢出导致 //不受jvm控制，但是被java占用的
致命错误出现的时候，JVM生成了hs_err_pid<pid>.log这样的文件，其中往往包含了虚拟机崩溃原因的重要信息
默认创建在工作目录：可以结合find -name hs_err_pid*
hs_err_pid<pid>.log文件内容

1)触发致命错误的操作异常或者信号
2)版本和配置信息
3)触发致命异常的线程详细信息和线程栈
4)当前运行的线程列表和它们的状态
5)堆的总括信息
6)加载的本地库
7)命令行参数
8)环境变量
9)OS的CPU信息

可能的原因：
1)系统OOM Killer //grep kill /var/log/messages,查看kill时对应的内存占用total-vm,anon-rss,file-rss
2)人为的kill  //history |grep -i kill
3)代码代用system.exit() //反查代码
4)JVM自身bug //DirectMemory 的默认大小是64M，而JDK6之前和JDK6的某些版本的SUN JVM，存在一个BUG，在用-Xmx设定堆空间大小的时候，也设置了DirectMemory的大小。加入设置了-Xmx2048m，那么jvm最终可分配的内存大小为4G多一些，是预期的两倍。
解决方式是设置jvm参数-XX:MaxDirectMemorySize=128m，指定DirectMemory的大小。
5)内存问题    //内存不足，比如申请一个大的对象的时间。不能及时gc
6)native stack溢出导致 //不受jvm控制，但是被java占用的
致命错误出现的时候，JVM生成了hs_err_pid<pid>.log这样的文件，其中往往包含了虚拟机崩溃原因的重要信息
默认创建在工作目录：可以结合find -name hs_err_pid*
hs_err_pid<pid>.log文件内容

1)触发致命错误的操作异常或者信号
2)版本和配置信息
3)触发致命异常的线程详细信息和线程栈
4)当前运行的线程列表和它们的状态
5)堆的总括信息
6)加载的本地库
7)命令行参数
8)环境变量
9)OS的CPU信息