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显示了当前对象集中所有可能的引用类型：
从引用类型中，你就可以缩小对象集。例如，您可能知道那些引用类型是正常的，那些是不正常的。
