Back
Java

JVM笔记之引用、GC及OOM

强引用、软引用、弱引用和虚引用

强引用（Strong Reference） 只有这个引用被释放之后，对象才会被释放掉。只要引用存在，垃圾回收器永远不会回收。

我们平常典型编码Object obj = new Object()中的obj就是强引用。通过关键字new创建的对象所关联的引用就是强引用。
当JVM内存空间不足，JVM宁愿抛出OutOfMemoryError运行时错误（OOM），使程序异常终止，也不会靠随意回收具有强引用的“存活”对象来解决内存不足的问题。
对于一个普通的对象，如果没有其他的引用关系，只要超过了引用的作用域或者显式地将相应（强）引用赋值为 null，就是可以被垃圾收集的了， 具体回收时机还是要看垃圾收集策略。

软引用（Soft Reference） 内存溢出之前通过代码回收的引用。 通常用来实现内存敏感的缓存（图片缓存框架中，“内存缓存”中的图片是以这种引用来保存）。
软引用主要用户实现类似缓存的功能，在内存足够的情况下直接通过软引用取值，无需从繁忙的真实来源查询数据，提升速度； 当内存不足时，JVM 会确保在抛出 OutOfMemoryError 之前，清理软引用指向的对象，自动删除这部分缓存数据，从真正的来源查询这些数据。

弱引用（Weak Reference） 第二次垃圾回收时回收的引用，短时间内通过弱引用取对应的数据，可以取到，当执行过第二次垃圾回收时，将返回null。 同样可用于内存敏感的缓存（在静态内部类中，经常会使用虚引用。例如，一个类发送网络请求，承担callback的静态内部类，则常以虚引用的方式来保存外部类(宿主类)的引用，当外部类需要被JVM回收时，不会因为网络请求没有及时回来，导致外部类不能被回收，引起内存泄漏）
弱引用主要用于监控对象是否已经被垃圾回收器标记为即将回收的垃圾，可以通过弱引用的isEnQueued方法返回对象是否被垃圾回收器标记。

虚引用（Phantom Reference) 又称幽灵引用或幻影引用，虚引用既不会影响对象的生命周期，也无法通过虚引用来获取对象实例的任何属性或函数。
可用来跟踪对象被垃圾回收器回收的活动，当一个虚引用关联的对象被垃圾收集器回收之前会收到一条系统通知。
当一个对象的finalize方法已经被调用了之后，这个对象的幽灵引用会被加入到队列中。通过检查该队列里面的内容就知道一个对象是不是已经准备要被回收了。
虚引用和软引用弱引用都不同,它会在内存没有清理的时候被加入引用队列.虚引用的建立必须要传入引用队列,其他可以没有

Java内存回收机制

不论哪种语言的内存分配方式，都需要返回所分配内存的真实地址，也就是返回一个指针到内存块的首地址。

Java中对象是采用new或者反射的方法创建的，这些对象的创建都是在堆（Heap）中分配的，所有对象的回收都是由Java虚拟机通过垃圾回收机制完成的。GC为了能够正确释放对象，会监控每个对象的运行状况，对他们的申请、引用、被引用、赋值等状况进行监控，Java会使用有向图的方法进行管理内存，实时监控对象是否可以达到，如果不可到达，则就将其回收，这样也可以消除引用循环的问题。

在Java语言中，判断一个内存空间是否符合垃圾收集标准有两个：一个是给对象赋予了空值null，另一个是给对象赋予了新值，这样重新分配了内存空间。

GC算法分类

  1. 引用计数法(没有被java采⽤用)
  2. 标记清除法（通过根节点标记所有从根节点开始的可达对象，清除没标记过的对象，标记和清除两个过程效率不高，产生内存碎⽚）
  3. 标记压缩法（压缩：将所有存活对象压缩到内存的一端，清除边界外所有的空间）
  4. 复制回收算法
  5. 分代回收法（根据对象存活周期的不同将内存划分几块，一般是新生代和老年代，新⽣代基本采用复制算法，老年代采⽤用标记清除算法。

MinorGC & FullGC

  1. Minor GC通常发生在新生代的Eden区，一般采用复制回收算法（对象生存期短，发生GC的频率较高，回收速度比较快）。
  2. Full GC/Major GC 发生在老年代，所采用的是标记清除算法。

内存泄漏

内存泄漏是指无用对象（不再使用的对象）持续占有内存或无用对象的内存得不到及时释放，从而造成内存空间的浪费称为内存泄漏。内存泄露有时不严重且不易察觉，这样开发者就不知道存在内存泄露，但有时也会很严重，会提示Out of memory。

Java内存泄漏的根本原因是什么呢？长生命周期的对象持有短生命周期对象的引用就很可能发生内存泄漏，尽管短生命周期对象已经不再需要，但是因为长生命周期持有它的引用而导致不能被回收，这就是Java中内存泄漏的发生场景。具体主要有如下几大类：

1、静态集合类引起内存泄漏

像HashMap、Vector等的使用最容易出现内存泄露，这些静态变量的生命周期和应用程序一致，他们所引用的所有的对象Object也不能被释放，因为他们也将一直被Vector等引用着。

static Vector v = new Vector(10);
for (int i = 1; i<100; i++){
	Object o = new Object();
	v.add(o);
	o = null;
}

在这个例子中，循环创建Object 对象，并将所创建的对象放入一个Vector 中，如果仅仅释放引用本身（o=null），那么Vector 仍然引用该对象，所以这个对象对GC 来说是不可回收的。因此，如果对象加入到Vector 后，还必须从Vector 中删除，最简单的方法就是将Vector对象设置为null。

2、当集合里面的对象属性被修改后，再调用remove()方法时不起作用。

public static void main(String[] args){
	Set<Person> set = new HashSet<Person>();
	Person p1 = new Person("唐僧","pwd1",25);
	Person p2 = new Person("孙悟空","pwd2",26);
	Person p3 = new Person("猪八戒","pwd3",27);
	set.add(p1);
	set.add(p2);
	set.add(p3);
	System.out.println("总共有:"+set.size()+" 个元素!"); //结果：总共有:3 个元素!
	p3.setAge(2); //修改p3的年龄,此时p3元素对应的hashcode值发生改变

	set.remove(p3); //此时remove不掉，造成内存泄漏

	set.add(p3); //重新添加，居然添加成功
	System.out.println("总共有:"+set.size()+" 个元素!"); //结果：总共有:4 个元素!
	for (Person person : set){
		System.out.println(person);
	}
}

3、监听器

在java 编程中，我们都需要和监听器打交道，通常一个应用当中会用到很多监听器，我们会调用一个控件的诸如addXXXListener()等方法来增加监听器，但往往在释放对象的时候却没有记住去删除这些监听器，从而增加了内存泄漏的机会。

4、各种连接

比如数据库连接（dataSourse.getConnection()），网络连接(socket)和io连接，除非其显式的调用了其close（）方法将其连接关闭，否则是不会自动被GC 回收的。对于Resultset 和Statement 对象可以不进行显式回收，但Connection 一定要显式回收，因为Connection 在任何时候都无法自动回收，而Connection一旦回收，Resultset 和Statement 对象就会立即为NULL。但是如果使用连接池，情况就不一样了，除了要显式地关闭连接，还必须显式地关闭Resultset Statement 对象（关闭其中一个，另外一个也会关闭），否则就会造成大量的Statement 对象无法释放，从而引起内存泄漏。这种情况下一般都会在try里面去的连接，在finally里面释放连接。

5、内部类和外部模块的引用

内部类的引用是比较容易遗忘的一种，而且一旦没释放可能导致一系列的后继类对象没有释放。此外还要小心外部模块不经意的引用，例如程序员A 负责A 模块，调用了B 模块的一个方法如： public void registerMsg(Object b); 这种调用就要小心，传入了一个对象，可能模块B就保持了对该对象的引用，需要注意模块B 是否提供相应的操作去除引用。

6、单例模式

不正确使用单例模式是引起内存泄漏的一个常见问题，单例对象在初始化后将在JVM的整个生命周期中存在（以静态变量的方式），如果单例对象持有外部的引用，那么这个对象将不能被JVM正常回收，导致内存泄漏。

class A{
	public A(){
		B.getInstance().setA(this);
	}
	....
}
//B类采用单例模式
class B{
	private A a;
	private static B instance = new B();
	public B(){}
	public static B getInstance(){
		return instance;
	}
	public void setA(A a){
		this.a=a;
	}
	//getter...
}

显然B采用singleton模式，它持有一个A对象的引用，而这个A类的对象将不能被回收。想象下如果A是个比较复杂的对象或者集合类型会发生什么情况

其他OOM

  1. OutOfMemoryError异常

    除了程序计数器外，虚拟机内存的其他几个运行时区域都有发生OutOfMemoryError(OOM)异常的可能，

    Java Heap 溢出，一般的异常信息：java.lang.OutOfMemoryError:Java heap spacess

    java堆用于存储对象实例，我们只要不断的创建对象，并且保证GC Roots到对象之间有可达路径来避免垃圾回收机制清除这些对象，就会在对象数量达到最大堆容量限制后产生内存溢出异常。

    出现这种异常，一般手段是先通过内存映像分析工具(如Eclipse Memory Analyzer)对dump出来的堆转存快照进行分析，重点是确认内存中的对象是否是必要的，先分清是因为内存泄漏(Memory Leak)还是内存溢出(Memory Overflow)。

    如果是内存泄漏，可进一步通过工具查看泄漏对象到GC Roots的引用链。于是就能找到泄漏对象时通过怎样的路径与GC Roots相关联并导致垃圾收集器无法自动回收。

    如果不存在泄漏，那就应该检查虚拟机的参数(-Xmx与-Xms)的设置是否适当。

  2. 虚拟机栈和本地方法栈溢出

    如果线程请求的栈深度大于虚拟机所允许的最大深度，将抛出StackOverflowError异常。如递归方法没有退出条件

    如果虚拟机在扩展栈时无法申请到足够的内存空间，则抛出OutOfMemoryError异常

    这里需要注意当栈的大小越大可分配的线程数就越少。

  3. 运行时常量池溢出

    异常信息：java.lang.OutOfMemoryError:PermGen space
    如果要向运行时常量池中添加内容，最简单的做法就是使用String.intern()这个Native方法。该方法的作用是：如果池中已经包含一个等于此String的字符串，则返回代表池中这个字符串的String对象；否则，将此String对象包含的字符串添加到常量池中，并且返回此String对象的引用。由于常量池分配在方法区内，我们可以通过-XX:PermSize和-XX:MaxPermSize限制方法区的大小，从而间接限制其中常量池的容量。

    对于老版本的 Oracle JDK，因为永久代的大小是有限的，并且 JVM 对永久代垃圾回收（如，常量池回收、卸载不再需要的类型）非常不积极，所以当我们不断添加新类型的时候，永久代出现 OutOfMemoryError 也非常多见。

  4. 方法区溢出

    方法区用于存放Class的相关信息，如类名、访问修饰符、常量池、字段描述、方法描述等。

    异常信息：java.lang.OutOfMemoryError:PermGen space
    方法区溢出也是一种常见的内存溢出异常，一个类如果要被垃圾收集器回收，判定条件是很苛刻的。在经常动态生成大量Class的应用中，要特别注意这点。

    随着元数据区的引入，方法区内存已经不再那么窘迫，所以相应的 OOM 有所改观，出现OOM，异常信息则变成了：“java.lang.OutOfMemoryError: Metaspace”。

如何监控和诊断 JVM 堆内和堆外内存使用

  • 可以使用综合性的图形化工具，如 JConsole
  • 也可以使用命令行工具进行运行时查询，如 jstat 和 jmap 等工具都提供了一些选项，可以查看堆、方法区等使用数据。
  • 使用 jmap 等提供的命令，生成堆转储（Heap Dump）文件，然后利用 jhat 或 Eclipse MAT 等堆转储分析工具进行详细分析。
  • 如果使用的是 Tomcat、Weblogic 等 Java EE 服务器，这些服务器同样提供了内存管理相关的功能。
  • 另外，从某种程度上来说，GC 日志等输出，同样包含着丰富的信息
comments powered by Disqus