自己简历的技术栈（1）

简历：

了解JVM原理，如类加载机制、内存结构、常⻅垃圾回收算法等。

1、简单说下你对JVM的了解

        

得分点

Java跨平台、HotSpot、热点代码探测技术、内存模型、垃圾回收算法、垃圾回收器

跨平台 

Java跨平台，JVM不跨平台。 

JVM是Java语言跨平台的关键，Java在虚拟机层面隐藏了底层技术的复杂性以及机器与操作系统的差异性。运行程序的物理机千差万别，而JVM则在千差万别的物理机上面建立了统一的运行平台，实现了在任意一台JVM上编译的程序，都能在任何其他JVM上正常运行。这一极大的优势使得Java应用的开发比传统C/C++应用的开发更高效快捷，程序员可以把主要精力放在具体业务逻辑，而不是放在保障物理硬件的兼容性上。通常情况下，一个程序员只要了解了必要的Java类库、Java语法，学习适当的第三方开发框架，就已经基本满足日常开发的需要了，JVM会在用户不知不觉中完成对硬件平台的兼容及对内存等资源的管理工作。

默认Java虚拟机HotSpot 

HotSpot是Sun/OracleJDK和OpenJDK中的默认Java虚拟机，也是目前使用范围最广的Java虚拟机。HotSpot既继承了Sun之前两款商用虚拟机的优点，也有许多自己新的技术优势，如它名称中的HotSpot指的就是它的热点代码探测技术。HotSpot的热点代码探测能力可以通过执行计数器找出最具有编译价值的代码，然后通知即时编译器以方法为单位进行编译。如果一个方法被频繁调用，或方法中有效循环次数很多，将会分别触发标准即时编译和栈上替换编译行为。通过编译器与解释器恰当地协同工作，可以在最优化的程序响应时间与最佳执行性能中取得平衡，而且无须等待本地代码输出才能执行程序，即时编译的时间压力也相对减小，这样有助于引入更复杂的代码优化技术，输出质量更高的本地代码。本地方法栈和Java方法栈是合并的。

内存模型 

JVM由三部分组成：类加载子系统、运行时数据区、执行引擎。

类加载子系统：根据指定的全限定名来载入类或接口。

运行时数据区：在程序运行时，存储程序的内容，例如：字节码、对象、参数、返回值等。而运行时数据区又可以分为方法区、堆、虚拟机栈、本地方法栈、程序计数器。

执行引擎：负责执行那些包含在被载入类的方法中的指令。
 

2、说说类加载机制

得分点
加载、验证、准备、解析、初始化

标准回答 

类加载过程

加载、链接（验证、准备、解析）、初始化。这个过程是在类加载子系统完成的。

加载：生成类的Class对象。

1. 通过一个类的全限定名获取定义此类的二进制字节流（即编译时生成的类的class字节码文件）
2. 将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。包括创建运行时常量池，将类常量池的部分符号引用放入运行时常量池。
3. 在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类各种数据的访问入口。注意类的class对象是运行时生成的，类的class字节码文件是编译时生成的。

链接：将类的二进制数据合并到JRE中。该过程分为以下3个阶段：

          验证：确保代码符合JAVA虚拟机规范和安全约束。包括文件格式验证、元数据验证、字节码验证、符号引用验证。

•   文件格式验证：验证字节码文件是否符合规范。
• 魔数：是否魔数0xCAFEBABE开头
• 版本号：版本号是否在JVM兼容范围
• 常量类型：类常量池里常量类型是否合法
• 索引值：索引值是否指向不存在或不符合类型的常量。

• 元数据验证：元数据是字节码里类的全名、方法信息、字段信息、继承关系等。
• 标识符：验证类名接口名标识符有没有符合规范
• 接口实现方法：有没有实现接口的所有方法
• 抽象类实现方法：有没有实现抽象类的所有抽象方法
• final类：是不是继承了final类。

• 指令验证：主要校验类的方法体，通过数据流和控制流分析，保证方法在运行时不会危害虚拟机安全。
• 类型转换：保证方法体中的类型转换是否有效。例如把某个类强转成没继承关系的类
• 跳转指令：保证跳转指令不会跳转到方法体以外的字节码指令上；
• 保证任意时刻操作数栈的数据类型与指令代码序列都能配合工作。

符号引用验证：确保后面解析阶段能正常执行。
类全限定名地址：验证类全限定名是否能找到对应的类字节码文件
引用地址：引用指向地址是否存在实例
引用权限：是否有权引用

        准备：为类变量（即static变量）分配内存并赋零值。
        解析：将方法区-运行时常量池内的符号引用（类的名字、成员名、标识符）转为直接引用（实际内存地址，不包含任何抽象信息，因此可以直接使用）。
初始化：类变量赋初值、执行静态语句块。

一个类型从被加载到虚拟机内存中开始，到卸载出内存为止，它的整个生命周期将会经历加载、验证、准备、解析、初始化、使用、卸载七个阶段，其中验证、准备、解析三个部分统称为连接，而前五个阶段则是类加载的完整过程。

1. 在加载阶段JVM需要在内存中生成一个代表这个类的Class对象，作为方法区这个类的各种数据的访问入口。
2. 验证阶段大致上会完成下面四个阶段的检验动作：文件格式验证、元数据验证、字节码验证、符号引用验证。
3. 准备阶段是正式为类中定义变量（静态变量）分配到内存并设置类变量初始值的阶段，这些变量所使用的内存都应当在方法区中进行分配，但必须注意到方法区本身是一个逻辑上的区域。
4. 解析阶段是Java虚拟机将常量池内的符号替换为直接引用的过程，符号引用以一组符号来描述所引用的目标，直接引用是可以直接指向目标的指针、相对偏移量或者一个能间接定位到目标的句柄。
5. 类的初始化阶段是类加载过程的最后一个步骤，直到初始化阶段，Java虚拟机才真正开始执行类中编写的Java程序代码，将主导权移交给应用程序。本质上，初始化阶段就是执行类构造器的过程。并不是程序员在Java代码中直接编写的方法，它是Javac编译器的自动生成物。

加分回答
关于在什么情况下需要开始类加载过程的第一个阶段“加载”，《Java虚拟机规范》中并没有进行强制约束，这点可以交给虚拟机的具体实现来自由把握。但是对于初始化阶段，《Java虚拟机规范》则是严格规定了有且只有六种情况必须立即对类进行“初始化”：
1. 使用new实例化对象、读写类的静态字段、调用类的静态方法时。
2. 使用java.lang.reflect包的方法对类型进行反射调用时。
3. 当初始化类时，若发现其父类还没有进行过初始化，则先初始化这个父类。
4. 虚拟机启动时，需要指定一个要执行的主类，虚拟机会先初始化这个主类。
5. 当使用JDK 7新加入的动态语言支持时，如果一个java.lang.invoke.MethodHandle实例最后的解析结果为REF_getStatic、REF_putStatic、REF_invokeStatic、REF_newInvokeSpecial四种类型的方法句柄，并且这个方法句柄对应的类没有进行过初始化，则需要先触发其初始化。
6. 当一个接口中定义了JDK 8新加入的默认方法（被default关键字修饰的接口方法）时，如果有这个接口的实现类发生了初始化，那该接口要在其之前被初始化。
 

3、说说你了解的JVM内存模型（结构）

得分点 

类加载子系统、运行时数据区、执行引擎

JVM由三部分组成：类加载子系统、运行时数据区、执行引擎

1、类加载子系统

通过类加载机制加载类的class文件，如果该类是第一次加载，会执行加载、验证、解析。只负责class文件的加载，至于是否可运行，则由执行引擎决定。

类加载过程是在类加载子系统完成的：加载 --> 链接（验证 --> 准备 --> 解析） --> 初始化

2、运行时数据区

在程序运行时，存储程序的内容（例如字节码、对象、参数、返回值等）。运行时数据区包括本地方法栈、虚拟机栈、方法区、堆、程序计数器。

只有方法区和堆是各线程共享的进程内存区域，其他运行区都是每个线程可以独立拥有的。

     1、本地方法栈

存放本地方法调用过程中的栈帧。用于管理本地方法的调用，本地方法是C语言写的。不是所有虚拟机都支持本地方法栈，例如Hotspot虚拟机就是将本地方法栈和虚拟机栈合二为一。栈解决程序的运行问题，即程序如何执行、如何处理数据。

• 栈帧：栈帧是栈的元素，由三部分组成，即局部变量表（存方法参数和局部变量）、操作数栈（存方法执行过程中的中间结果，或者其他暂存数据）和帧数据区（存方法返回地址、线程引用等附加信息）。

    2、虚拟机栈

存放Java方法调用过程中的栈帧。用于管理Java方法的调用，Java方法是开发时写的Java方法。

3、方法区

可以看作是一块独立于Java堆的内存空间，方法区是各线程共享的内存区域。

• 方法区和永久代、元空间的关系：方法区是一个抽象概念，永久代和元空间是方法区的实现方式。
• 永久代：属于JVM方法区的内存，用来存储类的元数据，如类名、方法信息、字段信息等一些静态的数据。JDK7及之前方法区也叫永久代。缺点是内存大小固定，容易出现oom问题。可以通过-XX:PermSize设置永久代大小。永久代对象只能通过Major GC（又称Full GC）进行垃圾回收。
• 元空间：是Hotspot在JDK8引入的，用于取代永久代。元空间属于本地内存，由操作系统直接管理，不再受JVM管理。同时内存空间可以自动扩容，避免内存溢出。默认情况下元空间可以无限使用本地内存，也可以通过-XX:MetaspaceSize限制内存大小。
   
• 常量池：就是一张表，JVM根据这张常量表找到要执行的类信息和方法信息
• 类常量池：是.class字节码文件中的资源仓库，主要存放字面量（表示字符串值和数值，例如字符串值"abc"、final常量、静态变量）和符号引用（类和接口的全限定名、字段名、方法名）。
• 运行时常量池：类加载的“加载”阶段会创建运行时常量池，统一存放各个类常量池去重后的符号引用。在类加载的“解析”阶段JVM会把运行时常量池的这些符号引用转为直接引用。类常量池。类常量池在字节码文件中的，运行时常量池在内存中。
• 字符串常量池：专门针对String类型设计的常量池。是当前应用程序里所有线程共享的，每个jvm只有一个字符串常量池。存储字符串对象的引用。在创建String对象时，JVM会先在字符串常量池寻找是否已存在相同字符串的引用，如果有的话就直接返回引用，没的话就在堆中创建一个对象，然后常量池保存这个引用并返回引用。
   

4、堆

• 存放对象实例、实例变量、数组，包括新生代（伊甸园区、幸存区S0和S1）和老年代。堆是垃圾收集器管理的内存区域。堆解决的是数据存储的问题，即数据怎么放、放在哪儿。堆实际内存空间可以不连续，大小可以选择固定大小或可扩展，堆是各线程共享的内存区域。

5、程序计数器（PC寄存器）

• 存放下一条字节码指令的地址，由执行引擎读取下一条字节码指令并转为本地机器指令进行执行。是程序控制流（分支、循环、跳转、线程恢复）的指示器，只有它不会抛出OutOfMemoryError。每个线程有自己独立的程序计数器，以便于线程在切换回来时能知道下一条指令是什么。程序计数器生命周期与线程一致。
   

3、执行引擎

将字节码指令解释/编译为对应平台上的本地机器指令。充当了将高级语言翻译为机器语言的译者。执行引擎在执行过程中需要执行什么样的字节码指令依赖于PC寄存器。每当执行完一项指令操作后，PC寄存器就会更新下一条需要被执行的指令地址。

• 字节码指令（JVM指令）：字节码文件中的指令，内部只包含一些能够被JVM所识别的字节码指令、符号表，以及其他辅助信息，不能够直接运行在操作系统之上。
• 本地机器指令：可以直接运行在操作系统之上。

内存模型里的运行时数据区：

JVM由三部分组成：类加载子系统、执行引擎、运行时数据区。

1. 类加载子系统,可以根据指定的全限定名来载入类或接口。

2. 运行时数据区。当程序运行时,JVM需要内存来存储许多内容,例如：字节码、对象、参数、返回值、局部变量、运算的中间结果,等等,JVM会把这些东西都存储到运行时数据区中,以便于管理。而运行时数据区又可以分为方法区、堆、虚拟机栈、本地方法栈、程序计数器。

3. 执行引擎,负责执行那些包含在被载入类的方法中的指令。

加分回答-运行时数据区

运行时数据区是开发者重点要关注的部分,因为程序的运行与它密不可分,很多错误的排查也需要基于对运行时数据区的理解。在运行时数据区所包含的几块内存空间中,方法区和堆是线程之间共享的内存区域,而虚拟机栈、本地方法栈、程序计数器则是线程私有的区域,就是说每个线程都有自己的这个区域。 
 

4、说说JVM常见的垃圾回收算法

得分点

标记清除、标记复制、标记整理，比较优缺点（效率、空间浪费、调整引用、stw）、使用场景

标记清除算法、标记复制算法、标记整理算法。

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

• 标记、清除：当堆中有效内存空间被耗尽时，会STW（stop the world，暂停其他所有工作线程），然后先标记，再清除。
• 标记：可达性分析法，从GC Roots开始遍历，找到可达对象，并在对象头中进行标记。
• 清除：堆内存内从头到尾进行线性遍历，“清除”非可达对象。注意清除并不是真的置空，垃圾还在原来的位置。实际是把垃圾对象的地址维护在空闲列表，对象实例化的申请内存阶段会通过空闲列表找到合适大小的空闲内存分配给新对象。
• 优点：简单
• 缺点：
• 效率不高：需要可达性遍历和线性遍历，效率差。
• STW导致用户体验差：GC时需要暂停其他所有工作线程，用户体验差。
• 有内存碎片，要维护空闲列表：回收垃圾对象后没有整理，导致堆中出现一块块不连续的内存碎片。
• 适用场景：适合小型应用程序，内存空间不大的情况。应用程序越大越不适用这种回收算法。
   

标记复制算法(Copying) ：

标记、复制、清除：将内存空间分为两块，每次只使用一块。在进行垃圾回收时，先可达性分析法标记可达对象，然后将可达对象复制到没有被使用的那个内存块中，最后再清除当前内存块中的所有对象。后续再按同样的流程来回复制和清除。

优点：

• 垃圾多时效率高：只需可达性遍历，效率很高。
• 无内存碎片：因为有移动操作，所以内存规整。

缺点：

• 内存利用率低，浪费内存：始终有一半以上的空闲内存
• 需要调整引用地址：可达对象移动后，内存地址发生了变化，需要调整所有引用，指向移动后的地址。
• 垃圾少时效率相对差，但还是比其他算法强：如果可达对象比较多，垃圾对象比较少，那么复制算法的效率就会比较低。只为了一点垃圾而移动所有对象未免有些小题大做。所以垃圾对象多的情况下，复制算法比较适合。

适用场景：适合垃圾对象多，可达对象少的情况，这样复制耗时短。非常适合新生代的垃圾回收，因为新生代要频繁地把可达对象从伊甸园区移动到幸存区，而且是新生代满了适合再Minor GC，垃圾对象占比高，所以回收性价比非常高，一次通常可以回收70-90%的内存空间，现在的商业虚拟机都是用这种GC算法回收新生代。

标记整理算法(Mark-Compact) ：

标记、整理、清除：首先可达性分析法标记可达对象，然后将可达对象按顺序整理到内存的一端，最后清理边界外的垃圾对象。相当于内存碎片优化版的标记清楚算法，不用维护空闲列表。
优点：

• 无内存碎片：内存规整。
• 内存利用率最高：内存既规整又不用浪费一般空间。

缺点：

• 效率最低：效率比其他两种算法都低
• 需要调整引用地址：可达对象移动后，内存地址发生了变化，需要调整所有引用，指向移动后的地址。
• STW导致用户体验差：移动时需要暂停其他所有工作线程，用户体验差。

分代收集算法

将堆分为新生代、老年代不同生命周期的对象放在不同的代，采用不同的收集算法，以提高回收效率。
 

引用计数法

每个对象都保存一个引用计数器属性，用户记录对象被引用的次数。

可达性分析法

可达性分析法会以GC Roots作为起始点，然后一层一层找到所引用的对象，被找到的对象就是存活对象，那么其他不可达的对象就是垃圾对象。

总结

1. 标记清除算法

算法分为“标记”和“清除”两个阶段，首先标记出所有需要回收的对象，在标记完成后，统一回收掉所有被标记的对象，也可以反过来，标记存活的对象，统一回收所有未被标记的对象。它主要有如下两个缺点： 第一个是执行效率不稳定，如果Java堆中包含大量对象，而且其中大部分是需要被回收的，这时必须进行大量标记和清除的动作，导致标记和清除两个过程的执行效率都随对象数量增长而降低。 第二个是内存空间碎片化问题，标记、清除之后会产生大量不连续的内存碎片，空间碎片太多可能会导致当程序在运行过程中需要分配较大对象时无法找到足够的连续的内存而不得不提前触发另一次垃圾收集。
 

2. 标记复制算法

将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。对于多数对象都是可回收的情况，算法需要复制的就是占少数的存活对象，而且每次都是针对整个半区进行内存回收，分配内存时也就不用考虑有空间碎片的复杂情况，只要移动堆顶指针，按顺序分配即可。

这种复制回收算法的代价是将可用内存缩小为了原来的一半，空间浪费未免太多了一点。另外，如果内存中多数对象都是存活的，这种算法将会产生大量的内存间复制的开销。所以，现在的商用Java虚拟机大多都优先采用了这种收集算法去回收新生代。
 

3. 标记整理算法

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

如果移动存活对象，尤其是在老年代这种每次回收都有大量对象存活区域，移动存活对象并更新所有引用这些对象的地方将会是一种极为负重的操作，而且这种对象移动操作必须全程暂停用户应用程序才能进行，像这样的停顿被最初的虚拟机设计者形象地描述为“Stop The World”。
 

加分回答

目前，新生代的垃圾回收采用标记复制算法比较多，老年代的垃圾回收采用标记整理算法比较多。而标记复制算法浪费一半内存的缺点长期以来被人诟病，所以业界也有人针对该算法给出了改进的方案。

IBM公司曾有一项专门研究对新生代“朝生夕灭”的特点做了更量化的诠释——新生代中的对象有98%熬不过第一轮收集。因此并不需要按照1∶1的比例来划分新生代的内存空间。在1989年，Andrew

Appel针对具备“朝生夕灭”特点的对象，提出了一种更优化的半区复制分代策略，现在称为“Appel式回收”。

Appel式回收的具体做法是把新生代分为一块较大的Eden空间和两块较小的Survivor空间，每次分配内存只使用Eden和其中一块Survivor。发生垃圾搜集时，将Eden和Survivor中仍然存活的对象一次性复制到另外一块Survivor空间上，然后直接清理掉Eden和已用过的那块Survivor空间。

HotSpot虚拟机的Serial、ParNew等新生代收集器均采用了这种策略来设计新生代的内存布局。HotSpot虚拟机默认Eden和Survivor的大小比例是8：1：1，也即每次新生代中可用内存空间为整个新生代容量的90%（Eden的80%加上一个Survivor的10%），只有一个Survivor空间，即10%的新生代是会被“浪费”的。

98%的对象可被回收仅仅是“普通场景”下测得的数据，任何人都没有办法百分百保证每次回收都只有不多于10%的对象存活，因此Appel式回收还有一个充当罕见情况的“逃生门”的安全设计，当Survivor空间不足以容纳一次Minor

GC之后存活的对象时，就需要依赖其他内存区域（实际上大多就是老年代）进行分配担保。

对比三种垃圾回收算法：