转载

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

在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中的 WeakHashMapThreadLocal 使用了弱引用。

设计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。

原文  https://juejin.im/post/5ddc71f9e51d45232f3bcf03
正文到此结束
Loading...