jvm内存溢出溯源

1.先上神器

2.远程监控配置

JProfile是一款性能瓶颈分析工具，具体要干啥呢下面看

1：创建一个监控任务 

2：选择tomcat版本 

3：监控远程服务器 

 4：选择oracle 1.5.0 

 5：填写需要监控的服务器地址 

 6：填写待监控的服务器下的tomcat/bin目录地址 

 7：startup.sh 路径 

8：端口默认8849 

 9：选择稍后启动客户端，会把刚刚的操作保存下来暂时不启动 

 10：之后会在你的目录下生成一个startup_jprofiler.sh 文件

 

 11：将startup_jprofiler.sh 文件 拷贝到tomcat的bin目录下

 

 12：启动这个脚本 ./startup_jprofiler.sh ，看到下面这个命令就是启动成功了，正在等待连接你本地的客户端

 

 13：修改一下我们的客户端配置

 

 14：将keep VMalive勾选上，否则会报错 

 15：启动客户端，可以看到正在监控服务器 

3.演示内存溢出场景，及工具使用

代码仓库地址：https://gitee.com/zsiyang/jvm_test.git

虚拟机参数设置如下：（演示用）

-Xms500m -Xmx500m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=C:\Users\pc-3356\Desktop\sql

• 选择Live memory菜单查看当前jvm加载类对象
• 工具栏选择 Mark Current 查看实时增长

  为了便于比较内存的增长情况，可以点击”Mark Current”按钮，来将当前内存使用情况作为参照，点击后会显示“Difference”列，该列会列出对象数量的变化和变化比率；

然后我们发起http请求模拟内存溢出

GET http://localhost:8080/test/jvm

• 现在观察Live memory 和Telemetries  查看内存及类增长进行分析

利用对象视图找出内存泄漏原因

大多数的内存泄漏可以被追溯到对象集群。这将产生一些大的retained size的对象。最大的对象视图列出了带有最大retained size的对象。你可以利用该树形向下钻取从而发现错误引用。

使用参考图找到内存泄漏的原因

找出内存泄漏的核心工具是堆遍历器中的参考图。依次打开传入引用，你可能会立即发现一个错误引用。在复杂的系统中，这往往是不可能的。在这种情况下，你必须要找到一个或多个”garbage collector roots”。Garbage collector roots是JVM中的点，不受垃圾回收机制的约束。当你选择了传入引用或图形中的一个对象时，顶部的[Show path to GC root] 按钮被启用。

garbage collector roots非常多，若全部显示它们，可能会造成大量堆积，如图所示。此外，查找garbage collector roots也很耗时。 如果找到成千上万的roots，计算的时间很长而且会占用大量内存。为了防止这些问题，最好开始时从单个garbage collector root 开始查找，然后根据利用 UP to roots 根据需要慢慢增加garbage collector root。

garbage collector root 的链条可以很长，如图所示：

使用cumulated references views以查找内存泄漏的原因

在某些情况下，您可能无法成功地缩小对象设置的规模。你的对象集中可能仍包含了大量的实例或者在此情况下，使用参考图不可能会提供任何见解。这时，堆遍历器的引用视图中的 the cumulated reference tables 就可排上用场了。cumulated incoming reference table显示了当前对象集中所有可能的引用类型：

从引用类型中，你就可以缩小对象集。例如，您可能知道那些引用类型是正常的，那些是不正常的。