通过jvisualvm分析内存泄漏

到jdk的目录下的bin下执行jvisualvm
image-20200102172300724

进去之后,如图

image-20200102174201009

上面是有visual GC这个工具的,但是真实的我刚打开的时候是没有的,需要:

image-20200102174237257

找到希望安装的插件进行安装,因为visual GC这个插件我已经安装过了所以在已安装里面

image-20200102174259160

这里我们再安装下VisualVM-JConsole这个插件

然后关掉原来的窗口,再次启动

image-20200102174444008

因为看效果比较慢,所以 java -Xmx201k -Xmn200k -jar nanjing_jvm_demo-1.0-SNAPSHOT.jar
这里将虚拟机可用内存设小一点,然后年轻代设置大一点,年老代自然就小了。

image-20200102223108562

通过下图发现,年老代,发生了6次,但是年老代还是持续增长的,说明存在无法被回收的对象,可能是内存泄漏了。

这个时候看抽样器

image-20200102230551689

NanJing28Suo果然是最大的,正如我们的Demo中的
点击dump堆

image-20200102231758860

过一段时间再dump一次(当然了我demo中就是最大10000,这样不同的时间间隔是没有变化的,在缓慢增长的时候dump两次能够看出变化)

image-20200102231846284

这个时候左边出现了两个dump文件,点击任意的一个dump文件,与另一个比较

image-20200102231935102

刚才说了,因为我的demo实例已经到达上限,所以下图是没有变化的,真实场景是能看到类的缓慢增长的,时间有限,这里就不演示了

image-20200102232020370

下面是网上的有增长的图

img

而我们上面知道最消耗内存的是NanJing28Suo这个类,所以

image-20200102232131557

image-20200102232231793

image-20200102232325760

可以看到左边是实例,右边是他的引用,谁持有引用?最后终于定位到了ArraList

https://www.cnblogs.com/shangxiaofei/articles/10867908.html

https://www.cnblogs.com/liululee/p/11056779.html