JavaCore/HeapDump文件及其分析方法 -
- ITeye博客
博客分类：
产生时间
Java程序运行时，有时会产生JavaCore及HeapDump文件，它一般发生于Java程序遇到致命问题的情况下。
有时致命问题发生后，Java应用不会死掉，还能继续运行；
但有时致命问题发生，Java进程会死掉；
为了能够保留Java应用发生致命错误前的运行状态，JVM在死掉前产生两个文件，分别为JavaCore及HeapDump文件。
有何区别
JavaCore是关于CPU的，而HeapDump文件是关于内存的。
JavaCore文件主要保存的是Java应用各线程在某一时刻的运行的位置，即JVM执行到哪一个类、哪一个方法、哪一个行上。它是一个文本文件，打开后可以看到每一个线程的执行栈，以stack&& trace的显示。通过对JavaCore文件的分析可以得到应用是否“卡”在某一点上，即在某一点运行的时间太长，例如数据库查询，长期得不到响应，最终导致系统崩溃等情况。
HeapDump文件是一个二进制文件，它保存了某一时刻JVM堆中对象使用情况，这种文件需要相应的工具进行分析，如IBM&& Heap Analyzer这类工具。这类文件最重要的作用就是分析系统中是否存在内存溢出的情况。
怎么生成
这两个文件可以用手工的方式生成，当我们会遇到系统变慢或无响应的情况，这时就以采用手工的方式生成JavaCore及HeapDump文件。
在Unix/Linux上，产生这两个文件的方法如下：
# ps -ef | grep java
17:30 pts/0 00:00:00 grep java
root
Oct27 ? 00:02:27 /usr/bin/java -server -XX:PermSize=64M -XX:MaxPermSize=128m -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager-Djava.util.logging.config.file=/usr/local/tomcat8090/conf/logging.properties -Djava.endorsed.dirs=/usr/local/tomcat8090/endorsed -classpath :/usr/local/tomcat8090/bin/bootstrap.jar-Dcatalina.base=/usr/local/tomcat8090 -Dcatalina.home=/usr/local/tomcat8090 -Djava.io.tmpdir=/usr/local/tomcat8090/temp&& org.apache.catalina.startup.Bootstrap start
# kill -3 5580
首先，找出Java进程id ，然后再执行‘kill -3 进程号’的操作，等文件生成后再做一次同样的操作，再产生一组文件。
如何分析
JavaCore文件
两组文件在分析JavaCore时特别有效，因为它可以看出在先后两个时间点上，线程执行的位置，如果发现先后两组数据中同一线程都执行在同一位置，则说明此处可能有问题，因为程序运行是极快的，如果两次均在某一点上，说明这一点耗时是很大的，通过对这两个文件进行分析，查出原因，进而解决问题。
JavaCore文件的头部有一个“Current Thread Details”标记，它记录了JavaCore产生时系统运行的线程id，使用线程id在文件中查找线程的详细信息，该信息中记载了线程运行哪个类的时候造成的JavaCore。
NULL ------------------------------------------------------------------------
0SECTION TITLE&& subcomponent dump routine
NULL ===============================
1TISIGINFOOUTOFMEMORY received
1TIDATETIME Date:
at 15:59:42
1TIFILENAME Javacore filename:/usr/WebSphere/AppServer/profiles/WCSProdNode2/javacore3298782.txt
NULL ------------------------------------------------------------------------
0SECTION XHPI subcomponent dump routine
NULL&& ==============================
1XHTIME Wed Dec 7 15:59:42 2011
1XHSIGRECV Unexpected&& signal -1 received at&& 0x0 in &unknown&. Processing&& terminated.
1XHFULLVERSION J2RE 1.4.2 IBM AIX build ca142ifx- (SR13&& FP2)
NULL&&&&&&&&&&
1XHCURRENTTHD Current Thread&& Details
NULL ----------------------
2XHCURRSYSTHD "WebContainer :&& 5" sys_thread_t:0x45FB5328
3XHNATIVESTACK Native Stack
NULL ------------
3XHSTACKLINEERR unavailable -&& stack address not valid
:::
:::
0SECTION XM subcomponent&& dump routine
NULL ============================
NULL&&&&&&&&&&&
1XMCURTHDINFO Current Thread Details
NULL ----------------------
3XMTHREADINFO "WebContainer : 5" (TID:0x70A8E260, sys_thread_t:0x45FB5328, state:R, native ID:0x5CC0)&& prio=5
4XESTACKTRACE at&& org.apache.taglibs.mon.core.ImportSupport$ImportResponseWrapper.getString(Unknown&& Source)
4XESTACKTRACE at&& org.apache.taglibs.mon.core.ImportSupport.acquireString(Unknown&& Source)
4XESTACKTRACE at&& org.apache.taglibs.mon.core.ImportSupport.doEndTag(Unknown&& Source)
4XESTACKTRACE at&& com.ibm._jsp._part._jspx_meth_c_import_3(_part.java(Compiled Code))
4XESTACKTRACE at&& com.ibm._jsp._part._jspx_meth_c_otherwise_3(_part.java(Compiled&& Code))
4XESTACKTRACE at&& com.ibm._jsp._part._jspx_meth_c_choose_4(_part.java(Compiled Code))
4XESTACKTRACE at&& com.ibm._jsp._part._jspService(_part.java:3237)
这样结合当时的日志文件可以找到问题产生的原因。不过，这种方法只能找到不是内存溢出的错误，对于在core文件头就有java/lang/outMemoryException的错误还是不知道是执行到哪个类的时候出现。
HeapDump文件
HeapDump文件是指定时刻的Java堆栈的快照，是一种镜像文件。Heap Analyzer工具通过分析HeapDump文件，哪些对象占用了太多的堆栈空间，来发现导致内存泄露或者可能引起内存泄露的对象。
IBM HeapAnalyzer
更多信息见官方网站地址：http://www./tech/heapanalyzer
在我们的应用程序发生内存泄露的时候，会生成heapdump文件，文件名字类似于这样：heapdump.129.172870.phd，即heapdump. &yyyymmdd&.&hhmmss&.&pid&.phd。&hhmmss&表示什么不知道，好像不是时间。heapdump文件是指定时刻的java堆栈的快照，是一种镜像文件。HeapAnalyzer工具通过分析heapdump文件，哪些对象占用了太多的堆栈空间，来发现导致内存泄露或者可能引起内存泄露的对象。&?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /&
下载解压得到ha28.jar和readme.html使用文档。启动该软件的方式：
启动后的界面如下，使用open file菜单，浏览打开我们需要进行内存堆栈分析的heapdump文件：
Heapdump文件都比较大，打开的时候比较长，推荐在配置比较好的机器上进行堆栈分析，-Xmx设置大一点。
打开heapdump文件后的效果图，不要关闭中间的窗口。在Analysis菜单可以选择多种视图进行分析，Tree View，Objects List等等。随软件标配的readme.html说明的非常详细请参考该文件了解各种视图的用法。
IBM Thread and Monitor Dump Analyzer for Java
更多信息见官方网站地址：http://www./tech/jca
在一些平台上，在有些情况下，javacore也被称为javadump，它包含jvm和应用程序相关的在特定时刻的一些诊断信息，如操作系统，应用程序环境，线程，native stack本地堆，锁，和内存的信息。在生成heapdump文件的时候，一般会生成javacore文件。
Operating System
Javacore file name
Format Meaning
Windows and Linux
javacore.YYYYMMDD.HHMMSS.PID.txt
YYYYMMDD =year month day, D=processID
javacorePID.TIME.txt
PID=processID, TIME=seconds since&?xml:namespace prefix = st1 ns = "urn:schemas-microsoft-com:office:smarttags" /&1/1/1970
IBM Thread and Monitor Dump Analyzer for Java通过分析javacore文件可以发现死锁，可能的悬挂线程，资源竞争等。
下载解压得到jca29.jar，jca.properties.xml和readme.html使用文档。启动该软件的方式：
启动后的界面如下，使用open thread dumps菜单，浏览打开我们需要进行分析的javacore文件：
随软件标配的readme.html说明的非常详细请参考该文件了解各种视图的用法。
浏览: 19510 次
来自: 南京
Procdump是一个轻量级的Sysinternal团队开发的命令行工具, 它的主要目的是监控应用程序的CPU异常动向, 并在此异常时生成crash dump文件, 供研发人员和管理员确定问题发生的原因. 你还可以把它作为生成dump的工具使用在其他的脚本中.
有了它, 就完全不需要在同一台服务器上使用诸如32位系统上的Debug Diag 1.1或是64位系统上的ADPlus了.
===============
在任务管理器里发现w3wp.exe的CPU总在49%-60%左右, 间歇性地会下降一些. 我们需要在w3wp.exe的CPU在50%以上并能维持三秒钟的情形下抓取两组dump. 如果使用debug diag或adplus的话, 会比较困难, 因为这需要等待时机并手动抓取. 容易出现抓到的dump里不包含那些引发异常的动作的情况.
解决方案 - 救世主procdump
===============
Procdump可以很方便地帮助我们应付这种情况, 加速动作过程, 抓取正确数据集合. 它会指定的时间内监控目标进程的cpu, 并在那个点抓取一个内存快照(dump).
procdump -ma -c 50 -s 3 -n 2 5844(Process Name or PID)
&&& -ma 生成full dump, 即包括进程的所有内存. 默认的dump格式包括线程和句柄信息.
&&& -c 在CPU使用率到达这个阀值的时候, 生成dump文件.
&&& -s CPU阀值必须持续多少秒才抓取dump文件.
&&& -n 在该工具退出之前要抓取多少个dump文件.
上面的命令行会监控w3wp.exe的CPU, 在CPU使用率超过百分之五十超过3秒的时候, 生成dump文件, 重复该动作两次.
下面是该命令的一个实例记录:
C:\Users\jaskis\Downloads\procdump& procdump -ma -c 50 -s 3 -n 2 5844
ProcDump v1.1 - Writes process dump files
Copyright (C) 2009 Mark Russinovich
Sysinternals -
Process:&&&&&&&&&&& w3wp.exe (5844)
CPU threshold:&&&&& 50% of system
Duration threshold: 3s
Number of dumps:&&& 2
Hung window check:& Disabled
Exception monitor:& Disabled
Dump file:&&&&&&&&& C:\Users\jaskis\Downloads\procdump\w3wp.dmp
Time&&&&&&& CPU& Duration
[23:48.35]& 59%& 1s
[23:48.36] CPU usage below threshold.
[23:48.37]& 54%& 1s
[23:48.38]& 55%& 2s
[23:48.39]& 61%& 3s
Process has hit spike threshold.
Writing dump file C:\Users\jaskis\Downloads\procdump\w3wp_839PM.dmp... Dump written.
[23:48.44]& 61%& 1s
[23:48.45]& 59%& 2s
[23:48.46]& 57%& 3s
Process has hit spike threshold.
Writing dump file C:\Users\jaskis\Downloads\procdump\w3wp_846PM.dmp...
Dump written.
ProcDump v3.01
Using ProcDump.exe to monitor w3wp.exe for CPU spikes
&&相关文章推荐
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：1362105次
积分：19771
积分：19771
排名：第403名
原创：448篇
转载：1067篇
评论：143条
(5)(9)(4)(1)(2)(3)(2)(7)(4)(2)(9)(4)(12)(14)(2)(8)(7)(13)(2)(17)(23)(14)(12)(9)(8)(16)(12)(13)(6)(10)(22)(16)(32)(26)(22)(23)(20)(20)(12)(7)(11)(22)(2)(11)(10)(19)(7)(5)(5)(13)(5)(11)(11)(30)(14)(11)(10)(15)(21)(11)(12)(2)(3)(5)(8)(25)(11)(5)(10)(8)(3)(7)(8)(9)(8)(5)(9)(13)(10)(18)(13)(10)(3)(4)(2)(13)(3)(11)(10)(4)(15)(3)(2)(10)(7)(4)(3)(13)(8)(5)(10)(11)(5)(2)(6)(3)(11)(8)(10)(7)(11)(14)(8)(4)(35)(29)(7)(7)(18)(25)(1)(9)(11)(11)(18)(15)(9)(16)(9)(15)(16)(19)(9)(14)(37)(21)(26)(15)(1)用户名：百度技术
文章数：403
评论数：156
访问量：1312829
注册日期：
阅读量：1297
阅读量：3317
阅读量：442782
阅读量：1128896
51CTO推荐博文
Core，又称之为Core Dump文件，是Unix/Linux操作系统的一种机制，对于线上服务而言，Core令人闻之色变，因为出Core的过程意味着服务暂时不能正常响应，需要恢复，并且随着吐Core进程的内存空间越大，此过程可能持续很长一段时间（例如当进程占用60G+以上内存时，完整Core文件需要15分钟才能完全写到磁盘上），这期间产生的流量损失，不可估量。
凡事皆有两面性，OS在出Core的同时，虽然会终止掉当前进程，但是也会保留下第一手的现场数据，OS仿佛是一架被按下快门的相机，而照片就是产出的Core文件。里面含有当进程被终止时内存、CPU寄存器等信息，可以供后续开发人员进行调试。
关于Core产生的原因很多，比如过去一些Unix的版本不支持现代Linux上这种GDB直接附着到进程上进行调试的机制，需要先向进程发送终止信号，然后用工具阅读core文件。在Linux上，我们就可以使用kill向一个指定的进程发送信号或者使用gcore命令来使其主动出Core并退出。如果从浅层次的原因上来讲，出Core意味着当前进程存在BUG，需要程序员修复。从深层次的原因上讲，是当前进程触犯了某些OS层级的保护机制，逼迫OS向当前进程发送诸如SIGSEGV(即signal 11)之类的信号, 例如访问空指针或数组越界出Core，实际上是触犯了OS的内存管理，访问了非当前进程的内存空间，OS需要通过出Core来进行警示，这就好像一个人身体内存在病毒，免疫系统就会通过发热来警示，并导致人体发烧是一个道理（有意思的是，并不是每次数组越界都会出Core，这和OS的内存管理中虚拟页面分配大小和边界有关，即使不出Core，也很有可能读到脏数据，引起后续程序行为紊乱，这是一种很难追查的BUG）。
说了这些，似乎感觉Core很强势，让人感觉缺乏控制力，其实不然。控制Core产生的行为和方式，有两个途径：
1.修改/proc/sys/kernel/core_pattern文件，此文件用于控制Core文件产生的文件名，默认情况下，此文件内容只有一行内容：&core&，此文件支持定制，一般使用%配合不同的字符，这里罗列几种：
%p& 出Core进程的PID
%u& 出Core进程的UID
%s& 造成Core的signal号
%t& 出Core的时间，从0:00:00开始的秒数
%e& 出Core进程对应的可执行文件名
2.Ulimit &C命令，此命令可以显示当前OS对于Core文件大小的限制，如果为0，则表示不允许产生Core文件。如果想进行修改，可以使用：
Ulimit &cn
其中n为数字，表示允许Core文件体积的最大值，单位为Kb，如果想设为无限大，可以执行：
Ulimit -cunlimited
产生了Core文件之后，就是如何查看Core文件，并确定问题所在，进行修复。为此，我们不妨先来看看Core文件的格式，多了解一些Core文件。
首先可以明确一点，Core文件的格式ELF格式，这一点可以通过使用readelf -h命令来证实，如下图：
从读出来的ELF头信息可以看到，此文件类型为Core文件，那么readelf是如何得知的呢？可以从下面的数据结构中窥得一二：
其中当值为4的时候，表示当前文件为Core文件。如此，整个过程就很清楚了。
了解了这些之后，我们来看看如何阅读Core文件，并从中追查BUG。在Linux下，一般读取Core的命令为：
gdb exec_file core_file
使用GDB，先从可执行文件中读取符号表信息，然后读取Core文件。如果不与可执行文件搅合在一起可以吗？答案是不行，因为Core文件中没有符号表信息，无法进行调试，可以使用如下命令来验证：
Objdump &x core_file | tail
我们看到如下两行信息：
SYMBOL TABLE:
no symbols
表明当前的ELF格式文件中没有符号表信息。
为了解释如何看Core中信息，我们来举一个简单的例子：
#include &stdio.h&
int main(){
int stack_of[];
这段程序使用gcc &g a.c &o a进行编译，运行后直接会Core掉，使用gdb a core_file查看栈信息，可见其Core在了这行代码：
int stack_of[];
原因很明显，直接在栈上申请如此大的数组，导致栈空间溢出，触犯了OS对于栈空间大小的限制，所以出Core（这里是否出Core还和OS对栈空间的大小配置有关，一般为8M）。但是这里要明确一点，真正出Core的代码不是分配栈空间的int stack_of[]， 而是后面这句int b=1, 为何？出Core的一种原因是因为对内存的非法访问，在上面的代码中分配数组stack_of时并未访问它，但是在其后声明变量并赋值，就相当于进行了越界访问，继而出Core。为了解释得更详细些，让我们使用gdb来看一下出Core的地方，使用命令gdb a core_file可见：
可知程序出现了段错误&Segmentation fault&， 代码是int b=1这句。我们来查看一下当前的栈信息：
其中可见指令指针rip指向地址为0&400473, 我们来看下当前的指令是什么：
这条movl指令要把立即数1送到0xffffffffe8287bfc(%rbp)这个地址去，其中rbp存储的是帧指针，而0xffffffffe8287bfc很明显是一个负数，结果计算为-。这就可以解释了：其中我们申请的int stack_of[]占用字节，b是int类型，占用4个字节，且栈空间是由高地址向低地址延伸，那么b的栈地址就是0xffffffffe8287bfc(%rbp)，也就是$rbp-。当我们尝试访问此地址时：
可以看到无法访问此内存地址，这是因为它已经超过了OS允许的范围。
下面我们把程序进行改进：
#include &stdio.h&
int main(){
int* stack_of = malloc(sizeof(int)*);
使用gcc &O3 &g a.c &o a进行编译,运行后会再次Core掉，使用gdb查看栈信息，请见下图：
可见BUG出在第7行，也就是*a=b这句，这时我们尝试打印b的值，却发现符号表中找不到b的信息。为何？原因在于gcc使用了-O3参数，此参数可以对程序进行优化，一个负面效应是优化过程中会舍弃部分局部变量，导致调试时出现困难。在我们的代码中，b声明时即赋值，随后用于为*a赋值。优化后，此变量不再需要，直接为*a赋值为1即可，如果汇编级代码上讲，此优化可以减少一条MOV语句，节省一个寄存器。
此时我们的调试信息已经出现了一些扭曲，为此我们重新编译源程序，去掉-O3参数（这就解释了为何一些大型软件都会有debug版本存在，因为debug是未经优化的版本，包含了完整的符号表信息，易于调试），并重新运行，得到新的core并查看，如下图：
这次就比较明显了，b中的值没有问题，有问题的是a，其指向的地址是非法区域，也就是a没有分配内存导致的Core。当然，本例中的问题其实非常明显，几乎一眼就能看出来，但不妨碍它成为一个例子，用来解释在看Core过程中，需要注意的一些问题。
【本文首发于：
【本文出自 “” 博客，谢绝转载！
了这篇文章
类别：┆阅读(0)┆评论(0)
11:08:34 10:47:001,在程序奔溃前部署。adplus.exe -crash -pn explorer.exe -o d:
-crash:当进程挂掉的时候抓取dump，只能抓取到进程报错时的信息，如果进程不报错，就无法抓取到dump-hang：当开启windbugu之后就开始抓取dump，主要用于抓取进程异常，如进程未崩溃的情况，例如进程占用cpu 100%
-pn：进程的PID或进程名，如果是进程名，会区分大小写-o： dump的输出路径
FULLDUMP_SecondChance_ch_InvalidHandle_iexplore在关闭崩溃程序的时候才生成。另外两个dump崩溃的时候马上生成。
2，程序崩溃后停留在错误提示窗口，崩溃发生后再抓取。Windbg-&file-&Attach to a Process在弹出的节面找到崩溃的进程。在命令栏填.dump -ma d:\fuckie.dmp
-m : 缺省选项，生成标准minidump,文件较小，便于传输，只包含系统、加载的模块、进程、线程信息。-ma : 包括尽量多选项的minidump,文件很大，包括完整的内存内容，句柄，未加载模块等。-mFhutwd :带有数据段、非共享的读写内存页和其他有用信息的minidump,是一种折中方案。
阅读(...) 评论()