2020秋招面试JVM虚拟机高频问题总结问题+答案

下面是按jvm虚拟机知识点分章节总结的一些jvm学习与面试相关的一些东西。一般作为Java程序员在面试的时候一般会问的大多就是Java内存区域、虚拟机垃圾算法、虚拟垃圾收集器、JVM内存管理这些问题了。Java面试通关手册（Java学习指南）github地址（欢迎star和pull）：https://github.com/Snailclimb/Java_Guide（GITHUB 五万多星）...

丘山一郎

831人浏览 · 2019-08-27 10:04:58

丘山一郎 · 2019-08-27 10:04:58 发布

下面是按jvm虚拟机知识点分章节总结的一些jvm学习与面试相关的一些东西。一般作为Java程序员在面试的时候一般会问的大多就是Java内存区域、虚拟机垃圾算法、虚拟垃圾收集器、JVM内存管理这些问题了。
下边附面试常考问题，并且给出答案
深入理解虚拟机之Java内存区域：
1.介绍下Java内存区域（运行时数据区）。
2.对象的访问定位的两种方式。

深入理解虚拟机之垃圾回收
1.如何判断对象是否死亡（两种方法）。
2.简单的介绍一下强引用、软引用、弱引用、虚引用（虚引用与软引用和弱引用的区别、使用软引用能带来的好处）。
3.垃圾收集有哪些算法，各自的特点？
4.HotSpot为什么要分为新生代和老年代？
5.常见的垃圾回收器有那些？
6.介绍一下CMS,G1收集器。
7.Minor Gc和Full GC 有什么不同呢？

虚拟机性能监控和故障处理工具
1.JVM调优的常见命令行工具有哪些？

深入理解虚拟机之类文件结构
1.简单介绍一下Class类文件结构（常量池主要存放的是那两大常量？Class文件的继承关系是如何确定的？字段表、方法表、属性表主要包含那些信息？）

深入理解虚拟机之虚拟机类加载机制
1.简单说说类加载过程，里面执行了哪些操作？
2.对类加载器有了解吗？
3.什么是双亲委派模型？
4.双亲委派模型的工作过程以及使用它的好处。

Java面试通关手册（Java学习指南）github地址（欢迎star和pull）：https://github.com/Snailclimb/Java_Guide （GITHUB 五万多星）

一、深入理解虚拟机之Java内存区域：

1.介绍下Java内存区域（运行时数据区）。
包括五大部分：方法区、堆、程序计数器、本地方法栈、虚拟机栈
在这里插入图片描述
程序计数器
　程序计数器是一个记录着当前线程所执行的字节码的行号指示器。
线程私有。字节码解释器工作是就是通过改变这个计数器的值来选取下一条需要执行指令的字节码指令，分支、循环、跳转、异常处理、线程恢复等基础功能都需要依赖计数器完成

JAVA代码编译后的字节码在未经过JIT（实时编译器）编译前，其执行方式是通过“字节码解释器”进行解释执行。简单的工作原理为解释器读取装载入内存的字节码，按照顺序读取字节码指令。读取一个指令后，将该指令“翻译”成固定的操作，并根据这些操作进行分支、循环、跳转等流程。
　　从上面的描述中，可能会产生程序计数器是否是多余的疑问。因为沿着指令的顺序执行下去，即使是分支跳转这样的流程，跳转到指定的指令处按顺序继续执行是完全能够保证程序的执行顺序的。假设程序永远只有一个线程，这个疑问没有任何问题，也就是说并不需要程序计数器。但实际上程序是通过多个线程协同合作执行的。
　　首先我们要搞清楚JVM的多线程实现方式。JVM的多线程是通过CPU时间片轮转（即线程轮流切换并分配处理器执行时间）算法来实现的。也就是说，某个线程在执行过程中可能会因为时间片耗尽而被挂起，而另一个线程获取到时间片开始执行。当被挂起的线程重新获取到时间片的时候，它要想从被挂起的地方继续执行，就必须知道它上次执行到哪个位置，在JVM中，通过程序计数器来记录某个线程的字节码执行位置。因此，程序计数器是具备线程隔离的特性，也就是说，每个线程工作时都有属于自己的独立计数器。

Java虚拟机栈

线程私有，生命周期和线程一致。描述的是 Java 方法执行的内存模型：每个方法在执行时都会床创建一个栈帧(Stack Frame)用于存储局部变量表、操作数栈、动态链接、方法出口等信息。每一个方法从调用直至执行结束，就对应着一个栈帧从虚拟机栈中入栈到出栈的过程。

局部变量表：存放了编译期可知的各种基本类型(boolean、byte、char、short、int、float、long、double)、对象引用(reference 类型)和 returnAddress 类型(指向了一条字节码指令的地址)

StackOverflowError：线程请求的栈深度大于虚拟机所允许的深度。
OutOfMemoryError：如果虚拟机栈可以动态扩展，而扩展时无法申请到足够

本地方法栈
区别于 Java 虚拟机栈的是，Java 虚拟机栈为虚拟机执行 Java 方法(也就是字节码)服务，而本地方法栈则为虚拟机使用到的 Native 方法服务。也会有 StackOverflowError 和 OutOfMemoryError 异常。

Java 堆
对于绝大多数应用来说，这块区域是 JVM 所管理的内存中最大的一块。线程共享，主要是存放对象实例和数组。内部会划分出多个线程私有的分配缓冲区(Thread Local Allocation Buffer, TLAB)。可以位于物理上不连续的空间，但是逻辑上要连续。

方法区
属于共享内存区域，存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。

2.对象的访问定位的两种方式。
（A）、使用句柄
Java堆划分一块内存作为句柄池，reference中存储就是对象的句柄地址；

    对象句柄包含两个地址：
   （1）、在堆中分配的对象实例数据的地址；
   （2）、这个对象类型数据地址；    
    如图所示：

在这里插入图片描述
优点：对象移动时（垃圾回收时常见的动作），reference不需要修改，只改变句柄中实例数据指针；

（B）、使用直接指针
reference中存储就是在堆中分配的对象实例数据的地址；

而对象实例数据中需要有这个对象类型数据的相关信息（前面文章讨论了HotSpot使用对象头来存储对象类型数据地址）；

如图所示：
在这里插入图片描述
优点：对象访问时节省了一次指针定位的时间开销，速度更快；

由于对象访问非常频繁进行，所以能较好提升性能；

二、深入理解虚拟机之垃圾回收

1.如何判断对象是否死亡（两种方法）。
一、引用计数法
给对象添加一个引用计数器，每当有一个地方引用它时，计数器值就加1；当引用失效时，计数器值就减1；任何时刻计数器为0的对象就是不可能被再使用的。
主流的JVM里面没有选用引用计数算法来管理内存，其中最主要的原因是它很难解决对象间的互循环引用的问题。
二、可达性分析算法
通过一些列的称为“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链，当一个对象到GC Roots没有任何引用链相连时（就是从GC Roots 到这个对象是不可达），则证明此对象是不可用的。所以它们会被判定为可回收对象（例如图B中的对象既是不可达的）。
在这里插入图片描述
遍历从GC Roots开始，那么哪些对象可作为GC Roots对象？
虚拟机栈中应用的对象
方法区里面的静态对象
方法区常量池的对象
本地方法栈JNI应用的对象

在可达性分析算法中，要真正宣告一个对象死亡，至少要经历两次标记过程：
1.如果对象在进行可达性分析后发现没有与GC Roots相连接的引用链，那它将会被第一次标记并且进行一次筛选，筛选的条件是此对象是否有必要执行finalize()方法。当对象没有覆盖finalize()方法，或者finalize()方法已经被虚拟机调用过，虚拟机将这两种情况都视为“没有必要执行”。
2.如果这个对象被判定为有必要执行finalize()方法，那么这个对象将会放置在一个叫做F-Queue队列之中，并在稍后由一个由虚拟机自动建立的、低优先级的Finalizer线程去执行它。finalize()方法是对象逃脱死亡命运的最后一次机会，稍候GC将对F-Queue中的对象进行第二次小规模的标记，如果对象要在finalie()中成功拯救自己——只要重新与引用链上的任何一个对象建立关联即可，譬如把自己（this关键字）赋值给某个类变量或者对象的成员变量，那在第二次标记时它将会被移除出“即将回收”的集合；如果对象这时候还没有逃脱，那基本上它就真的被回收了。
在这里插入图片描述
2.简单的介绍一下强引用、软引用、弱引用、虚引用（虚引用与软引用和弱引用的区别、使用软引用能带来的好处）。

强引用、软引用、弱引用、虚引用，这4种引用的强度是依次递减的。

强引用：在代码中普遍存在的，类似“Object obj = new Object()”这类引用，只要强引用还在，垃圾收集器永远不会回收掉被引用的对象。

软引用：是一种相对强引用弱化一些的引用，可以让对象豁免一些垃圾收集，只有当jvm认为内存不足时，才会去试图回收软引用指向的对象。jvm会确保在抛出OutOfMemoryError之前，清理软引用指向的对象。

弱引用：非必需对象，但它的强度比软引用更弱，被弱引用关联的对象只能生存到下一次垃圾收集发生之前。

虚引用：也称为幽灵引用或幻影引用，是最弱的一种引用关系，无法通过虚引用来获取一个对象实例，为对象设置虚引用的目的只有一个，就是当着个对象被收集器回收时收到一条系统通知。

3.垃圾收集有哪些算法，各自的特点？
标记-清除算法复制算法标记-整理算法分代收集算法

标记—清除算法首先标记出需要回收的对象，在标记完成后进行统一的回收（标记即二次标记的过程）。此算法有两个不足：一是效率问题，标记和清除两个过程效率都不高；二是空间问题，标记清除后会产生大量不连续的内存碎片，内存空间碎片太多的话会导致以后程序在运行中想要分配较大对象的时候，无法找到一块连续的内存空间而导致不得不进行又一次的GC回收（后续的垃圾回收算法都是基于此算法进行改进的）。
在这里插入图片描述
复制算法
把内存按容量划分为大小相等的两块区域，每次只使用其中的一块，当这一块的内存空间用完了，就把还存活的对象复制到另一块内存中去，然后把已经使用的过的内存空间一次性清理掉。这样每次都是对半个内存区域进行GC回收，并不会产生内存碎片，但是代价是把内存缩小了一半，效率比较低。
在这里插入图片描述
标记—整理算法

标记算法一样，区别是清除的时候会把所有存活的对象向一端移动（向上和向左），然后清除掉端边界以外的内存。

在这里插入图片描述
分代收集算法根据对象存活周期的不同将内存划分为几块（新生代或老生代），然后根据每个年代的特点采用最合适的收集算法。比如在新生代中，每次都有大量对象死去，就选择复制算法；而在老生代中对象的生存率高，没有额外的空间为它进行分配担保，所以采用标记—清除算法或者标记—整理算法来进行回收。

4.HotSpot为什么要分为新生代和老年代？
JVM在程序运行过程当中，会创建大量的对象，这些对象，大部分是短周期的对象，小部分是长周期的对象，对于短周期的对象，需要频繁地进行垃圾回收以保证无用对象尽早被释放掉，对于长周期对象，则不需要频率垃圾回收以确保无谓地垃圾扫描检测。为解决这种矛盾，Sun JVM的内存管理采用分代的策略。

补充知识：JVM在堆中的垃圾收集机制
HotSpot JVM把年轻代分为了三部分：1个Eden区和2个Survivor区（分别叫from和to）。默认比例为8：1,为啥默认会是这个比例，接下来我们会聊到。一般情况下，新创建的对象都会被分配到Eden区(一些大对象特殊处理),这些对象经过第一次Minor GC后，如果仍然存活，将会被移到Survivor区。对象在Survivor区中每熬过一次Minor GC，年龄就会增加1岁，当它的年龄增加到一定程度时，就会被移动到年老代中。

因为年轻代中的对象基本都是朝生夕死的(80%以上)，所以在年轻代的垃圾回收算法使用的是复制算法，复制算法的基本思想就是将内存分为两块，每次只用其中一块，当这一块内存用完，就将还活着的对象复制到另外一块上面。复制算法不会产生内存碎片。

在GC开始的时候，对象只会存在于Eden区和名为“From”的Survivor区，Survivor区“To”是空的。紧接着进行GC，Eden区中所有存活的对象都会被复制到“To”，而在“From”区中，仍存活的对象会根据他们的年龄值来决定去向。年龄达到一定值(年龄阈值，可以通过-XX:MaxTenuringThreshold来设置)的对象会被移动到年老代中，没有达到阈值的对象会被复制到“To”区域。经过这次GC后，Eden区和From区已经被清空。这个时候，“From”和“To”会交换他们的角色，也就是新的“To”就是上次GC前的“From”，新的“From”就是上次GC前的“To”。不管怎样，都会保证名为To的Survivor区域是空的。Minor GC会一直重复这样的过程，直到“To”区被填满，“To”区被填满之后，会将所有对象移动到年老代中。
在这里插入图片描述

5.常见的垃圾回收器有那些？

下图为HotSpot虚拟机有的垃圾收集器，有连线关系的表示可以搭配使用，反之不能。
在这里插入图片描述
新生代垃圾收集器
Serial
此垃圾收集器年代久远，用于新生代的垃圾收集，采用复制算法。是单线程的垃圾收集器也就是不管你的服务器有多少CPU，反正它就用其中的一个CPU启动一个线程去处理垃圾回收，并且停止所有工作线程等待它回收完成。所以它在收集时会STW(stop the world)。能与其搭配的老年代收集器是CMS与Serial Old。
在这里插入图片描述
单线程的好处就在于它简单，没有上下文线程切换的开销。多用于桌面应用中，也就是适用于client模式。因为桌面应用一般占用的内存不大，内存不大代表需要处理的垃圾不多，所以即使单线程也能处理很快，所以感受不到STW。是client模式下默认的新生代垃圾收集器。

ParNew
此垃圾收集器可以说是Serial的多线程版本，它和Serial的差别就在于复制的时候是多线程的。
**加粗样式**
它主要是能利用多CPU，提升复制的速度，减少STW的时间。但是在单CPU情况下不要使用它，因为线程切换有开销,性能不一定会比Serial好，当然如果CPU数很多的话那性能肯定是比Serial好的。所以在Server模式下可以用它来作为新生代垃圾处理器。能与其搭配的老年代收集器是CMS与Serial Old。

Parallel Scavenge
Scavenge是捡破烂的意思…恩并行捡破烂说的是好像没错，用的也是复制算法。那不是已经在ParNew了吗，怎么还来个并行的。它和ParNew主要有两个不同点
1、Parallel Scavenge的关注点在于可控制的吞吐量，吞吐量=运行用户代码的时间/(运行用户代码的时间+GC时间)。就是说它的重点不在于想缩短每次GC的时间，而在于控制虚拟机运行一段时间中，所花费在GC上的总时间。比如程序运行了100分钟，其间垃圾收集了1分钟，那吞吐量就是99%。
2、Parallel Scavenge能自适应调节新生代中配置的参数，例如Eden和survivor比例等。其实就是因为它能自适应，所以才能可控制吞吐量，它根据实际情况动态调整这些参数来达到要求的吞吐量。
此收集器也提供了“-XX:MaxGCPauseMillis”控制垃圾收集最大停顿时间(允许值大于0)，“-XX:GCTimeRatio”吞吐量(1-99)。
看到“-XX:MaxGCPauseMillis”，别以为我们想设置多少就多少，收集器只能尽可能的保证而已。而且说白了能如果想提高新生代GC的速度，那就是减少新生代的内存空间，内存空间少垃圾肯定少处理起来肯定快。但是空间少是不是更快的容易满啊，所以所需的GC次数肯定会增多，那吞吐量也会下降。
比如说一个程序现在跑在服务器上，假设每次新生代GC时间是100毫秒，每10秒钟一次新生代GC，那一分钟花费在GC上的时间就是600毫秒。那我想每次花在GC时间更少比如60毫秒，那就减少新生代内存空间，但是这样每5秒钟一次GC，那一分钟花费在GC上的时间就是720毫秒。
对应使用的场景就是如果你的服务是计算类的，默默在后台计算，和用户交互很少，所以你肯定想的是吞吐量大，也就是总的GC时间短，能充分的用了CPU来计算，这个时候就适合用Parallel Scavenge。
那如果你的程序是交互类的，你的要求肯定就是STW的时间越短越好，能快速响应客户的请求。Parallel Scavenge也行，但是它不能和CMS联合使用呀！因为Parallel Scavenge没有使用原本HotSpot中和其它GC通用的那个GC框架，而是新框架。所以默认和CMS搭配的就是ParNew。
在这里插入图片描述
老年代垃圾收集器
Serial Old
它是Serial 收集器的老年代版本，是单线程收集，采用的是标记-整理算法。主要用于client模式和CMS的后备收集器。除了G1,上面说的几个新生代收集器都可以与它搭配使用。图请参考上面Serial。

Paraller Old
它是Parallel Scavenge的老年代版本，是多线程收集，采用的是标记-整理算法。它只能和Parallel Scavenge搭配。它的出现打破了Parallel Scavenge尴尬的地位，因为之前Parallel Scavenge只能和Serial Old配合，人家新生代都多线程跑了，奈何老年代只有单线程，拖累它了。图请参考上面Parallel Scavenge。

CMS
CMS(Concurrent Mark Sweep),从名字可以看出它采用的是标记-清除算法。它致力于减少STW的时间，让垃圾收集时同时用户线程也能并行着。在目前的Server主流垃圾收集器。
在这里插入图片描述
它的垃圾收集步骤分为以下4步：
1、初始标记(会STW)
2、并发标记
3、重新标记(会STW)
4、并发清理
初始标记就是仅标记GC Roots直接关联的对象，不继续深入标记，致力于减少STW时间。并发标记就是深入标记遍历后面所有关联对象。重新标记就是修正因并发标记阶段而发生变动了的对象标记会STW。然后就是并发清理垃圾。
所以CMS把所需消耗时间最长的深入标记阶段和清理阶段与用户线程并行。大大减少了STW所需的时间。
但是它有以下3个缺点：
1、并发阶段会与工作线程争抢CPU资源
2、空间碎片问题，因为采取的是标记-清除算法所以会产生空间碎片。为什么解决这个问题CMS提供了"-XX:+UseCMSCompactAtFullCollection"(默认开启)，用于当CMS顶不住需要进行FullGC时整理空间碎片，但是整理的过程是用户线程是得停止工作的，所以停顿的时间会变长。
3、浮动垃圾问题。因为在并发清理的时候允许用户线程继续执行，而执行就可能产生新的垃圾进入老年代，所以需要预留一部分空间给这些浮动垃圾，而当这些浮动垃圾过多在CMS运行期间爆了，那CMS就会出现“Concurrent Mode Failure”，这是时候就得后备的Serial Old上来重新进行老年代的垃圾收集，所以停顿的时间就更长了。

G1
此垃圾收集器不需要和别人配合，自己处理新生代和老年代。在jdk9中G1变为Server模式默认的垃圾收集器。它的发明就是为了替代CMS。
G1（Garbage-First）从整体来看是基于标记-整理的算法，从局部来看是基于复制算法。它和CMS一样可以和用户进程并行。相对于CMS 它的优点是首先它能建立可预测的停顿时间模型，能在一个规定的时间段内指定垃圾收集的时间不超过限制的毫秒数，并且它将Java堆分为多个大小相等的独立区域，也就是Region。虽然它还保留着分代的概念，但是新生代和老年代不是物理隔离了。它的清理区间不再是整个新生代或者老年代，而是以区域为划分，不会产生空间碎片。
G1会维护一个优先列表，根据跟踪各个region回收所能产生的空间大小和时间来标定优先级，优先回收优先级最大的Region。这就等于每次的回收目标更加精确化，提高回收的效率
G1的收集步骤可分为：
1、初始标记
2、并发标记
3、最终标记
4、筛选回收
在这里插入图片描述
初始标记和CMS一样先标记GC Roots直接关联对象，然后并发深入标记，遍历关联对象。最终标记和CMS重新标记一个概念，筛选回收也就是筛选下决定回收哪个Region价值更大。

6.介绍一下CMS,G1收集器。
答案参考上题目
7.Minor Gc和Full GC 有什么不同呢？

Minor GC 是清理年轻代
Major GC 是清理永久代。
Full GC 是清理整个堆空间—包括年轻代和永久代。

新生代 GC（Minor GC）：指发生在新生代的垃圾收集动作，因为 Java 对象大多都具
备朝生夕灭的特性，所以 Minor GC 非常频繁，一般回收速度也比较快。
老年代 GC（Major GC / Full GC）：指发生在老年代的 GC，出现了 Major GC，经常
会伴随至少一次的 Minor GC（但非绝对的，在 ParallelScavenge 收集器的收集策略里
就有直接进行 Major GC 的策略选择过程）。MajorGC 的速度一般会比 Minor GC 慢 10
倍以上。

补充知识： Minor GC ，Full GC 触发条件
Minor GC触发条件：当Eden区满时，触发Minor GC。
Full GC触发条件：
（1）调用System.gc时，系统建议执行Full GC，但是不必然执行
（2）老年代空间不足
（3）方法去空间不足
（4）通过Minor GC后进入老年代的平均大小大于老年代的可用内存
（5）由Eden区、From Space区向To Space区复制时，对象大小大于To Space可用内存，则把该对象转存到老年代，且老年代的可用内存小于该对象大小

三、虚拟机性能监控和故障处理工具

1.JVM调优的常见命令行工具有哪些？
1.jps命令:jps主要用来输出JVM中运行的进程状态信息
Java版的ps命令，查看java进程及其相关的信息，如果你想找到一个java进程的pid，那可以用jps命令替代linux中的ps命令了，简单而方便。
2.jstat命令:jstat 它可以显示出虚拟机进程中的类装载、内存、垃圾收集、JIT编译等运行数据
jstat命令是使用频率比较高的命令，主要用来查看JVM运行时的状态信息，包括内存状态、垃圾回收等。
3.jstack命令:jstack主要用来查看某个Java进程内的线程堆栈信息，jstack可以定位到线程堆栈，根据堆栈信息我们可以定位到具体代码，所以它在JVM性能调优中使用得非常多。
4.jmap:常用情况，用jmap把进程内存使用情况dump到文件中，再用jhat分析查看

四、深入理解虚拟机之类文件结构

1.简单介绍一下Class类文件结构（常量池主要存放的是那两大常量？Class文件的继承关系是如何确定的？字段表、方法表、属性表主要包含那些信息？）

Class类文件结构
Class文件是一组以8位字节为基础的二进制流，各个数据项目严格按照顺序紧凑地排列在Class文件之中，中间没有添加任何分隔符，这使得整个Class文件中存储的内容几乎全部是程序运行的必要数据，没有空隙存在。当遇到需要占用8位字节以上空间的数据项时，则会按照高位在前的方式分割成若干个8位字节进行存储。
Class文件格式采用一种类似于C语言结构体的伪结构来存储数，这种伪结构有两种数据类型：无符号数和表。
这里需要重复提一下，Class文件结构不像XML等描述语言，由于它没有任何分割符号，所以无论是数量甚至于数据存储的字节序这样的细节都被严格限定，哪个字节代表什么含义，长度是多少，先后顺序如何，都不允许改变。

常量池
紧接着主次版本号之后的是常量池入口，常量池可以理解为Class文件之中的资源仓库，它是Class文件结构中与其他项目关联最多的数据类型，也是占用Class文件空间最大的数据项目之一，同时它还是在Class文件中第一个出现的表类型数据项目。
常量池主要存放两大常量：字面量和符号引用。字面量比较接近于java语言层面的的常量概念，如文本字符串、声明为final的常量值等。而符号引用则属于编译原理方面的概念。包括下面三类常量：
类和接口的全限定名
字段的名称和描述符
方法的名称和描述符

字段表集合
字段表（field info）用于描述接口或类中声明的变量。字段包括类级变量以及实例变量，但不包括在方法内部声明的局部变量。

我们可以想一想在java中描述一个字段可以包含什么信息呢?

字段的作用域（public ,private,protected修饰符），是实例变量还是类变量（static修饰符）、可变性（final）、并发可见性（volatile修饰符，是否强制从主内存读写）、可否被序列化（transient修饰符）、字段数据类型、字段名称。上述这些信息中，各个修饰符都是布尔值，要么有某个修饰符，要么没有，很适合使用标志位来表示。而字段叫什么名字、字段被定义为什么数据类型这些都是无法固定的，只能引用常量池中常量来描述。

方法表集合
Class文件存储格式中对方法的描述与对字段的描述几乎采用了完全一致的方式。方法标的结构如同字段表一样，依次包括了访问标志、名称索引、描述符索引、属性表集合几项。
在这里稍微提一下，因为volatile修饰符和transient修饰符不可以修饰方法，所以方法表的访问标志中没有这两个对应的标志，但是增加了synchronized、native、abstract等关键字修饰方法，所以也就多了这些关键字对应的标志。

属性表集合
在Class文件，字段表，方法表中都可以携带自己的属性表集合，以用于描述某些场景专有的信息。与Class文件中其它的数据项目要求的顺序、长度和内容不同，属性表集合的限制稍微宽松一些，不再要求各个属性表具有严格的顺序，并且只要不与已有的属性名重复，任何人实现的编译器都可以向属性表中写入自己定义的属性信息，Java虚拟机运行时会忽略掉它不认识的属性。

五、深入理解虚拟机之虚拟机类加载机制

1.简单说说类加载过程，里面执行了哪些操作？
在这里插入图片描述
虚拟机把描述类的数据从class文件加载到内存，并对数据进行校验、转换解析和初始化。最终形成可以被虚拟机最直接使用的java类型的过程就是虚拟机的类加载机制。
前面总结了java编译和Class类文件的结构：java文件编译后生成class字节码文件，实现了java的一次编写到处运行的目的，但是class文件没有经过连接步骤，不包含对象在内存中的布局，那么程序执行时肯定是由虚拟机通过某种方式读取了Class类文件，并将其经过一系列步骤转换为内存中对应的存在，程序才能使用，这一过程就涉及到了类的加载。
在虚拟机实现中，类由Class文件到可用对象的转换过程包括加载、（验证、准备、解析）、初始化这几个过程，其中（验证、准备、解析）又统称连接；加载过程完成的任务主要任务是根据类的全限定名找到对应的字节码文件，将其加载到内存中；连接主要任务是完成相关的验证、为类变量分配内存、将符号引用转换为直接引用；初始化就是完成为类的静态变量和静态语句块置用户指定的初始值。
上述过程的顺序问题：加载、验证、准备、初始化这四个过程的“开始”一定是遵照顺序执行的，“解析”过程的开始可能在初始化之前，也可能在之后（实际被调用前在开始解析）。注意，说的是“开始”遵循顺序，执行过程中可能会有交叉。
jvm之java类加载机制和类加载器(ClassLoader)的详解

2.对类加载器有了解吗？
类加载器
类加载器负责加载所有的类，其为所有被载入内存中的类生成一个java.lang.Class实例对象。一旦一个类被加载如JVM中，同一个类就不会被再次载入了。正如一个对象有一个唯一的标识一样，一个载入JVM的类也有一个唯一的标识。在Java中，一个类用其全限定类名（包括包名和类名）作为标识；但在JVM中，一个类用其全限定类名和其类加载器作为其唯一标识。例如，如果在pg的包中有一个名为Person的类，被类加载器ClassLoader的实例kl负责加载，则该Person类对应的Class对象在JVM中表示为(Person.pg.kl)。这意味着两个类加载器加载的同名类：（Person.pg.kl）和（Person.pg.kl2）是不同的、它们所加载的类也是完全不同、互不兼容的。

JVM预定义有三种类加载器，当一个 JVM启动的时候，Java开始使用如下三种类加载器：
**1)根类加载器（bootstrap class loader）😗*它用来加载 Java 的核心类，是用原生代码来实现的，并不继承自 java.lang.ClassLoader（负责加载$JAVA_HOME中jre/lib/rt.jar里所有的class，由C++实现，不是ClassLoader子类）。由于引导类加载器涉及到虚拟机本地实现细节，开发者无法直接获取到启动类加载器的引用，所以不允许直接通过引用进行操作。

下面程序可以获得根类加载器所加载的核心类库,并会看到本机安装的Java环境变量指定的jdk中提供的核心jar包路径：

public class ClassLoaderTest {
 
	public static void main(String[] args) {
		
		URL[] urls = sun.misc.Launcher.getBootstrapClassPath().getURLs();
		for(URL url : urls){
			System.out.println(url.toExternalForm());
		}
	}
}

运行结果：
在这里插入图片描述
**2)扩展类加载器（extensions class loader）：**它负责加载JRE的扩展目录，lib/ext或者由java.ext.dirs系统属性指定的目录中的JAR包的类。由Java语言实现，父类加载器为null。

**3)系统类加载器（system class loader）：**被称为系统（也称为应用）类加载器，它负责在JVM启动时加载来自Java命令的-classpath选项、java.class.path系统属性，或者CLASSPATH换将变量所指定的JAR包和类路径。程序可以通过ClassLoader的静态方法getSystemClassLoader()来获取系统类加载器。如果没有特别指定，则用户自定义的类加载器都以此类加载器作为父加载器。由Java语言实现，父类加载器为ExtClassLoader。

类加载器加载Class大致要经过如下8个步骤：
1、检测此Class是否载入过，即在缓冲区中是否有此Class，如果有直接进入第8步，否则进入第2步。
2、如果没有父类加载器，则要么Parent是根类加载器，要么本身就是根类加载器，则跳到第4步，如果父类加载器存在，则进入第3步。
3、请求使用父类加载器去载入目标类，如果载入成功则跳至第8步，否则接着执行第5步。
4、请求使用根类加载器去载入目标类，如果载入成功则跳至第8步，否则跳至第7步。
5、当前类加载器尝试寻找Class文件，如果找到则执行第6步，如果找不到则执行第7步。
6、从文件中载入Class，成功后跳至第8步。
7、抛出ClassNotFountException异常。
8、返回对应的java.lang.Class对象。

3.什么是双亲委派模型？
在这里插入图片描述
双亲委派模式是在Java 1.2后引入的，其工作原理的是，如果一个类加载器收到了类加载请求，它并不会自己先去加载，而是把这个请求委托给父类的加载器去执行，如果父类加载器还存在其父类加载器，则进一步向上委托，依次递归，请求最终将到达顶层的启动类加载器，如果父类加载器可以完成类加载任务，就成功返回，倘若父类加载器无法完成此加载任务，子加载器才会尝试自己去加载，这就是双亲委派模式，即每个儿子都很懒，每次有活就丢给父亲去干，直到父亲说这件事我也干不了时，儿子自己想办法去完成，这不就是传说中的实力坑爹啊？

4.双亲委派模型的工作过程以及使用它的好处。

采用双亲委派模式的是好处是Java类随着它的类加载器一起具备了一种带有优先级的层次关系，通过这种层级关可以避免类的重复加载，当父亲已经加载了该类时，就没有必要子ClassLoader再加载一次。其次是考虑到安全因素，java核心api中定义类型不会被随意替换，假设通过网络传递一个名为java.lang.Integer的类，通过双亲委托模式传递到启动类加载器，而启动类加载器在核心Java API发现这个名字的类，发现该类已被加载，并不会重新加载网络传递的过来的java.lang.Integer，而直接返回已加载过的Integer.class，这样便可以防止核心API库被随意篡改。

六、OOM内存溢出的排查

什么是OOM
OOM为out of memory的简称，来源于java.lang.OutOfMemoryError，指程序需要的内存空间大于系统分配的内存空间，OOM后果就是程序crash；可以通俗理解：程序申请内存过大，虚拟机无法满足，然后自杀了。

导致OOM问题的原因
为什么会没有内存了呢？原因不外乎有两点：

1）分配的少了：比如虚拟机本身可使用的内存（一般通过启动时的VM参数指定）太少。

2）应用用的太多，并且用完没释放，浪费了。此时就会造成内存泄露或者内存溢出。

内存泄露：申请使用完的内存没有释放，导致虚拟机不能再次使用该内存，此时这段内存就泄露了，因为申请者不用了，而又不能被虚拟机分配给别人用。

内存溢出：申请的内存超出了JVM能提供的内存大小，此时称之为溢出。

最常见的OOM情况有以下三种：

•java.lang.OutOfMemoryError: Java heap space ------>java堆内存溢出，此种情况最常见，一般由于内存泄露或者堆的大小设置不当引起。对于内存泄露，需要通过内存监控软件查找程序中的泄露代码，而堆大小可以通过虚拟机参数-Xms,-Xmx等修改。
•java.lang.OutOfMemoryError: PermGen space 或 java.lang.OutOfMemoryError：MetaSpace ------>java方法区，（java8 元空间）溢出了，一般出现于大量Class或者jsp页面，或者采用cglib等反射机制的情况，因为上述情况会产生大量的Class信息存储于方法区。此种情况可以通过更改方法区的大小来解决，使用类似-XX:PermSize=64m -XX:MaxPermSize=256m的形式修改。另外，过多的常量尤其是字符串也会导致方法区溢出。
•java.lang.StackOverflowError ------> 不会抛OOM error，但也是比较常见的Java内存溢出。JAVA虚拟机栈溢出，一般是由于程序中存在死循环或者深度递归调用造成的，栈大小设置太小也会出现此种溢出。可以通过虚拟机参数-Xss来设置栈的大小。
排查手段
一般手段是：先通过内存映像工具对Dump出来的堆转储快照进行分析，重点是确认内存中的对象是否是必要的，也就是要先分清楚到底是出现了内存泄漏还是内存溢出。

•如果是内存泄漏，可进一步通过工具查看泄漏对象到GC Roots的引用链。这样就能够找到泄漏的对象是通过怎么样的路径与GC Roots相关联的导致垃圾回收机制无法将其回收。掌握了泄漏对象的类信息和GC Roots引用链的信息，就可以比较准确地定位泄漏代码的位置。

•如果不存在泄漏，那么就是内存中的对象确实必须存活着，那么此时就需要通过虚拟机的堆参数（ -Xmx和-Xms）来适当调大参数；从代码上检查是否存在某些对象存活时间过长、持有时间过长的情况，尝试减少运行时内存的消耗。

Java OOM问题如何排查

七、系统CPU飙高和GC频繁，如何排查？

系统运行缓慢的五种情况：

代码中某个位置读取数据量较大，导致系统内存耗尽，从而导致Full GC次数过多，系统缓慢；
代码中有比较耗CPU的操作，导致CPU过高，系统运行缓慢；相对来说，这是出现频率最高的两种线上问题，而且它们会直接导致系统不可用。另外有几种情况也会导致某个功能运行缓慢，但是不至于导致系统不可用：
代码某个位置有阻塞性的操作，导致该功能调用整体比较耗时，但出现是比较随机的；
某个线程由于某种原因而进入WAITING状态，此时该功能整体不可用，但是无法复现；
由于锁使用不当，导致多个线程进入死锁状态，从而导致系统整体比较缓慢。

系统缓慢的情况分析

通过 top命令查看CPU情况，如果CPU比较高，则通过top -Hp 命令查看当前进程的各个线程运行情况，找出CPU过高的线程之后，将其线程id转换为十六进制的表现形式，然后在jstack日志中查看该线程主要在进行的工作。这里又分为两种情况
如果是正常的用户线程，则通过该线程的堆栈信息查看其具体是在哪处用户代码处运行比较消耗CPU；
如果该线程是VM Thread，则通过jstat -gcutil 命令监控当前系统的GC状况，然后通过jmap dump:format=b,file= 导出系统当前的内存数据。导出之后将内存情况放到eclipse的mat工具中进行分析即可得出内存中主要是什么对象比较消耗内存，进而可以处理相关代码；
如果通过 top 命令看到CPU并不高，并且系统内存占用率也比较低。此时就可以考虑是否是由于另外三种情况导致的问题。具体的可以根据具体情况分析：
如果是接口调用比较耗时，并且是不定时出现，则可以通过压测的方式加大阻塞点出现的频率，从而通过jstack查看堆栈信息，找到阻塞点；
如果是某个功能突然出现停滞的状况，这种情况也无法复现，此时可以通过多次导出jstack日志的方式对比哪些用户线程是一直都处于等待状态，这些线程就是可能存在问题的线程；
如果通过jstack可以查看到死锁状态，则可以检查产生死锁的两个线程的具体阻塞点，从而处理相应的问题。

系统CPU飙高和GC频繁，如何排查？

CMS垃圾收集器

G1垃圾收集器

深入剖析JVM：G1收集器+回收流程+推荐用例

CMS垃圾收集器与G1垃圾收集器的区别

区别一：使用范围不一样
CMS收集器是老年代的收集器，可以配合新生代的Serial和ParNew收集器一起使用
G1收集器收集范围是老年代和新生代。不需要结合其他收集器使用

区别二： STW的时间
CMS收集器以最小的停顿时间为目标的收集器。

G1收集器可预测垃圾回收的停顿时间（建立可预测的停顿时间模型）

区别三：垃圾碎片
CMS收集器是使用“标记-清除”算法进行的垃圾回收，容易产生内存碎片

G1收集器使用的是“标记-整理”算法，进行了空间整合，降低了内存空间碎片。

G1回收器的特点
G1的出现就是为了替换jdk1.5种出现的CMS,这一点已经在jdk9的时候实现了，jdk9默认使用了G1回收器，移除了所有CMS相关的内容。G1和CMS相比，有几个特点：

控制回收垃圾的时间：这个是G1的优势，可以控制回收垃圾的时间，还可以建立停顿的时间模型，选择一组合适的Regions作为回收目标，达到实时收集的目的
空间整理：和CMS一样采用标记-清理的算法，但是G1不会产生空间碎片，这样就有效的使用了连续空间，不会导致连续空间不足提前造成GC的触发
G1把Java内存拆分成多等份，多个域（Region），逻辑上存在新生代和老年代的概念，但是没有严格区分
在这里插入图片描述
依旧存在新生代老年代的概念，但是没有严格区分。Region最多分为2048个