java内存泄漏的定位与分析(二)

如果为了更好的证明FGC对服务器性能的影响，我们可以使用java visualVM来查看一下：

从上图可以发现执行FGC的情况，下午3:10分之前是没有FGC的，之后出现大量的FGC。

上图是jvm堆内存的使用情况，下午3:10分之前的内存回收还是比较合理，但是之后大量内存无法回收，最后导致内存越来越少，导致大量的full gc。

下面我们在看看大量full GC 对服务器性能的影响，下面是我用loadrunner对我们项目进行压力测试相应时间的截图：

从图中可以发现有，在进行full GC 后系统的相应时间有了明显的增加，点击率和吞吐量也有了明显的下降。所以java内存泄漏对系统性能的影响是不可忽视的。

3、定位内存泄漏

当然通过上面几种方法我们可以发现java的内存泄漏问题，但是作为一名合格的高级工程师，肯定不甘心就把这样的结论交给开发，当然这也的结论交给开发，开发也很难定位问题，为了更好的提供自己在公司的地位，我们必须给开发工程师提供更深入的测试结论，下面就来认识一下MemoryAnalyzer.exe。java内存泄漏检查工具利器。

首先我们必须对jvm的堆内存进行dump，只有拿到这个文件我们才能分析出jvm堆内存中到底存了些什么内容，到底在做什么？

MemoryAnalyzer的用户我在这里就不一一说明了，我的博客里也有说明，下面就展示我测试的成功图：

其中深蓝色的部分就为内存泄漏的部分，java的堆内存一共只有481.5M而内存泄漏的部分独自占有了336.2M所以本次的内存泄漏很明显，那么我就来看看那个方法导致的内存泄漏：

从上图我们可以发现红线圈着的方法占用了堆内存的67.75%，如果能把这个测试结果交给开发，开发是不是应该很好定位呢。所以作为一名高级测试工程师，我们需要学习的东西太多。

本人刚刚完成了云存储架构师的 培训学习（包括了linux的内核了解、 shell的高级 编程、linux安全的学习重点iptables和tcp/ip等各种协议的抓包分析、linux的集群、性能调优等接下来还有dba的课程等待着我挑战）。