IBM WebSphere Javacore分析

今天公司的服务器宕机了，抛出很多的javacore 文件，这个文件比较好分析，下面我们讲一下什么是javacore ，以及如何通过分析javaCore文件找出问题。

参考 http://zhangzhiqiangli.blog.163.com/blog/static/459183842012715111949106/

一、什么是Javacore？

Javacore是Java应用程序在某一时间的文本表示形式，也可理解为Java Dump（通常称为Thread Dump）的线程转储文件。该文件记录了整个JVM的运行情况，包含线程、垃圾回收、JVM运行参数、内存地址等信息。JVM的许多问题都可以用这个文件进行诊断，其中比较典型的包括线程阻塞、CPU使用率过高、JVM Crash、堆内存不足和类装载等问题。

Javacore文件通常以*.txt方式显示，名称格式主要是以Javacore为头，加上日期号、产生的时间号、当时的线程编号，如: Javacore.20100719.003424.299228.txt.

我们可以通过以下几种方式获取Javacore：

1. 向操作系统发送一个中止的signal

http://blog.csdn.net/happyqwz/article/details/8255762

2. 在Java的执行代码中使用JavaDump（）方法

com.ibm.jvm.Dump.JavaDump（） 方法促使JVM dump

发布ProblemDiagnosticsLabToolkit应用包，通过可视化页面直接生成相关文件。

3. 系统在异常时自动抛出

? 一个严重的本地调用出错（非Java的异常）

? JVM堆的大小被使用完了

? OutOfMemory 错误

二、Javacore描述了什么内容？

在Javacore文件的帮助下，我们就可以更好地分析系统运行情况，在系统出现死锁，或者内部错误、中间件等问题时，我们都可以通过Javacore进一步深入分析。我们可以在Javacore文件里找到以下相关信息：

? JVM的参数启动参数、Jdk版本

? JVM堆大小

? JVM产生原因、产生时间（可手动获取，可系统抛出）

? 全局垃圾回收次数、分配失败次数、内存溢出时，最后一次详细的垃圾回收记录

? JVM堆内存地址信息

? JVM中，所有线程执行情况（包含应用程序内部执行线程，容器线程，垃圾回收线程，定时线程，线程池线程，页面请求转发线程等多种线程信息）

? 已装载入JVM中的类的信息

如下表：

 

序号	描述	例子
1	? JAVA产生的原因 ? 产生时间 ? 产生的线程号 ? JDK版本 ? JVM堆大小 ? 空间堆大小 ? 已分配的堆大小
2	JVM堆对象占用比例信息
3	整体线程的状态，各占比例情况
4	主要线程类型与其线程数，及在整个容器中所占用的比例
5	其他相关信息	……

三、如何分析Javacore？

我们可以通过Javacore提供的信息对JVM进行一个全面的分析，除了了解垃圾回收情况、JVM相关配置信息外，分析重点可放在线程执行情况上，分析哪些线程在等待，哪些在执行，以便快速缩小问题范围。

（打开Javacore文件，庞大的字符串使得我们查找信息十分不便，此时我们可以利用IBM Thread and Monitor Dump Analyzer for Java工具分析，该工具可以让我们清晰的分析Javacore文件）。

在IBM Thread and Monitor Dump Analyzer for Java工具中，请求线程可分为以下几种状态：

? 死锁，Deadlock（重点关注）

? 执行中，Runnable（重点关注）

? 等待资源，Waiting on condition（重点关注）

? 等待监控器检查资源，Waiting on monitor

? 暂停，Suspended

? 对象等待中，Object.wait()

? 阻塞，Blocked（重点关注）

? 停止，Parked

在整个分析过程中，我们需要根据问题分析线程的运行的情况（如该Javacore是什么时候生成的，是内存溢出，还是系统繁忙时），查看不同状态的线程的执行堆栈，分析堆栈找到其中属于系统应用的代码可进一步缩小问题点（在版本稳定的中间件里，我们分析问题一般先从应用代码入手，了解是哪些业务代码触发了问题）。我们要了解线程状态具体的意思，线程中的堆栈代码，整个容器的各个类型线程的情况，结合这些信息进行深入的分析。

ü Deadlock：死锁线程，一般指多个线程调用间，进入相互资源占用，导致一直等待无法释放的情况。

ü Runnable：一般指该线程正在执行状态中，该线程占用了资源，正在处理某个请求，有可能正在传递SQL到数据库执行，有可能在对某个文件操作，有可能进行数据类型等转换。

ü Waiting on condition：等待资源，如果堆栈信息明确是应用代码，则证明该线程正在等待资源，一般是大量读取某资源，且该资源采用了资源锁的情况下，线程进入等待状态，等待资源的读取。又或者，正在等待其他线程的执行等。

ü Blocked：线程阻塞，是指当前线程执行过程中，所需要的资源长时间等待却一直未能获取到，被容器的线程管理器标识为阻塞状态，可以理解为等待资源超时的线程。这种情况在was的日志中，一般可以看到CPU饥渴，或者某线程已执行了XX秒的信息。

在了解了以上线程状态的具体意思后，我们就可以结合这些信息更进一步分析线程问题。

在内存溢出时，分析Javacore文件中的线程内容，可以采用自下而上的分析方法。首先查看有多少线程被设置了Blocked状态，这些线程是在执行什么请求，并且到了堆栈最后一步在等待什么资源，将其分类记录下来；查找到这些Blocked线程等待的执行线程编号，在Javacore中，继续查找该线程，分析其堆栈与状态与监控器的记录的信息。一般这些线程会处于Waiting on condition状态，因为这些线程也是因为资源迟迟未获取到或者执行时间过长一直处于等待状体，进一步导致队列中其他需要访问这些资源的线程都被设置为Blocked状态。在找到线程后，我们就可以初步将问题缩小到哪些业务应用请求存在问题，是哪一个类与哪一行代码，其等待的资源是什么。结合这些信息详细分析业务代码，或者根据这些问题到IBM网站中，查找对应版本的中间件是否存在同样的问题，如有，则可以考虑打补丁升级。

一个Javacore描述的是在一个时间片段中的JVM的运行情况，这些信息相对来说是有限的，为了更进一步分析与定位问题，我们可以采集连续多个时间片段的Javacore，如间隔30秒或者几分钟的Javacore。分别对这些Javacore进行分析，以求更加清晰JVM在该时间段内的运行情况，或者出现阻塞问题的线程及其相关线程的的执行情况，从而准确定位问题。

在整个性能优化过程中，学会如何分析Javacore是十分关键的一步。通过切面，对JVM中所运行的线程及堆栈进行全面分析，可以让我们顺利而有方向性地开展性能调优工作，并使优化工作更加简单快捷。

 

然后采用jca分析工具，我采用的是jca401的版本，进入dos环境，执行：

java -Xmx200m -jar jca401.jar

会打开图形界面，调入javacore文件，进行分析发现有线程处于blocked状态，点击toolbar中的“Thread Detail”图标，能够看到具体的线程状态及明细，定位blocked的线程，查看明细，本例中发现该线程blocked by一个QuartzScheduler线程，该线程的调用堆栈如下：

而且还发现大量waiting on condition

都是quartz在等待。基本确定是定时器除了问题。

最后发现是定时器的配置文件没改，无法连接到数据库，而且设置的超时时间过长。