headdump 内存分析。

 

1         编写目的

Ø  最近系统中频繁的内存中占用一直偏高，指望找出内存中那些对象是调用过于频繁，或者大对象没有被即便回收的，可能会致使内存泄漏的。

Ø  在系统在内存在一直快速增长，分析照成这个问题的缘由

Ø  GC过于频繁。

2         GC 日志资料

显而易见，这里是cms回收机制，在咱们系统中在系统内存使用率68%时执行gc 但这个gc 过于频繁，有理由怀疑，在内存累加过程当中，多是应为程序致使的问题。全部有咱们去分析内存日志。

3         使用memory analysis分析内存

Memory analysis 可使用内存分析器来分析生产与数亿对象堆转储,快速计算保留对象的大小,看看谁是阻止垃圾收集器收集对象,自动运行报告提取泄漏疑点

3.1.1            开始获取Jvmdump 文件

3.1.1.1        使用jmap 生成堆信息

3.1.1.2        使用插件生成

在eclipse 中 fileà Acquire Heap Dump

 

 

 

3.1.1.3 在启动文件中配置虚拟机参数当系统在OutOfMemoryError 时自动生成堆的

 

在启动文件中配置虚拟机参数： -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/home/eim/heap

3.1.2            导入生产的jvmheap 文件

Eclipse –> open file 指定jvmheap 文件

进入首页：

3.1.3            Histogram

经过精确计算 retained  heap 中的各个对象占用的大小，这个计算会稍微慢些。

 

 

上面是经过对象的建立次数进行的一次排序， 很明显在圈里面的对象都是一些被引用的数据，被引用到的数据，当前信息是堆中的信息，而后咱们看代码中的建立对象和队中的占用内存大小。经过咱们的包进行一次过滤可得出下图

 

在上图中经过shallow heap 和 retained heap 比较可得 注:  shallow heap 是当前对象自己占用的内存大小， retained heap 是包括对象的全部引用以后所占用的内存大小。这上图中分析，根据咱们系统中的代码分析的对象： 其中 JEUser ， PersonalVCard，TenementMember,TenmenetVCard,JETenement,JeDepartement,UserMetas 这些对象一直保持缓存和数据库同步，若是用户信息，和企业信息 在不常常变更的状况下， 这些对象的占用内存的大小应该是比较稳定的。 不可照成内存快速增长的情况。而后咱们预测FDFSVirtualFile 和对象 SubscribeMapperManager 两个对象是否存在某种程序中设计不合理。在跟踪代码可发如今这个对象中存在的对象属性，以下图

带着这个对象中的属性，去查看是不是当前属性中的某个引用占了大份数据。

 

3.1.4             Leak Suspects

 

 

分析内存可能致使内存泄漏的缘由。 在系统中存在的数据量最多的CacheWrapper 这个是正常的，但在这个数据的大小不太合理，这个须要经过详细信息来分析， 在CacheWrapper 中可能致使的这么大数据的缘由。从前文很容易得出一个结论， 如今在内存中不是应为对象建立的太多而致使的内存一直增加，而是由于内存中的对象为大对象不断的建立大对象致使的，那咱们来看累积最大的对象，所映射的是哪些对象。 以下图操做。

 

 

如上图所示，如今已经有理由去怀疑这个对象的使用确实在程序中存在问题。在FDFSVirtualFile这个属性attributes 经过代码跟踪，存储的都是一些图片的二进制。 在系统中的全部的图片，的大图中图小图信息。

 

参考资料：

http://eclipsesource.com/blogs/2013/01/21/10-tips-for-using-the-eclipse-memory-analyzer/