JVM内存分析工具使用

Java 内存堆栈分析，是我们在分析线上问题常用的手段。线上会遇到一些问题从日志上无法分析的疑难问题。我们可以分析一些JVM内存，来看看问题到底出在哪里了。在生产环境上一般不允许我们使用一些例如JMX或是JProfile(我也是刚刚了解到)这类的工具。这类工具通常使用在开发测试中解决性能瓶颈和理解问题用到。今天我介绍一下我用过的一些工具，他们都不是在线分析工具，都需要先收集JVM内存消息导入到文件中，然后我们再分析。我主要介绍一下用法，因为分析的过程，是根据现网现象结合dump消息综合思考的过程，这个我也再学习中，目前没有一个系统的概念。

分析栈内存（stack）：jstack/kill -3 + IBM Thread and Monitor Dump Analyzer for Java （点击下载）

分析堆内存(heap)： jmap + jhat。

我们通常是从栈信息入手来进行分析。下面我详细介绍一下他们具体是使用方法：jstack是java自带的一个分析工具，我们可以在java的安装目录找到：$JAVA_HOME/bin 中找到。kill -3和jstack效果一样，只不过他会将栈信息打印到tomcat的catalina.out 文件中去。

使用方法在命令的usage里面的介绍非常明确了，我就不去介绍啦。我这里举个例子：

1. 我们先查询一下java进程，因为jstack要根据java进程号来打印stack信息：javaps -ef|grep java

2. 找到进程pid之后，将stack信息记录到stack.out文件中： jstack -l 31155 > stack.out

3. 我们再用IBM Thread and Monitor Dump Analyzer for Java这个工具来分析。这里可以清晰的看到线程数状态统计，和每个线程的状态。

具体的分析方法我们可以看看这篇文章。http://jameswxx.iteye.com/blog/1041173

jmap + jhat。这个两个命令也是java自带的，在$JAVA_HOME/bin中你也可以找到他们两个。基本使用方法是：

1. 先打印heap信息：jmap -dump:live,format=b,file=heap.bin 注意这个文件一般会很大。要看应用服务。

2. 使用jhat分析：jhat -J-mx1024M heap.bin 这个命令会启动一个Server服务，默认的端口是7000。其中-mx是设置最大使用多少内存，如果你要分析的heap文件很大的话，这个值要配置很大，不然会包内存异常的错误。

我们主要看这个两个部分：Show instance counts for all classes (excluding platform)Show heap histogram平台外的对象信息，和对象heap树状图，这个树状图包括所有对象的个数已经占有大小，占用的大小是bytes。

我在以前处理现网问题是时候，用到过一次。我们在巡检的时候发现，有个服务(Tomcat服务)在一个月前就不上报自己的状态给管理台了，我让一线维护查询这个Tomcat是不是就没启动：

    ps -ef|grep java

根据一线的反馈，这个Tomcat的进程还在，应该是启动的，但是为什么不上报自己的状态呢？我们又让一线反馈一下这个服务的监控页面（能查询JDBC连接字符串，打印Spring Bean，打印一些和数据库同步的业务参数）是否显示正常，结果发现这个页面一直无法打开，浏览器一直处于缓冲的那种状态。这下90%可以确定Tomcat僵死了。

分析一下问题根因。先让一线反馈jstack消息，我们没有发现什么问题。后来又让他们反馈jmap消息，这个文件打印出来会很大（900M~2G）根据我们配置的JVM内存参数来定的，不过好的是压缩比很大，RAR压缩一下就几兆了。所以jmap命令会非常消耗服务器IO性能，一般不要在业务高峰用。我们用jhat分析map打印的heap消息发现，有个平台外的HTTP连接实例被创建了2百多万个，一直没有被释放掉。这个应该就是问题的原因啦。经过定位发现根因，应该是一线在开局实施的时候，修改了Tomcat里面web.xml中的session-timeout参数，将他改成了555555，也就是说session超时时间是555555分钟。