JVM - 关于垃圾收集的常见问题

声明：

本文由Yasin Shaw原创，首发于我的网站yasinshaw.com和公众号"xy的技术圈"。

若是须要转载请联系我（微信：yasinshaw）并在文章开头显著的地方注明出处。

关注公众号便可获取学习资源或加入技术交流群。

引用

Java有哪四种引用？分别介绍一下？

在JDK 1.2 以后，对引用的概念进行了扩充，把引用分为强引用、软引用、弱引用、虚引用。

• 强引用：通常的引用，只要强引用还存在，垃圾收集器就不会回收这个对象；
• 软引用SoftReference：描述一些还有用但不是必须的对象。在系统将要发生OOM以前，会把这些对象列进回收范围之中进行第二次回收，若是第二次回收后仍是没有足够的内存，才会抛OOM异常；
• 弱引用WeakReference：只能生存到下一次垃圾收集发生以前；
• 虚引用PhantomReference：一个对象是否有虚引用的存在，彻底不会对其生存时间构成影响，也没法经过虚引用来取得一个对象实例。

这四种引用的应用场景是什么？

强引用就不说了，咱们平时用得最多的就是强引用。

软引用通常用于图片缓存、网页缓存或其它形式的缓存框架中。“内存缓存”中的图片是以这种引用保存，使得 JVM 在发生 OOM 以前，能够回收这部分缓存。

Browser prev = new Browser();               // 获取页面进行浏览
SoftReference sr = new SoftReference(prev); // 浏览完毕后置为软引用 
if(sr.get() != null) { 
    rev = (Browser) sr.get();           // 尚未被回收器回收，直接获取
} else {
    prev = new Browser();               // 因为内存吃紧，因此对软引用的对象回收了
    sr = new SoftReference(prev);       // 从新构建
}
复制代码

JDK中的WeakHashMap和ThreadLocal使用了弱引用。

设计WeakHashMap类是为了解决一个有趣的问题：若是有一个值，对应的键已经再也不使用了，将会出现什么状况呢？

假定对某个键的最后一次引用已经消亡，再也不有任何途径引用这个值的对象了。可是，因为在程序中的任何部分没有再出现这个键，因此，这个键值对没法从Map中删除。

WeakHashMap 使用弱引用（weak references) 保存键。 WeakReference对象将引用保存到另一个对象中，在这里，就是散列键。对于这种类型的对象，垃圾回收器用一种特有的方式进行处理。

一般，若是垃圾回收器发现某个特定的对象已经没有他人引用了，就将其回收。然而，若是某个对象只能由 WeakReference引用，垃圾回收器仍然回收它，但要将引用这个对象的弱引用放人队列中。

WeakHashMap将周期性地检查队列，以便找出新添加的弱引用。一个弱引用进人队列意味着这个键再也不被他人使用，而且已经被收集起来。因而，WeakHashMap将删除对应的键值对。

JDK中直接内存的回收就用到虚引用，因为JVM自动内存管理的范围是堆内存，而直接内存是在堆内存以外（实际上是内存映射文件），因此直接内存的分配和回收都是由Unsafe类去操做。

Java在申请一块直接内存以后，会在堆内存分配一个对象保存这个堆外内存的引用，这个对象被垃圾收集器管理，一旦这个对象被回收，相应的用户线程会收到通知并对直接内存进行清理工做。

关于软引用的缓存功能，还有更好的替代方法吗？

有的，咱们可使用最近最少使用算法（LRU）。其核心思想是“若是数据最近被访问过，那么未来被访问的概率也更高”。最多见的实现是使用一个链表保存缓存数据，详细算法实现以下：

1. 新数据插入到链表头部；
2. 每当缓存命中（即缓存数据被访问），则将数据移到链表头部；
3. 当链表满的时候，将链表尾部的数据丢弃。

Redis的键过时策略就使用了LRU算法。

安全点

什么是安全点和安全区域？

指的是程序在某个点或者某个区域是GC安全的。

对于Safe Point，另外一个须要考虑的问题是如何在GC发生时让全部线程（这里不包括执行JNI调用的线程）都“跑”到最近的安全点上再停顿下来。

这里有两种方案可供选择：抢先式中断（Preemptive Suspension）和主动式中断（Voluntary Suspension），其中抢先式中断不须要线程的执行代码主动去配合，在GC发生时，首先把全部线程所有中断， 若是发现有线程中断的地方不在安全点上，就恢复线程，让它“跑”到安全点上。如今几乎没有虚拟机实现采用抢先式中断来暂停线程从而响应GC事件。

而主动式中断的思想是当GC须要中断线程的时候，不直接对线程操做，仅仅简单地设置一个标志，各个线程执行时主动去轮询这个标志，发现中断标志为真时就本身中断挂起。轮询标志的地方和安全点是重合的，另外再加上建立对象须要分配内存的地方。

使用Safe Point彷佛已经完美地解决了如何进入GC的问题，但实际状况却并不必定。Safe Point机制保证了程序执行时，在不太长的时间内就会遇到可进入GC的Safe Point。

可是，程序“不执行”的时候呢？所谓的程序不执行就是没有分配CPU时间，典型的例子就是线程处于Sleep状态或者Blocked状态，这时候线程没法响应JVM的中断请求，“走”到安全的地方去中断挂起，JVM也显然不太可能等待线程从新被分配CPU时间。对于这种状况，就须要安全区域（Safe Region）来解决。

安全区域是指在一段代码片断之中，引用关系不会发生变化。在这个区域中的任意地方开始GC都是安全的。咱们也能够把Safe Region看作是被扩展了的Safe Point。

在线程执行到Safe Region中的代码时，首先标识本身已经进入了Safe Region，那样，当在这段时间里JVM要发起GC时，就不用管标识本身为Safe Region状态的线程了。在线程要离开Safe Region时，它要检查系统是否已经完成了根节点枚举（或者是整个GC过程），若是完成了，那线程就继续执行，不然它就必须等待直到收到能够安全离开Safe Region的信号为止。

垃圾收集器

说一下常见的一些垃圾收集器？

新生代： Serial：单线程，新生代； ParNew: 多线程，新生代； Parallel Scavenge：多线程，新生代，关注吞吐量，容许较长的STW（Stop the world）换取吞吐量最大化； 老年代： Serial Old: 单线程，Serial的老年代版本； Parallel Old：多线程，Parallel Scavenge的老年代版本，关注吞吐量； CMS：多线程，标记-清除算法，关注停顿时间，能够与Serial和ParNew配合。 其它： G1：同时负责新生代和老年代，是目前一段时间主流的垃圾收集器（JDK 9 到 11 的默认垃圾收集器）。 ZGC：在大堆下也能够控制STW时间极短（几毫秒内），在JDK 11 为实验阶段。

Java 各版本模式默认是用的什么垃圾收集器？

这里只讨论Server模式.

在JDK7，默认是Parallel Scavenge + Serial Old。

在JDK 8 及JDK 7u4以后的版本，默认是Parallel Scavenge + Parallel Old。

在JDK 9 到JDK 11，默认是G1

GC

介绍一下CMS老年代GC的几个阶段，并对它们的耗时作一下排序？

四个阶段：

1. 初始标记：标记GC Roots能直接关联到的对象，须要STW（Stop The World）；
2. 并发标记：根据初始标记的对象作可达性分析；
3. 从新标记：修正并发标记期间由于用户应用程序继续运做而致使标记产生变更的对象，须要STW；
4. 并发清除：回收对象；

耗时排序：并发清除> 并发标记> 从新标记 > 初始标记

说一下CMS的CMF（Concurrent Mode Failure）产生的缘由？

CMS在老年代达到阈值（默认92%，能够经过参数调整阈值）的时候，会进行Full GC。

若是在“并发清除”阶段，因为程序继续运行，产生了过多的垃圾，预留的内存没法知足程序须要，就会出现Concurrent Mode Failure。

说一下若是CMS发生了CMF，虚拟机是怎么处理的？

若是出现了CMF，这时虚拟机将启动后备预案： 临时启用Serial Old收集器来从新进行Full GC，这样停顿时间就很长了。

G1从Java9开始成为默认的垃圾收集器，它的优势是什么？

G1一直在持续不断地改进中，G1设计的目的是替换CMS，它最主要的优势是创建了“可预测的停顿模型”，它能够尽可能去知足用户指望的停顿时间。

同时，G1解决了CMS碎片化太多的问题。JVM系列下一篇文章咱们将重点讨论G1。

内存分配和回收策略

对象在堆上的内存分配和回收策略？

• 优先在Eden区分配。新生代通常分为一个Eden加两个Survivor，默认比例8:1:1（G1有所不一样，下篇文章介绍）。
• 大对象直接进入老年代。由于新生代通常使用复制算法，若是对象太大，在新生代复制的代价很是高，并且占内存。常见的大对象有：很大的字符串、很大的byte数组（好比图片等转成的字节数组）。
• 长期存活的对象进入老年代。对象头有一个字段存放了对象的“年龄”信息，对象在新生代每通过一次Minor GC，就会+1，当它的年龄达到必定值（默认是15），就会进入老年代。
• 动态对象年龄断定：对象年龄不必定要达到阈值才进入老年代，若是在Survivor空间中相同年龄全部对象大小的总和大于Survivor空间的一半，年龄大于或等于该值的对象，就能够直接进入老年代。
• 空间分配担保：在发生Minor GC以前，JVM会检查老年代最大可用连续空间时候大于历次晋升到老年代对象的平均大小，若是大于，就容许分配担保，若是小于，就要进行一次Full GC。而若是容许了分配担保，结果发现装不下，就说明担保失败，那也会发起一次Full GC。