1.怎样定位垃圾（怎么判断对象已死）？

（1）引用计数法（reference counting）

在对象中添加一个引用计数器，每当有一个地方引用他时，计数器就加一，当引用失效时，计数器的值就减1，任何时刻计数器为零的对象就是不可能再被使用的（存在弊端，当两个对象互相引用对方的时候，就会导致引用计数器一直都不为0，使得垃圾无法再进行回收）

 （2）可达性分析算法（Reachability Analysis）

通过一系列称为（GC Roots）的跟对象作为起始节点集，从这些节点开始，根据引用关系向下搜索，搜索过程所走过的路径称为“引用链”（Reference Chain），如果某个对象到GC Roots间没有任何引用链相连（从GC Roots到这个对象不可达）时，则证明此对象是不可能被再次使用过的

可达性分析算法要判定一个对象真正死亡要经过两次标记过程，如果对象在进行可达性分析以后发现没有与GC Roots相连的引用链，该对象就会被第一次标记，然后会进行一次筛选，筛选的条件是该对象是否有必要执行finalize()方法，如果对象没有覆盖finalize()方法，或者finalize()方法已经被虚拟机调用过，那么虚拟机将这两种情况都视为‘没有必要执行’。如果这个对象被判定为有必要执行finalize()方法，那么该对象就会被放置在一个F-Queue的队列之中，并在稍后由一条由虚拟机自动建立的。低调度优先级的Finalizer线程去执行它们的finalize()方法（这里的执行是指虚拟机会触发这个方法进行执行，但并不承诺一定会等待它运行结束，这样做的原因是，如果某个对象的finalize()方法执行缓慢，或者更极端的发生了死循环，将很可能导致整个内存回收子系统的崩溃）

Finalize()方法是对象逃脱死亡命运的最后一次机会，稍后收集器将对F-Queue中的对象进行第二次小规模的标记，如果对象要在finalize()中成功拯救自己，只要重新与引用链上的任何一个对象建立关联即可，譬如把自己（this关键字）赋值给某个类变量或者对象的成员变量，那么在第二次标记时，它将被移除“即将回收”的集合，如果对象这个时候还没有逃脱，那基本上它就真的要被回收了，下面实例为java实现gc回收时对象自救的过程

/**

 * 此代码演示了两点

 * 1.对象在被GC时会被自我拯救

 * 2.这种自救的机会只有一次，因为一个对象的finalize()方法最多只被系统调用一次

 * @author xh

 */

public class FinalizeEscapGC {

    public static FinalizeEscapGC SAVE_HOOK = null;

    public void isAlive(){

    System.out.println("I am still Alive");

    }

    @Override

    protected void finalize() throws Throwable {

         super.finalize();

         System.out.println("finalize be execute");

         SAVE_HOOK = this;

    }

    public static void main(String[] args) throws Throwable {

         SAVE_HOOK = new FinalizeEscapGC();

         //对象第一次拯救自己

         SAVE_HOOK = null;

         System.gc();

         //因为Finalizer的优先级很低，暂停0.5s，以等待它

         Thread.sleep(500);

         if(SAVE_HOOK != null){

             SAVE_HOOK.isAlive();

         }else{

             System.out.println("I am has dead");

         }

         //下面这段代码和上面的一样，但是这次却拯救失败了

         SAVE_HOOK = null;

         System.gc();

         //因为Finalizer的优先级很低，暂停0.5s，以等待它

         Thread.sleep(500);

         if(SAVE_HOOK != null){

             SAVE_HOOK.isAlive();

         }else{

             System.out.println("I am has dead");

         }

    }

  }

运行结果：

2.在java技术体系中，可固定作为GC Roots 的对象有哪些？

   （1）虚拟机栈（栈帧中的本地变量表）中引用的对象

           各个线程被调用的方法堆栈中使用到的参数，局部变量，临时变量

   （2）方法区中类的静态属性引用的对象

          Java类的引用类型静态变量

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

         字符串常量池（String Table）里的引用

  （4）本地方法栈中JNI（即常说的Native方法）引用的对象

  （5）Java虚拟机内部的引用

          基本数据类型对应的Class对象，一些常驻的异常对象（NullPointException，OutofMemoryError）等，还有系统类加载器

 （6）所有被同步锁（syncronized关键字）持有的对象

 （7）反映java虚拟机内部情况的JMXBean、JVMTI中注册的回调、本地代码缓存等

3.哪些垃圾收集器具备了局部回收的特征？

  （1）OpenJDK中的 G1，Shenandoah,ZGC

  （2）Azul 的PGC,C4

4.什么是引用？

     概念：如果reference类型的数据中存储的数值代表的是另一个内存的起始地址，就称该reference数值是代表某块内存，某个                 对象的引用

    分类：jdk1.2以后，java对引用概念进行了分类，一共分为以下几种

  （1）强引用（Strongly Reference）

          属于最传统的引用定义，指在程序代码之中普遍存在的引用复制，类似Object obj = new Object（） 这种引用关系。无论              在任何情况下，只要强引用关系还在，垃圾收集器就永远不会回收掉被引用的对象

  （2）软引用

          用来描述有一些还有用，但非必须的对象，只被软引用关联的对象，在系统将要发生内存溢出前，会把这些对象列进回收            范围之中进行第二次回收，如果这次回收还是没有足够的内存，才会抛出内存溢出异常。Java中使用SoftReference类来实            现软引用

 （3）弱引用

          用来描述那些非必须的对象，但是强度会比软引用更弱一些，被弱引用关联的对象只能生存到下一次垃圾收集发生为止，            当垃圾收集器开始工作，无论当前内存是否足够，都会回收掉被弱引用关联的对象。Java中通过WeakReference类来实现            弱引用

 （4）虚引用（幽灵引用/幻影引用）

         是最弱的一种引用，一个对象是否有虚引用存在，完全不会对其生存时间构成影响，也无法通过虚引用来获取到一个对象       实      例，为一个对象设置虚引用关联的唯一目的只是为了能在这个对象被收集器回收的时候收到一个系统通知，java使用       PhantomReference类来实现虚引用

5.垃圾收集算法有哪些？

（1）标记清除算法（Mark-Sweep）

在1960年由Lisp之父 John McCarthy提出，算法分为标记和清除两个阶段：首先标记出所有需要回收的对象，在标记完成后，统一回收掉所有被标记的对象，也可以反过来，标记存活的对象，统一回收掉所有未被标记的对象。标记的过程就是对象是否属于垃圾的判定过程

缺点：1） 执行效率不稳定：如果java堆中包含大量对象，而且其中大部分对象都是需要被回收的，这是就必须进行大量的标记和清除的动作，从而导致标记和清除两个过程的执行效率都会随对象数量的增长而降低

              2）内存空间的碎片化：标记，清除之后会产生大量的不连续的空间碎片，空间碎片太多可能会导致当以后在程序运行过程中需要分配较大对象时无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作

        算法图示：

（2）标记-复制算法/复制算法（Semispace Copying）

1969年由Fenichel提出的垃圾收集算法，将可用内存按容量划分为大小相等的两块，每次只使用其中的一块，当这一块内存用完了，就将还活着的对象复制到另外一块上面，然后再把已使用过的内存空间清除掉。

优点：1）实现简单，2）运行高效，3）没有空间碎片，只要移动堆顶指针，按顺序分配即可

缺点：1）如果内存中多数对象都是存活的，这种算法将导致大量的内存间复制的开销

      2）内存空间浪费：这种算法将可用内存缩小为了原来的一半

算法图示：

（3）标记-整理算法（Mark-Compact）

    针对老年代对象的存亡特征，1974年Edward Lueders提出Mark-Compact算法，其中标记过程仍然与标记-清除算法一样，但是后续步骤不是直接对可回收的对象进行清理，而是让所有存活的对象都向内存空间一端移动，然后直接清理掉边界以外的内存

    优点：1）没有空间碎片，2)不会浪费内存空间

    缺点：回收效率低：如果移动存活对象，尤其是在老年代这种每次回收都有大量对象存活的区域，移动存活对象并更新所有引用这些对象的地方将会是一个极为负重的操作，而且这种对象移动操作必须全程暂停用户应用程序才能进行

    算法图示：

6.垃圾收集器有哪些？

第一类：经典垃圾收集器

（1）Serial收集器

是最基础，历史最悠久的收集器，曾经（在jdk1.3.1之前）是HotSpot虚拟机新生代收集器的唯一选择。这个收集器是一个单线程工作的收集器，但它的单线程的意义并不仅仅是说明它只会使用一个处理器或一条收集线程去完成垃圾收集工作，更重要的是强调它在进行垃圾收集时，必须暂停其他所有工作线程，直到它收集结束（这个过程是由虚拟机在后台自动发起和自动完成的，在用户不可知，不可控的情况下把用户的正常工作的线程全部停掉，对于很多用户来说是不能接受的）

控制参数：-XX：SurvivorRatio   

-XX：PretenureSizeThreshold

-XX：HandlePromotionFailure

Serial/Serial Old收集器的运行过程图示：

（2）ParNew收集器

实质上是Serial收集器的多线程并行版本，除了同时使用多条线程进行垃圾收集之外，其余的行为包括Serial收集器可用的所有参数、收集算法、Stop the World，对象分配规则、回收策略等都与Serial收集器完全一致，在实现上这两种收集器也共用了相当多的代码

控制参数：-XX：SurvivorRatio   

-XX：PretenureSizeThreshold

-XX：HandlePromotionFailure

-XX：+UseConcMarkSweepGC（激活CMS）

          特点：除了Serial收集器以外，目前只有ParNew收集器能够与CMS收集器配合使用

          ParNew 收集器工作流程图示：

（3）Parallel Scavenge收集器

也是一款新生代收集器，同样基于标记-复制算法实现的收集器，能够并行收集的多线程收集器

特点：可以达到一个可控制的吞吐量（Throughput）（处理器用于运行用户代码的时间与处理器总消耗时间的比值）

控制参数：-XX：MaxGCPauseMillis（控制最大垃圾收集停顿时间）

-XX：GCTimeRatio（吞吐量大小）

-XX：+UseAdaptiveSizePolicy（开关参数，当这个参数激活之后，就不

需要人工指定新生代的大小（-Xmn）、Eden与

Survivor区的比ֻ例（-XX：SurvivorRatio）、晋升老

年代对象大小（-XX：PretenureSizeThreshold）等参数了）

（4）Serial Old 收集器

        Serial Old是Serial收集器的老年代版本，它同样是一个单线程收集器，使用标记-整理算法。这个收集器的主要意义也是供客户端下的HotSpot虚拟机使用。如果在服务端，它也可能有两种用途：一种是在JDK5以及之前的版本中与Parallel Scavenge收集器搭配使用，另外一种就是作为CMS收集器发生失败时的后备预案，在并发收集发生 Concurrent Mode Failure时使用

        Serial Old 收集器工作流程图示：

（5）Parallel Old 收集器

Parallel Old 是Parallel Scavenge收集器的老年代版本，支持多线程并发收集，基于标记-整理算法实现。这个算法是直到JDK1.6时才开始提供的，在此之前，新生代的Parallel Scavenge收集器一直处于相当尴尬的状态，原因是如果新生代选择了Parallel Scavenge收集器，老年代除了Serial Old（PS MarkSweep）收集器外别无选择，其他表现良好的老年代收集器，如CMS无法与它配合工作。由于老年代Serial Old收集器在服务端性能是哪个的‘拖累’，使用Parallel Scavenge收集器也未必能在整体上获得吞吐量最大的效果。

 知道Parallel Old收集器出现后，吞吐量优先收集器有了比较名副其实的搭配组合，在注重吞吐量或者处理器资源较为稀缺的场合，都可以优先考虑Parallel Scavenge 加 Parallel Old收集器这个组合

Parallel Old 收集器的工作过程图示：

（6）CMS（Concurrent Mark Sweep）收集器

CMS 收集器是一种以获取最短回收停顿时间为目标的收集器，目前很大一部分的java应用集中在互联网网站或者基于浏览器的B/S系统的服务器上，这类应用通常会较为关注服务的响应速度，希望系统的停顿时间尽可能短，以给用户带来良好的交互体验。

CMS收集器基于标记-清除算法实现，运作过程分为

   1）初始标记（CMS initial mark）

需要“Stop the World，仅仅只是标记一下GC Roots能直接关联到的对象，速度很快

   2）并发标记（CMS concurrent mark）

需要“Stop the World，从GC Roots的直接关联对象开始遍历整个对象图的过程，这个过程耗时较长但不需要停顿用户线程，可以与垃圾收集线程一起并发运行

   3）重新标记（CMS remark）

为了修正并发标记期间因用户程序继续运行而导致标记发生变动的那一部分对象的标记记录，这个阶段的停顿时间通常会比初始标记阶段稍长一些，但也远比并发标记阶段的时间短

   4）并发清除（CMS concurrent sweep）

清理删除掉标记阶段判断的已经死亡的对象，由于不需要移动存活对象，所以这个阶段也是可以和用户线程同时并发的

         特点：CMS收集器的内存回收过程是与用户线程一起并发执行的

         优点：并发收集，低停顿

         缺点：1）对处理器资源非常敏感，在并发阶段，虽然不会导致用户线程停顿，但是会因为占用了一部分线程而导致应用程                          序变慢，降低总吞吐量

                 2）空间碎片

      CMS收集器运行过程图示：

（7）G1（Garbage First）收集器（全功能的垃圾收集器）

G1收集器是垃圾收集器技术发展历史上的里程碑式的成果，它开创了收集器面向局部收集的设计思路和基于Region的内存布局形式。

G1收集器是一款主要面向服务端应用的垃圾收集器，jdk9发布，G1取代Parallel Scavenge加parallel Old组合，成为服务端模式下的默认垃圾收集器

特点：G1收集器的Mixed GC 模式：可以面向堆内存任何部分来组成回收集（Collection Set。一般简称CSet）进行回收，衡量标准不再是它属于哪个分代，  而是哪块内存中存放的垃圾数量最多，回收收益最大

实现原理：基于Region的堆内存布局

G1不再坚持固定大小以及固定数量的分代区域划分，而是把连续的java堆划分为多个大小相等的独立区域（Region），每一个Region都可以根据需要，扮演新生代的Eden空间，Survivor空间或者老年代空间。收集器对扮演不同角色的Region采用不同的策略去处理，对于在回收过程中对新创建对象的内存分配，程序要继续运行就肯定会持续有新对象创建，G1为每一个Region设计了两个名为    TAMS(Top at Mark Start)的指针，把Region中的一部分空间划分出来用于并发回收过程中的新对象分配，并发回收时，新分配的对象地址都必须要在这两个指针位置以上，G1默认在这个地址以上的对象是被隐式标记过得，即默认它们是存活的，不纳入回收范围，与CMS中的“Concurrent Mode Failure”失败会导致Full GC类似，如果内存回收的速度赶不上内存分配的速度，G1收集器也要被迫冻结用户线程执行，导致Full GC而产生长时间的“Stop The World”

          实现算法：SATB

优点：无论是新创建的对象还是已经存活了一段时间，熬过多次收集的旧对象都能获得很好的收集效果

G1Region分区示意图示：

          G1收集器的运作过程

  1）初始标记（Initial Marking）

仅仅只是标记一下GC Roots能直接关联到的对象，并且修改TAMS指针的值，让下一阶段用户线程并发运行时，能正确的在可用的Region中分配新对象，这个阶段需要停顿线程，但耗时很短，而且是借用进行Minor GC的时候同步完成的，所以G1收集器在这个阶段实际并没有额外的停顿

 2）并发标记（Concurrent Marking）

从GC Root开始对堆中对象进行可达性分析，递归扫描整个堆里的对象图，找出要回收的对象，这个阶段耗时较长，但是可与用户进程并发执行，当对象图扫描完成以后，还要重新处理 SATB记录下的在并发时有引用变动的对象

 3）最终标记（Final Marking）

对用户线程做另一个短暂的暂停，用于处理并发阶段结束后仍遗留下来的最后那少量的SATB记录

4）筛选回收（Live Data Counting and EvaCuation）

负责更新Region的统计数据，对各个Region的回收价值和成本进行排序，根据用户所期望的停顿时间来制定回收计划，可以自由选择任意多个Region构成回收集，然后把决定回收的那一部分Region的存活对象复制到空的Region中，再清理掉整个旧Region的全部空间。这里的操作涉及存活对象的移动，是必须暂停用户线程，由多条收集器线程并行完成的

          总结：G1收集器除了并发标记外，其余阶段也是要完全暂停线程的，换言之，它并非纯粹的追求低延迟，官方给它设定的目标是在延迟可控的情况下获得更高的吞吐量，所以才能担当起“全功能收集器”的重任与期望

G1收集器运行效果图示

各个垃圾收集器之间的关系

图示展示了七种作用于不同分代的收集器，如果两个收集器之间有连线，则说明它们可以搭配使用

第二类：低延迟垃圾收集器

1. Shenandoah收集器

第一款不由Oracle（包括以前的Sun）公司的虚拟机团队所领导开发的HotSpot垃圾收集器，不可避免地会受到一些来自‘官方’的排挤。也就是说，Shenandoah是一款只有OpenJDK才会 包含，而OracleJDK里反而不存在的收集器，它的‘免费开源版’比‘商业收费版’功能更多

发展历史：最初的Shenandoah由RedHat公司独立发展的新型收集器项目，在2014年RedHat把Shenandoah贡献给了OpenJDK，并推动它成为OpenJDK 12的正式特性之一，也就是后来的JEP 189

特点：能在任何堆内存大小下都可以把垃圾收集的停顿时间限制在10毫秒以内，相比CMS和G1，Shenandoah不仅要进行并发的垃圾标记，还要并发的进行对象清理后的整理工作

与G1的不同之处：

1）支持并发的整理算法（G1的回收阶段是可以多线程并行的，但是却不能与用户线程并发）

2）默认是不使用分代收集的（不会有专门的新生代Region或者老年代Region的存在，没有实现分代，并不是说分代对Shenandoah没有价值，更多是处于性价比的权衡，基于工作量上的考虑而将其放在优先级较低的位置上的）

3）摒弃了在G1中耗费较大内存和计算资源去维护的记忆集，改用名为‘连接矩阵（Connection Matricx）的全局数据结构来记录跨Region的引用关系’（降低了处理跨代指针时的记忆集维护消耗，也降低了伪共享的问题的发生概率）

 连接矩阵图示：

 图示解析：如果Region 5中的对象Baz引用了Region 3 Foo，Foo又引用了Region 1的Bar，那连接矩阵中的5行3列，3行1列就应该被打上标记，在回收时通过这张表格就可以得出哪些Region之间产生了跨代作用

         Shenandoah收集器的工作过程：

    1）初始标记（Initial Marking）

与G1一样，首先标记与GC Roots直接关联的对象，这个阶段仍是“Stop The World”的，但停顿时间与堆大小无关，至于GC Roots的数量相关

    2）并发标记（Concurrent Marking）

与G1一样，遍历对象图，标记出全部可达的对象，这个阶段是与用户线程一起并发的，时间长短取决于堆中存活的对象数量以及对象图的结构复杂程度

   3）最终标记（Final Marking）

与G1一样，处理剩余的SATB扫描，并在这个阶段统计出回收价值最高的Region，将这些Region构成一组回收集（Collection Set），最终标记阶段也会有一小段短暂的停顿

   4）并发清理（Concurrent Cleanup）

这个阶段用于清理那些整个区域内连一个存活对象都没有找到的Region（这类Region被称为Immediate Garbage Region）

   5）并发回收（Concurrent Evacuation）

并发回收阶段是Shenandoah与之前Hotspot中其它收集器的核心差异，在这个阶段，Shenandoah要把回收集里面的存活对象先复制一份到其他未使用的Region之中（复制对象这件事情如果将用户线程冻结起来再做那是相当简单的，但是两者必须要同事并发进行的话，就变得复杂起来了，其困难点是在移动对象的同时，用户线程仍然可能不停对被移动的对象进行读写访问，移动对象是一次性的行为，但移动之后整个内存中所有指向该对象的引用都还是旧对象的地址，这是很难一瞬间全部改变过来的。对于并发回收阶段遇到的这些困难，Shenandoah将会通过读屏障和被称为“Brooks Pointers”的转发指针来解决）。并发回收阶段运行的时间长短取决于回收集的大小

  6）初始引用更新（Initial Update Reference）

并发回收阶段复制对象结束后，还需要把堆中所有指向旧对象的引用修正到复制后的新地址，这个操作被称为‘引用更新’。应用更新的初始化阶段实际上并未做什么具体的处理，设立这个阶段只是为了建立一个线程集合点，确保所有并发回收阶段中进行的收集器线程都已完成分配给它们的对象移动任务而已，初始引用更新时间很短，会产生一个非常短暂的停顿

  7）并发引用更新（Concurrent Update Reference）

真正开始进行引用更新操作，这个阶段是与用户线程一起并发的，时间长短取决于内存中涉及的引用数量的多少。并发引用更新与并发标记不同，它不再需要沿着对象图来搜索，只需要按照内存物理地址的顺序，线性地搜索出引用类型，把旧值改为新值即可

  8）最终引用更新（Final Update Reference）

解决了堆中的引用更新之后，还要修正存在于GC Roots中的引用，这个阶段是Shenandoah的最后一次停顿，停顿时间只与GC Roots的数量有关

  9）并发清理（Concurrent Cleanup）

经过并发回收和引用更新之后，整个回收集中所有的Region已再无存活对象，这些Region都变成Immediate Garbage Regions了，最后再调用一次并发清理过程来回收这些Region的内存空间，供以后新对象分配使用

Shenandoah工作过程图示：

   （2）ZGC收集器

ZGC和Shenandoah都是希望在尽可能对吞吐量影响不大的前提下，实现任意堆内存大小都可以把垃圾收集的停顿时间限制在10毫秒以内的低延迟

特点：基于Region内存布局，不设分代，使用读屏障，染色指针技术（Colored Pointer）和内存多重映射等技术来实现可并发的标记整理算法的

与G1和Shenandoah区别：

   ZGC的Region（Page/Zpage）具有动态性（动态创建和销毁，动态的区域容量大小）

ZGC的区域具有大，中，小三类容量：

1. 小型Region（Small Region）：容量固定为2MB，用于放置小于256kb的小对象
2. 中型Region（Medium Region）：容量固定为32MB，用于放置大于等于256kb但小于4MB的对象
3. 大型Region（Large Region）：容量不固定，可以动态变化，但必须为2MB的整数倍，用于放置4MB以上的大对象，这样预示着虽然名字叫做‘大型Region’，但它的实际容量完全有可能小于中型Region，最小容量可低至4MB。大型Region在ZGC的实现中式不会被重分配的，因为复制一个大对象的代价非常高昂

         ZGC的堆内存布局图示：

第三类Epsilon收集器

是一款不能够进行垃圾收集为‘卖点’的垃圾收集器，主要作用是为了隔离垃圾收集器与java虚拟机解释，编译，监控等子系统的关系而提出的垃圾收集器的统一接口，Epsilon是这个接口的有效性验证和参考实现，同时也用于需要剥离垃圾收集器影响的性能测试和压力测试

优点：负载极小，没有任何回收行为，适应新的技术潮流（短时间，小规模的服务形式）（提前编译，面向应用的类数据共享等）

各个收集器之间的并发情况统计图示：

7.衡量垃圾收集器的三项最重要的指标是哪些？

1. 内存占用（Footprint）
2. 吞吐量（Throughput）
3. 延迟（Latency）