互联网大厂面试考点————JVM

博客地址： Coding Lemon’s blog
所有文章会第一时间在博客更新！

大厂面试系列第三弹！

问题来自：八股文骚套路之JVM（重构完善版）

部分答案来自：JavaGuide

通过打星与加粗的方式对下面面试题的重要性进行评级！难度是针对互联网大厂的。

• ⭐ ：面试中不常问到，如果面试官问到尽量能答出来，答不出来也没关系。
• ⭐⭐ ：面试中不常问到，但是如果面试官问到的话，答不出来对你的印象会减分。
• ⭐⭐⭐：面试中会问到，答不出来面试有点悬。面试官会惊讶为什么你这也不会。
• ⭐⭐⭐⭐：面试高频考点。
• ⭐⭐⭐⭐⭐：面试超高频考点。四星考点和五星考点是参加十场面试，至少能有五场面试问到这些的。大家在准备面试过程中尽量把这些知识点的回答条理梳理清楚，面试官一问就开背。

1. 运行时数据区中包含哪些区域？哪些线程共享？哪些线程独享？(⭐⭐⭐⭐⭐)

JDK 1.8 之前：

JDK1.8以前，包含了：
1.线程共享的：堆、方法区
2.线程私有的：虚拟机栈、本地方法栈、程序计数器

JDK1.8：

JDK1.8以后，包含了：
1.线程共享的：堆、元空间
2.线程私有的：虚拟机栈、本地方法栈、程序计数器

JDK1.8 HotSpot JVM 将移除方法区（永久区），使用本地内存来存储类元数据信息并称之为：元空间（Metaspace）。这意味着不会再有java.lang.OutOfMemoryError: PermGen问题，也不再需要你进行调优及监控内存空间的使用。

1.1 堆

Java 虚拟机所管理的内存中最大的一块，Java 堆是所有线程共享的一块内存区域，在虚拟机启动时创建。此内存区域的唯一目的就是存放对象实例，几乎所有的对象实例以及数组都在这里分配内存。

Java 堆是垃圾收集器管理的主要区域，因此也被称作GC 堆（Garbage Collected Heap）。从垃圾回收的角度，由于现在收集器基本都采用分代垃圾收集算法，所以 Java 堆还可以细分为：新生代和老年代；再细致一点有：Eden 空间、From Survivor、To Survivor 空间等。进一步划分的目的是更好地回收内存，或者更快地分配内存。

在 JDK 7 版本及 JDK 7 版本之前，堆内存被通常分为下面三部分：

1. 新生代内存(Young Generation)
2. 老年代(Old Generation)
3. 永生代(Permanent Generation)

JDK 8 版本之后方法区（HotSpot 的永久代）被彻底移除了（JDK1.7 就已经开始了），取而代之是元空间，元空间使用的是直接内存。

1.2 方法区

方法区与 Java 堆一样，是各个线程共享的内存区域，它用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。

1.3 虚拟机栈

虚拟机栈的生命周期和线程相同，描述的是 Java 方法执行的内存模型，每次方法调用的数据都是通过栈传递的。

Java 虚拟机栈是由一个个栈帧组成，而每个栈帧中都拥有：局部变量表、操作数栈、动态链接、方法出口信息。每一个方法从调用直至执行完成的过程，就对应着一个栈帧在虚拟机栈中入栈到出栈的过程。

Java 虚拟机栈会出现两种错误：StackOverFlowError 和 OutOfMemoryError。

• StackOverFlowError： 若 Java 虚拟机栈的内存大小不允许动态扩展，那么当线程请求栈的深度超过当前 Java 虚拟机栈的最大深度的时候，就抛出StackOverFlowError 错误。
• OutOfMemoryError： Java 虚拟机栈的内存大小可以动态扩展， 如果虚拟机在动态扩展栈时无法申请到足够的内存空间，则抛出OutOfMemoryError异常。

1.4 本地方法栈

和虚拟机栈所发挥的作用非常相似，区别是： 虚拟机栈为虚拟机执行 Java 方法 （也就是字节码）服务，而本地方法栈则为虚拟机使用到的 Native 方法服务。 在 HotSpot 虚拟机中和 Java 虚拟机栈合二为一。

本地方法被执行的时候，在本地方法栈也会创建一个栈帧，用于存放该本地方法的局部变量表、操作数栈、动态链接、出口信息。

方法执行完毕后相应的栈帧也会出栈并释放内存空间，也会出现 StackOverFlowError 和 OutOfMemoryError 两种错误。

1.5 程序计数器

程序计数器是一个记录着当前线程所执行的字节码的行号指示器。

程序计数器主要有两个作用：

1. 字节码解释器通过改变程序计数器来依次读取指令，从而实现代码的流程控制，如：顺序执行、选择、循环、异常处理。
2. 在多线程的情况下，程序计数器用于记录当前线程执行的位置，从而当线程被切换回来的时候能够知道该线程上次运行到哪儿了。

2. 说一下方法区和永久代的关系。（⭐⭐⭐）

方法区和永久代的关系很像 Java 中接口和类的关系，。方法区是 Java 虚拟机规范中的定义，是一种规范，而永久代是一种实现。永久代就是 HotSpot 虚拟机对虚拟机规范中方法区的一种实现方式。

3. 讲一下 Java 创建一个对象的过程。（⭐⭐⭐⭐）

1. 类加载检查： 虚拟机遇到一条 new 指令时，首先将去检查这个指令的参数是否能在常量池中定位到这个类的符号引用，并且检查这个符号引用代表的类是否已被加载过、解析和初始化过。如果没有，那必须先执行相应的类加载过程。

系统加载 Class 类型的文件主要三步:加载->连接->初始化。连接过程又可分为三步:验证->准备->解析。

2. 分配内存： 在类加载检查通过后，接下来虚拟机将为新生对象分配内存。对象所需的内存大小在类加载完成后便可确定，为对象分配空间的任务等同于把一块确定大小的内存从 Java 堆中划分出来。分配方式有 “指针碰撞”（堆规整下适用） 和 “空闲列表”（堆不规整下适用） 两种，选择哪种分配方式由 Java 堆是否规整决定，而 Java 堆是否规整又由所采用的垃圾收集器是否带有压缩整理功能决定（“标记-清除”的堆是不规整的，“标记-整理”的堆是规整的）。

内存分配并发问题
在创建对象的时候有一个很重要的问题，就是线程安全，因为在实际开发过程中，创建对象是很频繁的事情，作为虚拟机来说，必须要保证线程是安全的，通常来讲，虚拟机采用两种方式来保证线程安全：

• CAS+失败重试： CAS 是乐观锁的一种实现方式。所谓乐观锁就是，每次不加锁而是假设没有冲突而去完成某项操作，如果因为冲突失败就重试，直到成功为止。虚拟机采用 CAS 配上失败重试的方式保证更新操作的原子性。
• TLAB： 为每一个线程预先在 Eden 区分配一块儿内存，JVM 在给线程中的对象分配内存时，首先在 TLAB 分配，当对象大于 TLAB 中的剩余内存或 TLAB 的内存已用尽时，再采用上述的 CAS 进行内存分配（就是先给每一个线程预留一块内存用着，不够再用CAS+失败重试）

3. 初始化零值： 内存分配完成后，虚拟机需要将分配到的内存空间都初始化为零值（不包括对象头），这一步操作保证了对象的实例字段在 Java 代码中可以不赋初始值就直接使用，程序能访问到这些字段的数据类型所对应的零值。

4. 设置对象头： 初始化零值完成之后，虚拟机要对对象进行必要的设置，例如这个对象是哪个类的实例、如何才能找到类的元数据信息、对象的哈希码、对象的 GC 分代年龄等信息。 这些信息存放在对象头中。 另外，根据虚拟机当前运行状态的不同，如是否启用偏向锁等，对象头会有不同的设置方式。

5. 执行 init 方法： 在上面工作都完成之后，从虚拟机的视角来看，一个新的对象已经产生了，但从 Java 程序的视角来看，对象创建才刚开始， 方法还没有执行，所有的字段都还为零。所以一般来说，执行 new 指令之后会接着执行 方法，把对象按照程序员的意愿进行初始化，这样一个真正可用的对象才算完全产生出来。

4. 对象的访问定位的两种方式（⭐⭐⭐⭐⭐）

建立对象就是为了使用对象，我们的 Java 程序通过栈上的 reference 数据来操作堆上的具体对象。对象的访问方式由虚拟机实现而定，目前主流的访问方式有使用句柄和直接指针两种：

1. 句柄： 如果使用句柄的话，那么 Java 堆中将会划分出一块内存来作为句柄池，reference 中存储的就是对象的句柄地址，而句柄中包含了对象实例数据与类型数据各自的具体地址信息；
   

2. 直接指针： 如果使用直接指针访问，那么 Java 堆对象的布局中就必须考虑如何放置访问类型数据的相关信息，而 reference 中存储的直接就是对象的地址。

这两种对象访问方式各有优势。使用句柄来访问的最大好处是 reference 中存储的是稳定的句柄地址，在对象被移动时只会改变句柄中的实例数据指针，而 reference 本身不需要修改。使用直接指针访问方式最大的好处就是速度快，它节省了一次指针定位的时间开销。

总结：其实句柄就是相当于在栈的本地变量表和实际地址之间加了一个句柄池，在对象指针改变时，只需要修改句柄池的指针指向，而不用改本地变量表中的数据。

5. 你了解分代理论吗？讲一下 Minor GC和Full GC（⭐⭐⭐⭐⭐）

分代收集理论建立在两个分代收集假说上：

1. 弱分代假说：绝大多数对象都是朝生夕灭的
2. 强分代假说：熬过越多次垃圾收集过程的对象就越难以消亡。

收集器将Java堆划分出不同的区域，将回收对象依据年龄（熬过回收的次数）分配到不同的区域中储存。原因是：这样虚拟机可以使用较低的频率来回收这个区域，兼顾了垃圾收集的时间开销和内存空间的有效利用。

设计者一般会把Java堆划分为新生代和老年代两个区域，在新生代中每次收集都有大批的对象死去，回收后存活的少量对象，会逐步晋升到老年代。
如果只对新生代进行收集的话，要考虑新生代对象可能被老年代中的对象所引用，为了找出该区域存活的对象不得不在固定的GC Roots之外再对老年代进行遍历，确保可达性分析结果的正确性。这样会对内存回收造成负担。

• 新生代 GC（Minor GC）: 指发生新生代的的垃圾收集动作，Minor GC 非常频繁，回收速度一般也比较快。

• 老年代 GC（Major GC）: 指发生在老年代的 GC，Major GC 的速度一般会比 Minor GC 的慢 10 倍以上。

• Full GC: Full GC 是清理整个堆空间—包括年轻代和老年代。

Minor GC过程：

1. 在初始阶段，新创建的对象被分配到Eden区，survivor的两块空间都为空。
2. 当Eden区满了的时候，minor garbage 被触发 。
3. 经过扫描与标记，存活的对象被复制到S0，不存活的对象被回收， 并且存活的对象年龄都增大一岁。
4. 在下一次的Minor GC中，Eden区的情况和上面一致，没有引用的对象被回收，存活的对象被复制到survivor区。当Eden 和 s0区空间满了，S0的所有的数据都被复制到S1，需要注意的是，在上次minor GC过程中移动到S0中的两个对象在复制到S1后其年龄要加1。此时Eden区S0区被清空，所有存活的数据都复制到了S1区，并且S1区存在着年龄不一样的对象。
5. 再下一次MinorGC则重复这个过程，这一次survivor的两个区对换，存活的对象被复制到S0，存活的对象年龄加1，Eden区和另一个survivor区被清空。
6. 再经过几次Minor GC之后，当存活对象的年龄达到一个阈值之后（-XX：MaxTenuringThreshold默认是15），就会被从年轻代Promotion到老年代。

MajorGC过程： MajorGC将会在老年代发生，老年代的空间将会被清除和压缩(标记-清除或者标记整理)。

6. Java 用什么方法确定哪些对象该被清理？讲一下可达性分析算法的流程。(⭐⭐⭐⭐)

这个算法的基本思想就是通过一系列的称为 “GC Roots” 的对象作为起点，从这些节点开始向下搜索，节点所走过的路径称为引用链，当一个对象到 GC Roots 没有任何引用链相连的话，则证明此对象是不可用的。

可作为 GC Roots 的对象包括下面几种:

• 虚拟机栈(栈帧中的本地变量表)中引用的对象
• 本地方法栈(Native 方法)中引用的对象
• 方法区中类静态属性引用的对象
• 方法区中常量引用的对象
• 所有被同步锁持有的对象

7.JDK 中有几种引用类型？分别的特点是什么？(⭐⭐)

1．强引用（StrongReference）
以前我们使用的大部分引用实际上都是强引用，这是使用最普遍的引用。如果一个对象具有强引用，那就类似于必不可少的生活用品，垃圾回收器绝不会回收它。当内存空间不足，Java 虚拟机宁愿抛出 OutOfMemoryError 错误，使程序异常终止，也不会靠随意回收具有强引用的对象来解决内存不足问题。
2. 软引用（SoftReference）
如果一个对象只具有软引用，那就类似于可有可无的生活用品。如果内存空间足够，垃圾回收器就不会回收它，如果内存空间不足了，就会回收这些对象的内存。只要垃圾回收器没有回收它，该对象就可以被程序使用。软引用可用来实现内存敏感的高速缓存。
软引用可以和一个引用队列（ReferenceQueue）联合使用，如果软引用所引用的对象被垃圾回收，JAVA 虚拟机就会把这个软引用加入到与之关联的引用队列中。
3. 弱引用（WeakReference）
如果一个对象只具有弱引用，那就类似于可有可无的生活用品。弱引用与软引用的区别在于：只具有弱引用的对象拥有更短暂的生命周期。在垃圾回收器线程扫描它所管辖的内存区域的过程中，一旦发现了只具有弱引用的对象，不管当前内存空间足够与否，都会回收它的内存。不过，由于垃圾回收器是一个优先级很低的线程， 因此不一定会很快发现那些只具有弱引用的对象。
弱引用可以和一个引用队列（ReferenceQueue）联合使用，如果弱引用所引用的对象被垃圾回收，Java 虚拟机就会把这个弱引用加入到与之关联的引用队列中。
4. 虚引用（PhantomReference）
"虚引用"顾名思义，就是形同虚设，与其他几种引用都不同，虚引用并不会决定对象的生命周期。如果一个对象仅持有虚引用，那么它就和没有任何引用一样，在任何时候都可能被垃圾回收。虚引用主要用来跟踪对象被垃圾回收的活动。
虚引用与软引用和弱引用的一个区别在于： 虚引用必须和引用队列（ReferenceQueue）联合使用。 当垃圾回收器准备回收一个对象时，如果发现它还有虚引用，就会在回收对象的内存之前，把这个虚引用加入到与之关联的引用队列中。程序可以通过判断引用队列中是否已经加入了虚引用，来了解被引用的对象是否将要被垃圾回收。程序如果发现某个虚引用已经被加入到引用队列，那么就可以在所引用的对象的内存被回收之前采取必要的行动。

特别注意，在程序设计中一般很少使用弱引用与虚引用，使用软引用的情况较多，这是因为软引用可以加速 JVM 对垃圾内存的回收速度，可以维护系统的运行安全，防止内存溢出（OutOfMemory）等问题的产生。

8. 标记清除、标记复制、标记整理分别是怎样清理垃圾的？各有什么优缺点？（⭐⭐⭐⭐⭐）

8.1 标记清除算法

该算法分为“标记”和“清除”阶段：首先标记出所有不需要回收的对象，在标记完成后统一回收掉所有没有被标记的对象。它是最基础的收集算法，后续的算法都是对其不足进行改进得到。
这种垃圾收集算法会带来两个明显的问题：

1. 效率问题
2. 空间问题（标记清除后会产生大量不连续的碎片）
   

8.2 标记-复制算法

为了解决效率问题，“标记-复制”收集算法出现了。它可以将内存分为大小相同的两块，每次使用其中的一块。当这一块的内存使用完后，就将还存活的对象复制到另一块去，然后再把使用的空间一次清理掉。这样就使每次的内存回收都是对内存区间的一半进行回收。

8.3 标记-整理算法

根据老年代的特点提出的一种标记算法，标记过程仍然与“标记-清除”算法一样，但后续步骤不是直接对可回收对象回收，而是让所有存活的对象向一端移动，然后直接清理掉端边界以外的内存。

8.4 分代收集算法

当前虚拟机的垃圾收集都采用分代收集算法，这种算法没有什么新的思想，只是根据对象存活周期的不同将内存分为几块。一般将 java 堆分为新生代和老年代，这样我们就可以根据各个年代的特点选择合适的垃圾收集算法。
比如在新生代中，每次收集都会有大量对象死去，所以可以选择”标记-复制“算法，只需要付出少量对象的复制成本就可以完成每次垃圾收集。而老年代的对象存活几率是比较高的，而且没有额外的空间对它进行分配担保，所以我们必须选择“标记-清除”或“标记-整理”算法进行垃圾收集。

9. JVM 中的安全点和安全区各代表什么？写屏障你了解吗？（⭐⭐⭐⭐）

安全点： JVM只有当程序运行到特定位置时才能暂停用户线程转入GC对应的流程，这个位置就是安全点。
**安全区域：**对于一些在休眠或者阻塞的线程，我们不可能让他们继续执行到下一个安全点，那么HotSpot就引入了安全区域的概念。
针对于像线程阻塞、休眠这些状态，HotSpot虚拟机将其视为处于安全区域内，在安全区域内对应的引用关系不会发生改变，因此在这个区域任意位置进行垃圾收集都是安全的。
当用户线程进入安全区域后，用户线程会标识自己已经进入了安全区域，那么jvm在进行垃圾收集时就不会考虑这些已经进入安全区域的线程，当用户线程即将离开安全区域时，会查询jvm是否即将进行垃圾回收，如果不需要那么用户线程就继续执行，否则它将会等待垃圾回收完成。

10. 并发标记要解决什么问题？并发标记带来了什么问题？如何解决并发扫描时对象消失问题？(⭐⭐⭐⭐)

并发标记: 进行 GC Roots 跟踪的过程，和用户线程一起工作，不需要暂停工作线程。
但是并发标记可能会有错标、漏标的情况。这个时候需要三色标记法。

三色标记算法，它是描述追踪式回收器的一种有用的方法，利用它可以推演回收器的正确性。 首先，我们将对象分成三种类型的。

• 黑色:根对象，或者该对象与它的子对象都被扫描
• 灰色:对象本身被扫描,但还没扫描完该对象中的子对象
• 白色:未被扫描对象，扫描完成所有对象之后，最终为白色的为不可达对象，即垃圾对象

当GC开始扫描对象时，按照如步骤进行对象的扫描：

1. 根对象被置为黑色，子对象被置为灰色。
2. 继续由灰色遍历,将已扫描了子对象的对象置为黑色。
3. 遍历了所有可达的对象后，所有可达的对象都变成了黑色。不可达的对象即为白色，需要被清理。

写入屏障（在进行并发标记时若有对象的增删）:
当黑色对象直接引用了一个白色对象后，我们就将这个黑色对象记录下来，在扫描完成后，重新对这个黑色对象扫描,这个就是增量更新（Incremental Update）

当删除了灰色对象到白色对象的直接或间接引用后，就将这个灰色对象记录下来，再以此灰色对象为根，重新扫描一次。这个就是原始快照（Snapshot At TheBeginning，SATB）

11. 对于 JVM 的垃圾收集器你有什么了解的？（⭐⭐⭐⭐）

11.1 Serial 收集器

Serial（串行）收集器,它的 “单线程” 的意义不仅仅意味着它只会使用一条垃圾收集线程去完成垃圾收集工作，更重要的是它在进行垃圾收集工作的时候必须暂停其他所有的工作线程（ “Stop The World” ），直到它收集结束。

新生代采用标记-复制算法，老年代采用标记-整理算法。

11.2 ParNew 收集器

ParNew 收集器其实就是 Serial 收集器的多线程版本，除了使用多线程进行垃圾收集外，其余行为（控制参数、收集算法、回收策略等等）和 Serial 收集器完全一样。

新生代采用标记-复制算法，老年代采用标记-整理算法。

11.3 Parallel Scavenge 收集器

Parallel Scavenge 收集器关注点是吞吐量（高效率的利用 CPU）。CMS 等垃圾收集器的关注点更多的是用户线程的停顿时间（提高用户体验）。所谓吞吐量就是 CPU 中用于运行用户代码的时间与 CPU 总消耗时间的比值。

新生代采用标记-复制算法，老年代采用标记-整理算法。

11.4 Serial Old 收集器

Serial 收集器的老年代版本，它同样是一个单线程收集器。它主要有两大用途：一种用途是在 JDK1.5 以及以前的版本中与 Parallel Scavenge 收集器搭配使用，另一种用途是作为 CMS 收集器的后备方案。

11.5 Parallel Old 收集器

Parallel Scavenge 收集器的老年代版本。使用多线程和“标记-整理”算法。在注重吞吐量以及 CPU 资源的场合，都可以优先考虑 Parallel Scavenge 收集器和 Parallel Old 收集器。

11.6 CMS 收集器

CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。它非常符合在注重用户体验的应用上使用。

CMS（Concurrent Mark Sweep）收集器是 HotSpot 虚拟机第一款真正意义上的并发收集器，它第一次实现了让垃圾收集线程与用户线程（基本上）同时工作。

从名字中的Mark Sweep这两个词可以看出，CMS 收集器是一种 **“标记-清除”**算法实现的，它的运作过程相比于前面几种垃圾收集器来说更加复杂一些。整个过程分为四个步骤：

• 初始标记： 暂停所有的其他线程，并记录下直接与 root 相连的对象，速度很快 ；
• 并发标记： 同时开启 GC 和用户线程，用一个闭包结构去记录可达对象。但在这个阶段结束，这个闭包结构并不能保证包含当前所有的可达对象。因为用户线程可能会不断的更新引用域，所以 GC 线程无法保证可达性分析的实时性。所以这个算法里会跟踪记录这些发生引用更新的地方。
• 重新标记： 重新标记阶段就是为了修正并发标记期间因为用户程序继续运行而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段的时间稍长，远远比并发标记阶段时间短
• 并发清除： 开启用户线程，同时 GC 线程开始对未标记的区域做清扫。

从它的名字就可以看出它是一款优秀的垃圾收集器，主要优点：并发收集、低停顿。
但是它有下面三个明显的缺点：

• 对 CPU 资源敏感；
• 无法处理浮动垃圾；
• 它使用的回收算法-“标记-清除”算法会导致收集结束时会有大量空间碎片产生。

11.7 G1 收集器

G1 (Garbage-First) 是一款面向服务器的垃圾收集器,主要针对配备多颗处理器及大容量内存的机器. 以极高概率满足 GC 停顿时间要求的同时,还具备高吞吐量性能特征.

• 并行与并发： G1 能充分利用 CPU、多核环境下的硬件优势，使用多个 CPU（CPU 或者 CPU 核心）来缩短 Stop-The-World 停顿时间。部分其他收集器原本需要停顿 Java 线程执行的 GC 动作，G1 收集器仍然可以通过并发的方式让 java 程序继续执行。
• 分代收集： 虽然 G1 可以不需要其他收集器配合就能独立管理整个 GC 堆，但是还是保留了分代的概念。
• 空间整合： 与 CMS 的“标记-清理”算法不同，G1 从整体来看是基于“标记-整理”算法实现的收集器；从局部上来看是基于“标记-复制”算法实现的。
• 可预测的停顿： 这是 G1 相对于 CMS 的另一个大优势，降低停顿时间是 G1 和 CMS 共同的关注点，但 G1 除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为 M 毫秒的时间片段内。

G1 收集器的运作大致分为以下几个步骤：

• 初始标记
• 并发标记
• 最终标记
• 筛选回收

G1 收集器在后台维护了一个优先列表，每次根据允许的收集时间，优先选择回收价值最大的 Region(这也就是它的名字 Garbage-First 的由来) 。 这种使用 Region 划分内存空间以及有优先级的区域回收方式，保证了 G1 收集器在有限时间内可以尽可能高的收集效率（把内存化整为零）。

12. JVM的内存分配策略？

对象的内存分分配主要是指堆上分配（也可栈上分配），对象主要分配在新生代Eden区，如果启动了本地线程分配缓冲，则按照线程优先在TLAB上分配。少数情况下也会直接分配在老年代，分配的规则不固定，取决于垃圾回收器组合以及JVM中与内存相关参数的设置。

目前以Serial/Serial Old收集器为例。

1. 对象优先在Eden区分配

大多数情况下，对象在新生代Eden区分配，当Eden区没有足够的空间，将触发一次Minor GC（新生代GC）。

2. 大对象直接进入老年代

大对象指的是需要大量连续内存空间的Java对象，比如很大的字符串以及数组。为了避免安置不下大对象提前触发GC,避免Eden和两个Survivor区发生大量的内存复制（复制算法），直接放置于老年代。

通过**-XX:PertenureSizeThreshold**参数，可以指定大于这个值的对象之机进入老年代。

3. 长期存活对象进入老年代（age==15时）

既然虚抑机采用了分代收集的思想来管理内存，那么内存回收时就必须能识别哪此时象应放在新生代，哪些对象应放在老年代中。为了做到这点，虚拟机给每个对象定义了一个对象年龄(Age) 计数器。 如果对象在Eden 出生并经过第一次Minor GC 后仍然存后，并且能被Survivor 容纳的话，将被移动到Survivor空间中，并且对象年龄设为1，对象在Survivor 区中每经过一次MinorGC, 年龄就增加1岁，当它的年龄增加到一定程度(默认为15岁)，就将会被晋升到老年代中。对象晋升老年代的年龄阈值，可以通过参数-XX:MaxTenuringThreshold 设置。

总结： 新生代对象的age达到15时，会晋升到老年代，用参数 -XX:MaxTenuringThreshold 配置，默认15。

4.动态对象年龄判断

为了能更好地适应不同程序的内存状况，虚拟机并不是永远地要求对象的年龄必须达到了MaxTenuringThreshold 才能晋升老年代，如果在Survivor 空间中相同年龄所有对象大小的总和大于Survivor 空间的一半，年龄大于或等于该年龄的对象就可以直接进入老年代，无须等到-XX:MaxTenuringThreshold 中要求的年龄。

总结： 如果Survivor空间中相同年龄所有对象大小的总和大于Survivor 空间的一半，那么年龄大于等于该年龄对象直接进入老年代。

5.空间分配担保

在发生MinorGC之前，虚拟机会先检查老年代最大可用的连续空间是否大于新生代所有对象总空间，如果这个条件成立，那么MinorGC可以确保是安全的。如果不成立，则虚拟机会查看HandlePromotionFailure设置值是否允许担保失败。如果允许，那么会继续检查老年代最大可用的连续空间是否大于历次晋升到老年代对象的平均大小，如果大于，将尝试着进行一次MinorGC，尽管这次MinorGC是有风险的；如果小于，或者HandlePromotionFail 设置不允许冒险，那这时也要改为进行一次Full GC。

下面解释一下“冒险”是冒了什么风险，前面提到过，新生代使用复制收集算法，但为了内存利用率，只使用其中一个Survivor空间来作为轮换备份，因此当出现大量对象在Minor GC 后仍然存活的情况(最极端的情况就是内存回收后新生代中所有对象都存活)，就需要老年代进行分配担保，把Suvivor 无法容纳的对象直接进人老年代。 与生活中的贷款担保类似，老年代要进行这样的担保，前提是老年代本身还有容纳这些对象的剩余空间，一共有多少对象会活下来在实际完成内存回收之前是无法明确知道的，所以只好取之前每一次回收晋升到老年代对象容量的平均大小值作为经验值，与老年代的剩余空间进行比较，决定是否进行Full GC（Stop the World） 来让老年代腾出更多空间。取平均值进行比较其实仍然是一种动态概率的手段，也就是说，如果某次Minor GC 存活后的对象突增，远远高于平均值的话，依然会导致担保失败(Handle Promotion Failure )。如果出现了HandlePromotionFailure 失败，那就只好在失败后重新发起一次Full GC。虽然担保失败时绕的圈子是最大的，但大部分情况下都还是会将HandlePromotionFailure开关打开，避免FullGC过于频繁。

13. 类的生命周期？类加载的过程了解么？加载这一步主要做了什么事情？初始化阶段中哪几种情况必须对类初始化？（⭐⭐⭐⭐⭐）

JavaGuide_类加载过程详解

14. 讲一下双亲委派模型(⭐⭐⭐⭐⭐)

即在类加载的时候，系统会首先判断当前类是否被加载过。已经被加载的类会直接返回，否则才会尝试加载。加载的时候，首先会把该请求委派该父类加载器的 loadClass() 处理，因此所有的请求最终都应该传送到顶层的启动类加载器 BootstrapClassLoader 中。当父类加载器无法处理时，才由自己来处理。当父类加载器为null时，会使用启动类加载器 BootstrapClassLoader 作为父类加载器。

双亲委派模型避免类的重复加载（JVM 区分不同类的方式不仅仅根据类名，相同的类文件被不同的类加载器加载产生的是两个不同的类），也保证了 Java 的核心 API 不被篡改。如果没有使用双亲委派模型，而是每个类加载器加载自己的话就会出现一些问题，比如我们编写一个称为 java.lang.Object 类的话，那么程序运行的时候，系统就会出现多个不同的 Object 类。
即父类加载，不重复加载。