javacore入门介绍

什么是javacore

javacore文件通常以txt方式结尾,名称格式主要是以javacore开头, 加上日期,产生的时间,当时的线程编号,如javacore.20100719.003424.299228.txt(Unix)

发送中断signal
AIX和Linux: SIGQUIT, kill -3 PID
Windows: Ctrl+Break, DrAdmin in WAS(未验证过)
在java的执行代码中使用JavaDump()方法(未验证过)
com.ibm.jvm.Dump.javaDump()方法促使JVM dump
发布ProblemDiagnosticsLabToolkit应用包,通过可视化页面直接生成相关文件
系统在异常时自动throw(程序不一定退出)
严重的本地调用出错
内存不足(例如 OutOfMemory)

操作系统相关信息JDK版本信息
关注jdk的版本(1.5前后差别比较大),32位和64位在内存要求上也有区别
JVM的启动参数信息
关注一些特殊的虚拟机参数如xms,xmx,xss,java.ext.dirs等，特别是内存分配要和线程数匹配，避免xms太小(频繁gc和扩展)
JVM堆内存信息,已装载入的类信息
JIT Core Cache和JIT Data Cache是JIT编译器使用的，用于提高运行效率。一般关注Object(Reversed)(堆内存分配)和Class(用于类加载)的内存使用率
dump产生原因与时间
用于追溯当时的现状
GC记录
关注Full GC(Global GC)情况,通常伴随比较多的GC线程
所有Thread执行情况(包括应用程序内部执行线程,容器线程,垃圾回收线程,定时线程,线程池线程,页面请求转发线程等多种线程信息)

整个图包括三部分，左边是线程列表，选择某个线程后，中间会展示该线程与其他线程的等待依赖关系，右边会显示线程的详细堆栈信息。通过在线程列表中对Name,State,Stack几列进行排序，可以对每类线程数量、是否有明显的瓶颈有个大概的印象，便于接下来的具体分析。

死锁 Deadlock
多个线程竞争多个资源，出现相互等待资源又不释放资源的情况，这种情况在现实中并不多见。
执行中 Runnable
通常这类线程堆栈真处于发送数据，数值计算，类型转换等操作。
等待资源 Waiting on condition
等待资源，如果堆栈信息明确是应用代码，则证明该线程正在等待资源，一般是大量读取某资源，且该资源采用了资源锁的情况下，线程进入等待状态，等待资源的读取。又或者，正在等待其他线程的执行等
等待监控器检查资源 Waiting on monitor
暂停 Suspended
对象等待中 Object.wait()
阻塞 Blocked
线程阻塞，是指当前线程执行过程中，所需要的资源长时间等待却一直未能获取到，被容器的线程管理器标识为阻塞状态，可以理解为等待资源超时的线程。这种情况在was的日志中，一般可以看到CPU饥渴，或者某线程已执行了XX秒的信息
停止 Parked

Thread开头	一般是应用自己起的后台线程，或者自己搞的线程池(没有重命名的时候),如果是独立进程大多业务都跑在这里
WebContainer	was容器线程，was的话业务一般都在这里，受容器线程数量控制
Timer	Timer定时任务，一些连接池等用于监控池内对象
Quartz	Quartz用于定时任务的线程，不受容器控制
Finalizer	用于实现finalize特殊方法的线程
GC Slave	GC线程，频繁gc的时候会出现不少
Main	主线程
JIT	用于实现JIT的线程

数百K的纯文本,最好借助工具,例如jca分析工具
采集连续的多个时间点的javacore,方便对比(手动)
一般的线程执行都会非常快，如果出现某个资源的阻塞，在短时间内的两个javacore，该线程的堆栈会变化不大。或多次javacore的线程都集中在等待某些资源。
了解app的性质,基本处理流程
app相关的处理能力(以前的数据,用于对比)
问题出现时,多了解周边情况(cpu,io,外围),记录现状
对thread状态进行分类,业务分布情况,资源等待情况(细化)
如有必要,获取heapdump分析(oom)

javacore经常和heapdump联系在一起，有时候也一起出现。这里简单对两个文件进行对比，希望大家有个印象：