headdump 内存分析。

摘要: memory analysis

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/