1.core dump介绍
程序异常退出（crash）时会自动生成一个core文件，包含了程序运行时的内存，寄存器状态，堆栈指针，内存管理等信息，也就是把程序当时工作的状态存储成一个文件。不仅仅是在出错的时候会生成core dump文件，在系统卡住或者cpu使用率很高的时候也可以手动触发生成core dump文件（当然这种情况也可以直接通过jmap和jstack dump出内存和线程堆栈，但JDK1.6以前，这2个命令经常执行不成功），这样就可以很好的分析了。
2.生成core dump文件
core dump文件生成开关其实是通过对生成的文件大小进行控制达到的，默认大小是0，也就是说默认是不生成core dump文件的，可以通过命令ulimit -c进行查看。将此参数修改成unlimited就可以生成core dump文件了，但值得注意的一点是，每个应用进程都会读取自己的一套系统参数，可以查看进程对应的内存文件/proc/<pid>/limits中的信息来判断修改后的参数值是否对此应用进程生效了，limits文件中的信息如下：
Limit Soft Limit Hard Limit Units
Max cpu time unlimited unlimited seconds
Max file size unlimited unlimited bytes
Max data size unlimited unlimited bytes
Max stack size 10485760 unlimited bytes
Max core file size unlimited unlimited bytes
Max resident set unlimited unlimited bytes
Max processes 20480 20480 processes
Max open files 204800 204800 files
Max locked memory 32768 32768 bytes
Max address space unlimited unlimited bytes
Max file locks unlimited unlimited locks
Max pending signals 1024 1024 signals
Max msgqueue size 819200 819200 bytes
上述信息中的对应的参数值为unlimited，代表此应用进程的core dump开关是开着的。ulimit -c unlimited这个命令可以在很多地方修改，比如用root在命令行执行，在/etc/profile中增加（/etc/profile文件中已经有defaultulimit -S -c 0 > /dev/null 2>&1，可以直接修改0为unlimited），在用户的.bash_profile中增加..这些方式执行后的影响范围还是挺复杂的，到现在也没弄清楚。当时通过root用户命令行修改后，在shell里查询ulimit -c是生效了，以为应用程序也生效了，觉得不用应用都不需要重启就生效了挺好，等到下一次crash的时候发现还是没有生成core dump文件，于是到文件/proc/<pid>/limits中检查此参数值才发现应用程序所读取的值还是0。后来采用一种比较简单直接的方式，用root用户修改/etc/profile文件中的ulimit -c的值，然后重新登录，重启应用，再检查/proc/<pid>/limits中的值，确保参数已经生效，后来应用再crash时core dump文件也如期而至，心里暗爽，终于可以开始分析堆栈了。
core dump文件生成的默认路径在用户的工作目录（启动脚本目录），可以通过设置参数/proc/sys/kernel/core_pattern的值改变core dump文件的最终生成路径及文件名格式。core dump文件成功后，在jboss控制台错误日志中的日志也多了core dumped关键字，如下：
/opt/.../jboss/bin/run.sh: line 181: 9176 段错误 (core dumped) "$JAVA" $JAVA_OPTS -Djava.endorsed.dirs="$JBOSS_ENDORSED_DIRS" -classpath "$JBOSS_CLASSPATH" org.jboss.Main "$@"
3.core dump分析
