到jdk的目录下的bin下执行jvisualvm
进去之后,如图

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

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

这里我们再安装下VisualVM-JConsole这个插件
然后关掉原来的窗口,再次启动

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

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

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

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

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

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

下面是网上的有增长的图

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



可以看到左边是实例,右边是他的引用,谁持有引用?最后终于定位到了ArraList
https://www.cnblogs.com/shangxiaofei/articles/10867908.html
https://www.cnblogs.com/liululee/p/11056779.html
本文介绍了如何通过jvisualvm工具分析内存泄漏问题。首先启动jvisualvm并安装VisualVM-JConsole插件,接着调整Java应用的内存配置以加速问题显现。观察到老年代内存持续增长,通过抽样器定位到疑似泄漏的NanJing28Suo类,进一步通过dump堆快照对比找出内存增长的实例和引用,最终发现ArrayList持有该类的引用,从而定位到内存泄漏源头。
1万+

被折叠的 条评论
为什么被折叠?



