GC

JVM

1、什么是垃圾回收系统？

• 程序在运行过程中，会产生大量的内存垃圾（一些没有引用指向的内存对象都属于内存垃圾，因为这些对象已经无法访问，对程序而言它们已经死亡），为了确保程序运行时的性能，Java 虚拟机在程序运行的过程中不断地进行自动的垃圾回收（GC）。
• JVM 的垃圾回收器都不需要我们手动处理无引用的对象了，这个就是最大的优点。而缺点也显而易见，Java 并未提供显式的内存管理操作，仅有的 System.gc() 方法也只是通知 JVM 需要进行 GC 操作，但是否执行仍需 JVM 决定。

2、哪些内存区域需要回收？

• 程序计数器、虚拟机栈、本地方法栈三个区域随线程而生随线程而灭。虚拟机栈中的栈帧随着方法的开始和结束对应着入栈和出栈。每一个栈帧需分配内存的大小在类结构确定下来时就已知了。因此这几个区域的内存分配和回收都具有确定性。方法结束时或是线程结束时内存会随之回收。
• 在 JVM 的堆和方法区中，一个接口的实现类所需的内存可能不同，一个方法的不同分支所需内存也可能不同。只有在程序运行期才能知道要创建多少对象，这部分的内存分配和回收具有动态性。

3、如何判断对象是否可以回收？

Java 在垃圾回收之前，需要判断对象是否存活，只有死亡的对象才能被 GC 回收。常用的两种方式是：引用计数法和可达性分析。

• 引用计数
  给对象添加一个引用计数器，每当有一个对象引用时 +1，当引用失效时 -1，任何时刻计数器为 0 的对象就是可以被回收的对象。
  
  • 引用计数发实现虽然简单，且很高效，但很难解决对象之间循环引用的问题。
• 可达性分析
  通过一系列称为 GC Roots 的对象作为起始点，从这些点向下搜索，搜索所走过的路径称为引用链，当一个对象到 GC Roots 没有任何引用链相连时，则认为对象不可达。
• 即使在可达性分析中不可达的对象，也并非是非死不可，只是处于缓刑阶段，要真正死亡至少要经历两次标记，这跟 finalize 有关。

4、GC Roots 对象有哪些？

1）虚拟机栈中引用的对象；

2）方法区中（1.8称为元空间）的类静态属性引用的对象；

3）方法区中的常量引用的对象；

4）本地方法栈中的JNI（native方法）引用的对象。

5、对象的回收过程？

JVM 在对 Java 对象回收阶段进行两次标记，一次筛选。

• finalize（）主要回收非Java资源如文件句柄、socket等。

1）如果可达性分析算法发现对象没有在 GC ROOT 引用链中，进行第一次标记并筛选是否需要调用重写的 finalize() 方法。

2）筛选的依据是被回收对象是否重写过 finalize() 方法，且该重写方法并未被虚拟机调用过，不满足直接进行回收。

3）如果该对象有必要执行 finalize() 方法，该对象就会被放置在一个叫 F-Queue 的队列之中 ，并在稍后会由虚拟机自动创建一个低优先级的线程 Finalizer 线程去执行它。这个线程只会触发这个方法，不一定会等它结束，原因是防止一个 finalize() 方法在虚拟机中执行缓慢或死循环，导致 F-Queue 队列中其他对象永久处于等待状态，甚至导致整个内存回收系统崩溃。

finalize() 方法是对象逃脱死亡命运的最后一次机会，稍后 GC 将会对 F-Queue 队列中的对象进行第二次小规模的标记，如果对象在 finalize() 方法中重新与引用链上的任何一个对象建立联系，就可以拯救自己。

6、方法区能否被回收？

• 有些人认为方法区（如 HotSpot 中的元空间或者永久代）是没有垃圾收集行为的，《Java虚 拟机规范》中提到过可以不要求虚拟机在方法区中实现垃圾收集，事实上也确实有未实现或未能完整实现方法区类型卸载的收集器存在（如JDK 11 时期的 ZGC 收集器就不支持类卸载），方法区垃圾收集的性价比通常也是比较低的，在 Java 堆中，尤其是在新生代中，对常规应用进行一次垃圾收集通常可以回收 70-99% 的内存空间，相比之下，方法区回收囿于苛刻的判定条件，其区域垃圾收集的回收成果往往远低于此。

方法区的垃圾收集主要回收两部分，废弃的常量和不再使用的类型。

该类所有的实例都已经被回收，也就是 Java 堆中不存在该类及其任何派生子类的实例。
加载该类的类加载器已经被回收，这个条件除非是经过精心设计的可替换类加载器的场景，如 OSGi、JSP 的重加载等，否则通常是很难达成的。
该类对应的 java.lang.Class 对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。
JVM 被允许对满足上述三个条件的无用类进行回收，而并不是和对象一样，没有引用了就必然会回收。关于是否要对类型进行回收，HotSpot 还提供了 -Xnoclassgc 参数进行控制。

7、四种引用类型？

• 强引用：永不回收，Java 中默认引用；

  例：

  Object obj=new Object();

  强引⽤是使用最普遍的引用。如果⼀个对象具有强引用，那垃圾回收器绝不会回收它。当内存空间不足，Java虚拟机宁愿抛出OutOfMemoryError错误，使程序异常终止，也不会靠随意回收具有强引⽤的对象来解决内存不足的问题。

• 软引用：内存溢出前回收；

  例：

  Object obj = new Object();
  SoftReference sf = new SoftReference(obj);
  obj = null;
  sf.get();//获取对象
  如果内存空间不足了，就会回收这些对象的内存。软引用可以和⼀个引用队列（ReferenceQueue）联合使用，如果软引用所引用的对象被垃圾回收器回收，Java虚拟机就会把这个软引用加⼊到与之关联的引用队列中。

• 弱引用：下次GC时回收；
  Object obj = new Object();
  WeakReference wf = new WeakReference(obj);
  wf.get();//获取对象

  弱引⽤与软引用的区别在于：只具有弱引用的对象拥有更短暂的⽣命周期。在垃圾回收器线程扫描它所管辖的内存区域的过程中，⼀旦发现了只具有弱引用的对象，不管当前内存空间足够与否，都会回收它的内存。弱引⽤可以和⼀个引用队列（ReferenceQueue）联合使用，如果弱引用所引用的对象被垃圾回收，Java虚拟机就会把这个弱引用加⼊到与之关联的引用队列中。

• 虚引用：无法通过 PhantomReference 获取对象，作用是 GC 时返回一个通知。
  Object obj = new Object();
  PhantomReference pf = new PhantomReference(obj);
  虚引用在任何时候都可能被垃圾回收器回收，主要用来跟踪对象被垃圾回收器回收的活动，被回收时会收到⼀个系统通知。虚引用与软引用和弱引用的⼀个区别在于：虚引用必须和引用队列 （ReferenceQueue）联合使用。当垃圾回收器准备回收⼀个对象时，如果发现它还有虚引用，就会在回收对象的内存之前，把这个虚引用加⼊到与之关联的引用队列中。

8、有哪些垃圾回收算法？

由于 Java 虚拟机规范中并没有对如何实现垃圾收集器做出明确的规定，因此各个厂商的虚拟机可以采用不同的方式来实现垃圾收集器，所以在此只讨论几种常见的垃圾收集算法的核心思想。

常见的算法有新生代的复制算法，以及老年代的标记清除和标记整理算法。

• Mark-Sweep（标记-清除）算法
  这是最基础的垃圾回收算法，因为它最容易实现，思想也是最简单的。标记-清除算法分为标记和清除两个阶段。标记阶段的任务是标记出所有需要被回收的对象，清除阶段就是回收被标记的对象所占用的空间。
  
  • 但是有一个比较严重的问题就是容易产生内存碎片，碎片太多可能会导致后续过程中需要为大对象分配空间时无法找到足够的空间而提前触发新的一次垃圾收集动作。
• Copying（复制）算法
  为了解决标记清除算法的缺陷，复制算法就被提了出来。它将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用的内存空间一次清理掉，这样一来就不容易出现内存碎片的问题。
  
  • 这种算法虽然实现简单，运行高效且不容易产生内存碎片，但是却对内存空间的使用做出了高昂的代价，因为能够使用的内存缩减到原来的一半。同时回收效率也和存活对象数量有着极大关系。
• Mark-Compact（标记-整理）算法
  为了解决复制算法的缺陷，充分利用内存空间，提出了标记整理算法，也称压缩算法。该算法标记阶段和标记清除一样，但是在完成标记之后，它不是直接清理可回收对象，而是将存活对象都向一端移动，然后清理掉端边界以外的内存。

• Generational Collection（分代收集）算法
  分代收集算法是目前大部分JVM的垃圾收集器采用的算法。它的核心思想是根据对象存活的生命周期将内存划分为若干个不同的区域。一般情况下将堆区划分为老年代（Tenured Generation）和新生代（Young Generation），老年代的特点是每次垃圾收集时只有少量对象需要被回收，而新生代的特点是每次垃圾回收时都有大量的对象需要被回收，那么就可以根据不同代的特点采取最适合的收集算法。

  目前大部分垃圾收集器对于新生代都采取复制算法，因为新生代中每次垃圾回收都要回收大部分对象，也就是说需要复制的操作次数较少，但是实际中并不是按照 1:1 的比例来划分新生代的空间的，一般来说是将新生代划分为一块较大的 Eden 空间和两块较小的 Survivor 空间，每次使用 Eden 空间和其中的一块 Survivor 空间，当进行回收时，将 Eden 和 Survivor 中还存活的对象复制到另一块 Survivor 空间中，然后清理掉 Eden 和刚才使用过的 Survivor 空间。

而由于老年代的特点是每次回收都只回收少量对象，一般使用的是标记-整理算法（压缩法）。

9、新生代为划分空间的比例？

通常将新生代划分为一块较大的 Eden 空间和两块较小的 Survivor 空间，其比例是 8:1:1。这是一个根据统计学得出的数据，新生代对象生存时间比较短，大约 80% 对象被回收。

10、常见的垃圾回收器

图中展示了 7 种作用于不同分代的收集器，分别是新生代收集器 Serial、ParNew、Parallel Scavenge，老年代收集器 CMS、Serial Old、Parallel Old 以及整堆收集器 G1。如果两个收集器之间存在连线，则说明它们可以搭配使用。虚拟机所处的区域则表示它是属于新生代还是老年代收集器。

• Serial 收集器
  单线程、简单高效，对于限定单个 CPU 的环境来说，Serial 收集器由于没有线程交互的开销，专心做垃圾收集自然可以获得最高的单线程回收效率。收集器进行垃圾回收时，必须暂停其他所有的工作线程，直到它结束（Stop The World）。
• ParNew 收集器
  ParNew 收集器其实就是Serial收集器的多线程版本。除了使用多线程外其余行为均和 Serial 收集器一模一样（参数控制、收集算法、Stop The World、对象分配规则、回收策略等），同样存在 STW 问题。
  
  • 可以使用 -XX:ParallelGCThreads 参数来设置垃圾收集的线程数。许多运行在 Server 模式下的虚拟机中首选的新生代收集器，因为它是除了 Serial 外，唯一能与 CMS 收集器配合工作的。
• Parallel Scavenge 收集器
  这是一个可以控制吞吐量的多线程收集器，故也称为吞吐量优先收集器。相比 ParNew 收集器，Parallel Scavenge 可以使用 XX:MaxGCPauseMillis 控制最大的垃圾收集停顿时间以及 XX:GCRatio 直接设置吞吐量的大小。
  
  • 同时支持 GC 自适应调节策略。即 Parallel Scavenge 收集器可设置 -XX:+UseAdptiveSizePolicy 参数。当打开时不需要手动指定新生代的大小（-Xmn）、Eden 与 Survivor区的比例（-XX:SurvivorRation）、晋升老年代的对象年龄（-XX:PretenureSizeThreshold）等信息，虚拟机会根据系统的运行状况收集性能监控信息，动态设置这些参数以提供最优的停顿时间和最高的吞吐量。
• Serial Old 收集器
  Serial 收集器的老年代版本，同样是单线程收集器，采用标记-整理算法。
• Parallel Old 收集器
  是 Parallel Scavenge收集器的老年代版本，采用标记-整理算法。适用于注重高吞吐量以及 CPU 资源敏感的场合。
• CMS 收集器
  一种以获取最短回收停顿时间为目标的收集器。也是基于标记-清除算法的并发收集器。此处并发同步于前面提及的几种多线程并行收集器，是指用户线程与垃圾收集线程同时工作（不一定是并行的可能会交替执行）。
  
  • 非常适用于注重服务的响应速度，希望系统停顿时间最短，给用户带来更好的体验等场景。
• G1 收集器
  一款面向服务端应用的垃圾收集器。

11、CMS 是如何工作的？

CMS 收集器的运行过程分为下列 4 步：

1）初始标记阶段，标记 GC Roots 能直接到的对象。速度很快但是仍存在 Stop The World 问题。

2）并发标记阶段，进行 GC Roots Tracing 的过程，找出存活对象且用户线程可并发执行。

3）重新标记阶段，为了修正并发标记期间因用户程序继续运行而导致标记产生变动的那一部分对象的标记记录，也存在 STW 问题。

4）并发清除阶段，对标记的对象进行清除回收。

CMS 收集器的缺点：

对 CPU 资源非常敏感。
无法处理浮动垃圾，可能出现 Concurrent Model Failure 失败而导致另一次 Full GC 的产生。
因为采用标记-清除算法所以会存在空间碎片的问题，导致大对象无法分配空间，不得不提前触发一次 Full GC。

12、G1 收集器是如何工作的？

如果不计算维护 Remembered Set 的操作，G1 收集器大致可分为如下步骤：

1）初始标记：仅标记GC Roots能直接到的对象，并且修改TAMS（Next Top at Mark Start）的值，让下一阶段用户程序并发运行时，能在正确可用的Region中创建新对象。（需要线程停顿，但耗时很短。）

2）并发标记：从GC Roots开始对堆中对象进行可达性分析，找出存活对象。（耗时较长，但可与用户程序并发执行）

3）最终标记：为了修正在并发标记期间因用户程序执行而导致标记产生变化的那一部分标记记录。且对象的变化记录在线程Remembered Set Logs里面，把Remembered Set Logs里面的数据合并到Remembered Set中。（需要线程停顿，但可并行执行。）

4）筛选回收：对各个Region的回收价值和成本进行排序，根据用户所期望的GC停顿时间来制定回收计划。（可并发执行）

13、触发 GC 的条件？

先来了解一下什么是 MinorGC(Young GC) 和 Major GC/FullGC。

1）MinorGC

从年轻代空间（包括 Eden 和 Survivor 区域）回收内存被称为 Minor GC，也叫Young GC。因为 Java 对象大多具备朝生夕死的特征，所以MinorGC非常频繁，一般回收速度也比较快。一般采用复制算法。

MinorGC 触发条件也很简单：当年轻代空间不足时，就会触发 MinorGC，注意这里的年轻代满指的是 Eden 区，Survivor 满不会引发 MinorGC。

同时 Minor GC 会引发 STW，暂停其它用户的线程，等垃圾回收结束，用户线程才恢复运行。

2）Major GC

CMS 收集器中，当老年代满时会触发 Major GC。且目前只有 CMS 收集器会有单独收集老年代的行为。

3）Full GC

Full GC 对收集整堆（新生代、老年代）和方法区的垃圾收集。

当年老代满时会引发 Full GC，将会同时回收新生代、年老代 ；当永久代满时也会引发 Full GC，会导致 Class、Method 元信息的卸载。

调用System.gc时，系统建议执行Full GC，但是不一定会执行；
老年代空间不足；
方法区空间不足；
通过 Minor GC 后进入老年代的空间大于老年代的可用内存；
由 Eden 区、survivor space1（From Space）区向 survivor space2（To Space）区复制时，对象大小大于 To Space 可用内存，则把该对象转存到老年代，且老年代的可用内存小于该对象大小。

14、什么是三色标记？

在垃圾回收算法中，标记总是必可少的一步。要找出存活对象，根据可达性分析，从 GC Roots 开始进行遍历访问，同时我们把遍历对象图过程中遇到的对象，按是否访问过这个条件标记成以下三种颜色：

白色：尚未访问过；
黑色：本对象已访问过，而且本对象引用到的其他对象也全部访问过了；
灰色：本对象已访问过，但是本对象引用到的其他对象尚未全部访问完。待全部访问后，会转换为黑色。

假设现在有白、灰、黑三个集合（表示当前对象的颜色），其遍历访问过程为：

1）初始时，所有对象都在白色集合中；

2）将 GC Roots 直接引用到的对象挪到灰色集合中；

3）从灰色集合中获取对象：将本对象引用到的其他对象全部挪到灰色集合中，最后将本对象本身挪到黑色集合里面；

重复步骤 3），直至灰色集合为空时结束。结束后，仍在白色集合的对象即为 GC Roots 不可达，可以进行回收。

15、什么是多标和漏标？

当需要支持并发标记时，即标记期间应用线程还在继续跑，对象间的引用可能发生变化，多标和漏标的情况就有可能发生。

• 多标
  当某个对象标记成灰色时，不被引用对象继续引用，本该被回收却被当作存活对象继续遍历下去，产生浮动垃圾。这并不会影响应用程序的正确性，只是需要等到下一轮垃圾回收中才被清除。

  另外，针对并发标记开始后的新对象，通常的做法是直接全部当成黑色，本轮不会进行清除。这部分对象期间可能会变为垃圾，这也算是浮动垃圾的一部分。

• 漏标

假设 GC 线程已经遍历到 E（变为灰色了），此时应用线程先将 E 与 G 的引用关系断开，再让 D 引用到 G。切回GC线程继续执行回收算法时，因为 E 已经没有对 G 的引用了，所以不会将 G 放到灰色集合；尽管因为 D 重新引用了 G，但因为 D 已经是黑色了，不会再重新做遍历处理。最后导致 G 被当作垃圾进行清除。这直接影响到了应用程序的正确性，是不可接受的。

16、如何解决漏标问题？

从代码角度看，漏标只有同时满足以下逻辑时才会发生：

var G = objE.fieldG; // 1. 读
objE.fieldG = null; // 2. 写
objD.fieldG = G; // 3. 写
1）读取灰色对象的成员变量属性值 ref；
2）将灰色对象对应属性设置为 null；
3）将属性 ref 赋值给黑色对象。

不难看出，只要在上面这三步中的任意一步中做一些手脚，通过读写屏障将引用对象记录起来，然后作为灰色对象再进行遍历即可。比如放到一个特定的集合，等初始的 GC Roots 遍历完（并发标记），再对该集合的对象遍历即可（重新标记）。

重新标记通常是需要 STW 的，因为应用程序一直在跑的话，该集合可能会一直增加新的对象，导致永远都跑不完。

在现代垃圾回收器中，不同的收集器对漏标的处理方案有所不同：

• G1 采用写屏障 + SATB
  当原来成员变量的引用发生变化之前，记录下原来的引用对象，即原始快照（Snapshot At The Beginning，SATB）。
• CMS 采用写屏障 + 增量更新
  当有新引用插入进来时，记录下新的引用对象，这种做法的思路是不要求保留原始快照，而是针对新增的引用，将其记录下来等待遍历，即增量更新（Incremental Update）。
• ZGC 采用读屏障
  读取成员变量时一律记录下来，这种做法是保守的，但也是安全的。