关于GC outofMemory的离线分析

分析工具

一般，我们一提到GC的问题，立即想到的是，如何使用那几个已知的工具来进行在线的分析，大多数都会说到如何设置参数，让GC日志打印，或者是使用visualVM、Jprofiler等工具来进行在线的GC监控。

但如果线上环境与开发环境是隔的情况下，就只能执行离线分析，特别是在GC发生以后，Jvm会将GC的内存dump出来到一个指定的目录中（或者这个步骤需要人为的去设置），这时候需要执行对Dump的内存进行分析，一般内存都会上G，多的有十几个G。

当我遇到的时候，首先将dump文件下载到本地，然后使用visualVM将其打开（在windows及linux下都可以执行）。对于hotspot内存来说（oracle jdk)以hprof结尾，选择的时候下拉文件中选择以其结尾的文件名就可以打开了。打开的时候，在windows下，如果是机械硬盘，打开时间会有10分钟以上，同样，在分析的时候，时间也需要较长的时间，直白的说，每一步都很卡。所以推荐使用mac book pro来进行分析，这样会节省好多的时间精力（估计要是研究的话会省下一天多的时间），一点迟滞感也没有，不是做广告，真是很快。所以在这里也说一句，研发的，一定要有一个macbook pro来用，效率提高的不是一点半点。话说，我在写这个文章的开始就在windows的联想小新（V4000，i7,8G内存）上打开visualVM，并开始加载dump文件，我码字都码到这里了，它依然在加载，你说~~~，吐槽一下，都20分钟了，还没有加载完成，你说这个破本，是不是应该摔了？如果让你用这个破玩意分析，你说你恼火不？

书回正文，打开的结果

图中标红的部门是泄漏的内存，可以双击，切到到Instance视图去查看内容是什么。这一步还是很耗时的。

关键的部分，其实是在summary标签，在那里会有一个出现异常的连接的线程链接，可以点击，一下就跳到出异常的方法，并显示了当时GC时的调用关系，然后与泄漏的内存内容相互印证一下，基本就可以肯定是这个方法了，然后分析泄漏的原因吧。

走过的弯路是使用ibm的heapAnalyzer一下就进入内存中的细节去了，结果分析不出来所以然，他提供的suspect方法也是莫名其妙，不准确，以后再研究一下，看如何与visualVM相互对比着分析heap吧。

其实，关于内存泄漏的分析，为了快速解决问题，我也找人帮忙了。其实自己该做的都做了，只是不够细心，不够有耐心。好多事情都是这样，现在都屈从于时间了。