JVM-性能调优-GUI篇

       JDK提供了一些内存泄漏的分析工具，如jconsole，jvisualvm等，用于辅助开发人员定位问题，但是这些工具很多时候并不足以满足快速定位的需求。下面介绍几款功能相对多一些、丰富一些。

图形化综合诊断工具

JDK自带的工具

官方文档：https://docs.oracle.com/javase/7/docs/technotes/guides/management/
1.jconsole：JDK自带的可视化监控工具。查看Java应用程序的运行概况、监控堆信息、永久区（或元空间）使用情况、类加载情况等。
位置：jdk\bin\jconsole.exe

2.Visual VM：是一个工具，它提供了一个可视界面，用于查看Java虚拟机上运行的基于Java技术的应用程序的详细信息。基本替代了jconsole。自带中最强大的，要掌握。
位置：jdk\bin\jvisualvm.exe

Visual VM 的一大特点是支持插件拓展，并且插件安装非常方便。我们既可以通过离线下载插件文件*.nbm，然后在Plugin对话框的已下载页面下，添加已下载的插件。也可以在可用插件页面下，在线安装插件。这里建议安装上：VisualGC。

插件地址：https://visualvm.github.io/pluginscenters.html

远程连接的步骤：
A.确定远程服务器的ip地址
B.添加JMX(通过JMX技术具体监控远端服务器那个Java进程)
C.修改bin/catalina.sh文件，连接远程的tomcat
D.在…/conf中添加jmxremote.access和jmxremote.password文件
E.将服务器地址改为公网ip地址
F.设置阿里云安全策略和防火墙策略
G.启动tomcat,查看tomcat启动日志和端口号监听
H.JXM中输入端口号、用户名、密码登录

3.JMC：Java Mission Control， 内置Java Flight Recorder。能够以极低的性能开销收集Java虚拟机的性能数据。
位置：jdk\bin\jmc.exe

第三方工具

1.MAT(Memory Analyzer Tool)：是基于Eclipse的内存分析工具，是一个快速、功能丰富得多Java heap分析工具，它可以帮助我们查找内存泄漏和减少内存消耗。
位置：Eclipse的插件形式

分析堆文件：
A.histogram：展示了各个类的实例数目以及这些实例的shallow heap 或 retainedheap的总和
B.thread overview：查看系统中的Java线程、查看局部变量的信息
C.获得对象相互引用的关系：with outgoing references\ with incoming references
D.浅堆与深堆：
shallow heap：

retained heap：

对象的实际大小：

E.支配树

2.JProfiler：商业软件，需要付费，功能强大。

3.Arthas：Alibaba开源的Java诊断工具，深受开发者喜爱。
官网：https://arthas.aliyun.com/zh-cn/

4.Btrace：Java运行时追踪工具，可以在不停机的情况下，跟踪指定的方法调用、构造函数调用和系统内存等信息。

dump文件内容

通过分析dump文件可以获得内内存信息：
1.所有的对象信息，包括对象实例、成员变量、存储于栈中的基本类型值和存储于堆中的其他对象的引用值。
2.所有的类信息，包括classcloader、类名称、父类、静态变量等。
3.GCRoot到所有的这些对象的引用路径。
4.线程信息，包括线程的调用栈以及此线程的线程局部变量(TLS)。

获取dump文件

方法一：通过jmap工具生成，可以生成任意一个java进程的dump文件

方法二：通过配置JVM参数生成
选项"-XX:+HeapDumpOnOutOfMemoryError" 或 “-XX:+HeapDumpBeforeFullGC”
选项"-XX:HeapDumpPath"所代表的含义就是当程序出现OutOfMemory时，将会在相应的目录下生成一份dump文件。如果不知道选项"-XX:HeapDumpPath"则在当前目录下生成dump文件。

对比：考虑到生产环境中几乎不可能在线对其进行分析，大都是采用离线分析，因此使用jmap+MAT工具是最常见的组合。

方法三：使用VisualVM可以导出堆dump文件

方法四：使用MAT既可以打开一个已有的堆快照，也可以通过MAT直接从活动Java程序中导出堆快照。该功能将借助jps列出当前正在运行的Java进程，以供选择并获取快照。

内存泄漏的理解与分类

可达性分析算法来判断对象是否是不再使用的对象，本质都是判断一个对象是否还被引用。那么对于这种情况下，由于代码的实现不同就会出现很多种内存泄漏问题（让JVM误以为此对象还在引用中，无法回收，造成内存泄漏）。

是否还被使用？是
是否还被需要？否

理解

严格来说，只有对象不会再被程序用到了，但是GC又不能回收他们的情况，才叫内存泄漏。但实际情况很多时候一些不太好的实践（或疏忽）会导致对象的生命周期变得很长甚至导致OOM，也可以叫做宽泛意义上的“内存泄漏”。

内存泄漏与内存溢出的关系

1.内存泄漏（memory leak）
申请 了内存用完了不释放，比如一共有1024M的内存，分配了512M的内存一直不回收，那么可以用的内存只有512M了，仿佛泄漏掉了一部分；
通俗一点讲的话，内存泄漏就是【占着茅坑不拉屎】

2.内存溢出（out of memory）
申请内存时，没有足够的内存可以使用；
通俗一点儿讲，一个测试就三个坑，有两个占着茅坑不走的（内存泄漏），剩下最后一个坑，厕所表示接待压力很大，这时候一下子来了两个人，坑位（内存）就不够了，内存泄漏变成了内存溢出了。

可见，内存泄漏和内存溢出的关系：内存泄漏的增多，最终会导致内存溢出。

泄漏的分类

经常发生：发生内存泄漏的代码会被多次执行，每次执行，泄漏一块内存。
偶然发生：在某些特定情况下会发生。
一次性：发生内存泄漏的方法只会执行一次。
隐式泄漏：一直占着内存不释放，直到执行结束，严格的说这个不算内存泄漏，因为最终释放掉了，但是如果执行时间特别长，也可能会导致内存耗尽。

java中内存泄漏的8种情况

1.静态集合类

静态集合类，如HashMap、linkedList等等。如果这些容器为静态的，那么它们的生命周期与JVM程序一致，则容器中的对象在程序结束之前将不能被释放，从而造成内存泄漏。简单而言，长生命周期的对象持有短生命周期对象的引用，尽管短生命周期的对象不再使用，但是因为长生命周期对象持有它的引用而导致不能被回收。

public class MemoryLeak{
	static List list = new ArrayList();
	public void oomTests(){
		//局部变量
		Object obj = new Object();
		//虽然是局部变量，但是依然被静态集合引用，出了方法依然无法回收
		list.add(obj);
	}
}

2.单例模式

单例模式，和静态集合导致内存泄漏的原因类似，因为单例的静态特性，它的生命周期和JVM的生命周期一样长，所以单例对象如果持有外部对象的引用，那么这个外部对象也不会被回收，那么就会造成内存泄漏。

3.内部类持有外部类

内部类持有外部类，如果一个外部类的实例对象的方法返回了一个内部类的实例对象。
这个内部类对象被长期引用了，即时那个外部类实例对象不再被使用，但由于内部类持有外部类的实例对象，这个外部类对象将不会被垃圾回收，这也会造成内存泄漏。

4.各种连接，如数据库连接、网络连接和IO连接等

在对数据进行操作的过程中，首先需要建立与数据库得到连接，当不再使用时，需要调用close方法来释放与数据库的连接。只有这样连接被关闭后，垃圾回收器才会回收对应的对象。
否则，如果在访问数据库的过程中，对Connection、Statement或ResultSet不显性地关闭，将会造成大量的对象无法被回收，从而引起内存泄漏。

5.变量不合理的作用域

变量不合理的作用域，一般而言，一个变量的定义的作用域大于其使用范围，很有可能会造成内存泄漏。另一方面，如果没有及时地把对象设置为null，很有可能导致内存泄漏的发生。

public class UsingRandom{
	private String msg;
	public void receiveMsg(){
		//private String msg;
		readFromNet(); //从网络中接受数据保存到msg中
		saveDB(); // 把msg保存到数据库中
		//msg = null;
	}
}

如上面的伪代码，通过readFromNet()方法吧接受的信息保存在变量msg中，然后调用saveDB()方法把msg的内存保存到数据库中，此时msg已经就没用了，由于msg的生命周期与对象的生命周期相同，此时msg还不能回收，因此造成了内存泄漏。

实际上这个msg变量可以放在receiveMsg方法内部，当方法使用完，那么msg的生命周期也就结束，此时就可以回收了。还有一种方法，在使用完msg后，把msg设置为null，这样垃圾回收器也会回收。

6.改变哈希值

当一个对象被存储进HashSet集合以后，就不能修改这个对象中的那些参与计算哈希值额的字段了。
否则，对象修改后的哈希值与最初存储进HashSet集合中的哈希值就不同了，在这种情况下，即使在contains()方法使用该对象的当前引用作为的参数去HashSet集合中检索对象，也将返回找不到对象的结果，这也会导致无法从HashSet集合中单独删除当前对象，造成内存泄漏。

这也是String为什么被设置成了不可变类型，我们可以放心地把String存入HashSet，或者把String当做HashMap的key值。

当我们想把自定义的类保存到散列表的时候，需要保证对象的hashcode不可变。

7.缓存泄漏

内存泄漏的另一个常见来源是缓存，一旦你把对象引用放入到缓存中，他就很容易遗忘。比如：之前项目在一次上线的时候，应用启动奇慢直到宕机，就是因为代码中会加重一个表中的数据到缓存中，测试环境只有几百条数据，但是生产环境有几百万的数据。

对于这个问题，可以使用WeakHashMap代表缓存，此种Map的特点是，当除了自身有对key的引用外，此key没有其他引用那么此map会自动丢弃此值。

8.监听器和回调

内存泄漏第三方常见来源是监听器和其他回调，如果客户端在你实现的API中注册回调，却没有显示的取消，那么就会积聚。
需要确保回调立即被当作垃圾回收的最佳方法是只保存它的弱引用，例如将他们保存成为WeakHashMap中的健。

支持使用OOL语言查询对象信息