【死磕JVM】这可能是最全的JVM面试题了-java jvm面试题

[[404599]]

1. 描述一下jvm内存模型

2.堆内存划分的空间

垃圾回收算法：标记清除、复制(多为新生代垃圾回收使用)、标记整理

3.如何解决线上gc频繁的问题?

查看监控，以了解出现问题的时间点以及当前FGC的频率(可对比正常情况看频率是否正常)
了解该时间点之前有没有程序上线、基础组件升级等情况。
了解JVM的参数设置，包括：堆空间各个区域的大小设置，新生代和老年代分别采用了哪些垃圾收集器，然后分析JVM参数设置是否合理。
再对步骤1中列出的可能原因做排除法，其中元空间被打满、内存泄漏、代码显式调用gc方法比较容易排查。
针对大对象或者长生命周期对象导致的FGC，可通过 jmap -histo 命令并结合dump堆内存文件作进一步分析，需要先定位到可疑对象。
通过可疑对象定位到具体代码再次分析，这时候要结合GC原理和JVM参数设置，弄清楚可疑对象是否满足了进入到老年代的条件才能下结论。

4.描述一下class初始化过程?

一个类初始化就是执行clinit()方法，过程如下：

父类初始化
static变量初始化/static块(按照文本顺序执行)

Java Language Specification中，类初始化详细过程如下(最重要的是类初始化是线程安全的)：

每个类都有一个初始化锁LC，进程获取LC(如果没有获取到，就一直等待)
如果C正在被其他线程初始化，释放LC并等待C初始化完成
如果C正在被本线程初始化，即递归初始化，释放LC
如果C已经被初始化了，释放LC
如果C处于erroneous状态，释放LC并抛出异常NoClassDefFoundError
否则，将C标记为正在被本线程初始化，释放LC;然后，初始化那些final且为基础类型的类成员变量
初始化C的父类SC和各个接口SI_n(按照implements子句中的顺序来) ;如果SC或SIn初始化过程中抛出异常，则获取LC，将C标记为erroneous，并通知所有线程，然后释放LC，然后再抛出同样的异常。
从classloader处获取assertion是否被打开
接下来，按照文本顺序执行类变量初始化和静态代码块，或接口的字段初始化，把它们当作是一个个单独的代码块。
如果执行正常，获取LC，标记C为已初始化，并通知所有线程，然后释放LC
否则，如果抛出了异常E。若E不是Error，则以E为参数创建新的异常ExceptionInInitializerError作为E。如果因为OutOfMemoryError导致无法创建ExceptionInInitializerError，则将OutOfMemoryError作为E。
获取LC，将C标记为erroneous，通知所有等待的线程，释放LC，并抛出异常E

5.简述一下内存溢出的原因，如何排查线上问题?

内存溢出的原因

java.lang.OutOfMemoryError: ......java heap space. 堆栈溢出，代码问题的可能性极大
java.lang.OutOfMemoryError: GC over head limit exceeded 系统处于高频的GC状态，而且回收的效果依然不佳的情况，就会开始报这个错误，这种情况一般是产生了很多不可以被释放的对象，有可能是引用使用不当导致，或申请大对象导致，但是java heap space的内存溢出有可能提前不会报这个错误，也就是可能内存就直接不够导致，而不是高频GC.
java.lang.OutOfMemoryError: PermGen space jdk1.7之前才会出现的问题，原因是系统的代码非常多或引用的第三方包非常多、或代码中使用了大量的常量、或通过intern注入常量、或者通过动态代码加载等方法，导致常量池的膨胀
java.lang.OutOfMemoryError: Direct buffer memory 直接内存不足，因为jvm垃圾回收不会回收掉直接内存这部分的内存，所以可能原因是直接或间接使用了ByteBuffer中的allocateDirect方法的时候，而没有做clear
java.lang.StackOverflowError - Xss设置的太小了
java.lang.OutOfMemoryError: unable to create new native thread 堆外内存不足，无法为线程分配内存区域
java.lang.OutOfMemoryError: request {} byte for {}out of swap 地址空间不够

6.jvm有哪些垃圾回收器，实际中如何选择?

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

新生代收集器(全部的都是复制算法)：Serial、ParNew、Parallel Scavenge

老年代收集器：CMS(标记-清理)、Serial Old(标记-整理)、Parallel Old(标记整理) 整堆收集器：G1(一个Region中是标记-清除算法，2个Region之间是复制算法)

同时，先解释几个名词：

并行(Parallel)：多个垃圾收集线程并行工作，此时用户线程处于等待状态
并发(Concurrent)：用户线程和垃圾收集线程同时执行
吞吐量：运行用户代码时间/(运行用户代码时间+垃圾回收时间)

1.Serial收集器是最基本的、发展历史最悠久的收集器。

特点：单线程、简单高效(与其他收集器的单线程相比)，对于限定单个CPU的环境来说，Serial收集器由于没有线程交互的开销，专心做垃圾收集自然可以获得最高的单线程手机效率。收集器进行垃圾回收时，必须暂停其他所有的工作线程，直到它结束(Stop The World)。

应用场景：适用于Client模式下的虚拟机。

Serial / Serial Old收集器运行示意图：

2.ParNew收集器其实就是Serial收集器的多线程版本。

除了使用多线程外其余行为均和Serial收集器一模一样(参数控制、收集算法、Stop The World、对象分配规则、回收策略等)。

特点：多线程、ParNew收集器默认开启的收集线程数与CPU的数量相同，在CPU非常多的环境中，可以使用-XX:ParallelGCThreads参数来限制垃圾收集的线程数。

和Serial收集器一样存在Stop The World问题

应用场景： ParNew收集器是许多运行在Server模式下的虚拟机中首选的新生代收集器，因为它是除了 Serial收集器外，唯一一个能与CMS收集器配合工作的。

ParNew/Serial Old组合收集器运行示意图如下：

3.Parallel Scavenge 收集器与吞吐量关系密切，故也称为吞吐量优先收集器。

特点：属于新生代收集器也是采用复制算法的收集器，又是并行的多线程收集器(与ParNew收集器类似)。该收集器的目标是达到一个可控制的吞吐量。还有一个值得关注的点是：GC自适应调节策略(与 ParNew收集器最重要的一个区别)

GC自适应调节策略： Parallel Scavenge收集器可设置-XX:+UseAdptiveSizePolicy参数。当开关打开时不需要手动指定新生代的大小(-Xmn)、Eden与Survivor区的比例(-XX:SurvivorRation)、晋升老年代的对象年龄(-XX:PretenureSizeThreshold)等，虚拟机会根据系统的运行状况收集性能监控信息，动态设置这些参数以提供最优的停顿时间和最高的吞吐量，这种调节方式称为GC的自适应调节策略。

Parallel Scavenge收集器使用两个参数控制吞吐量：XX:MaxGCPauseMillis 控制最大的垃圾收集停顿时间 XX:GCRatio 直接设置吞吐量的大小。

4.Serial Old是Serial收集器的老年代版本。

特点：同样是单线程收集器，采用标记-整理算法。

应用场景：主要也是使用在Client模式下的虚拟机中。也可在Server模式下使用。Server模式下主要的两大用途(在后续中详细讲解···)：

在JDK1.5以及以前的版本中与Parallel Scavenge收集器搭配使用。

作为CMS收集器的后备方案，在并发收集Concurent Mode Failure时使用。

Serial / Serial Old收集器工作过程图(Serial收集器图示相同)：

5.Parallel Old是Parallel Scavenge收集器的老年代版本。

特点：多线程，采用标记-整理算法。

应用场景：注重高吞吐量以及CPU资源敏感的场合，都可以优先考虑Parallel Scavenge+Parallel Old 收集器。

6.CMS收集器是一种以获取最短回收停顿时间为目标的收集器。

特点：基于标记-清除算法实现。并发收集、低停顿。

应用场景：适用于注重服务的响应速度，希望系统停顿时间最短，给用户带来更好的体验等场景下。如web程序、b/s服务。

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

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

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

重新标记：为了修正并发标记期间因用户程序继续运行而导致标记产生变动的那一部分对象的标记记录。仍然存在Stop The World问题。

并发清除：对标记的对象进行清除回收。CMS收集器的内存回收过程是与用户线程一起并发执行的。

CMS收集器的工作过程图：

CMS收集器的缺点：

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

7.G1收集器一款面向服务端应用的垃圾收集器。

特点如下：

并行与并发：G1能充分利用多CPU、多核环境下的硬件优势，使用多个CPU来缩短Stop-The-World停顿时间。部分收集器原本需要停顿Java线程来执行GC动作，G1收集器仍然可以通过并发的方式让Java程序继续运行。

分代收集：G1能够独自管理整个Java堆，并且采用不同的方式去处理新创建的对象和已经存活了一段时间、熬过多次GC的旧对象以获取更好的收集效果。

空间整合：G1运作期间不会产生空间碎片，收集后能提供规整的可用内存。

可预测的停顿：G1除了追求低停顿外，还能建立可预测的停顿时间模型。能让使用者明确指定在一个长度为M毫秒的时间段内，消耗在垃圾收集上的时间不得超过N毫秒。

G1收集器运行示意图：

关于gc的选择除非应用程序有非常严格的暂停时间要求，否则请先运行应用程序并允许VM选择收集器(如果没有特别要求。使用VM提供给的默认GC就好)。

如有必要，调整堆大小以提高性能。如果性能仍然不能满足目标，请使用以下准则作为选择收集器的起点：

如果应用程序的数据集较小(最大约100 MB)，则选择带有选项-XX：+ UseSerialGC的串行收集器。
如果应用程序将在单个处理器上运行，并且没有暂停时间要求，则选择带有选项-XX：+UseSerialGC的串行收集器
如果(a)峰值应用程序性能是第一要务，并且(b)没有暂停时间要求或可接受一秒或更长时间的暂停，则让VM选择收集器或使用-XX：+ UseParallelGC选择并行收集器。
如果响应时间比整体吞吐量更重要，并且垃圾收集暂停时间必须保持在大约一秒钟以内，则选择具有-XX：+ UseG1GC。(值得注意的是JDK9中CMS已经被Deprecated，不可使用!移除该选项)
如果使用的是jdk8，并且堆内存达到了16G，那么推荐使用G1收集器，来控制每次垃圾收集的时间。
如果响应时间是高优先级，或使用的堆非常大，请使用-XX：UseZGC选择完全并发的收集器。(值得注意的是JDK11开始可以启动ZGC，但是此时ZGC具有实验性质，在JDK15中
[202009发布]才取消实验性质的标签，可以直接显示启用，但是JDK15默认GC仍然是G1)

这些准则仅提供选择收集器的起点，因为性能取决于堆的大小，应用程序维护的实时数据量以及可用处理器的数量和速度。如果推荐的收集器没有达到所需的性能，则首先尝试调整堆和新生代大小以达到所需的目标。如果性能仍然不足，尝试使用其他收集器总体原则：减少STOP THE WORD时间，使用并发收集器(比如CMS+ParNew，G1)来减少暂停时间，加快响应时间，并使用并行收集器来增加多处理器硬件上的总体吞吐量。

7. 简述一下Java类加载模型?

双亲委派模型在某个类加载器加载class文件时，它首先委托父加载器去加载这个类，依次传递到顶层类加载器(Bootstrap)。如果顶层加载不了(它的搜索范围中找不到此类)，子加载器才会尝试加载这个类。双亲委派的好处

每一个类都只会被加载一次，避免了重复加载
每一个类都会被尽可能的加载(从引导类加载器往下，每个加载器都可能会根据优先次序尝试加载它)
有效避免了某些恶意类的加载(比如自定义了Java.lang.Object类，一般而言在双亲委派模型下会加载系统的Object类而不是自定义的Object类)

8. JVM8为什么要增加元空间，带来什么好处?

原因：

字符串存在永久代中，容易出现性能问题和内存溢出。
类及方法的信息等比较难确定其大小，因此对于永久代的大小指定比较困难，太小容易出现永久代溢出，太大则容易导致老年代溢出。
永久代会为 GC 带来不必要的复杂度，并且回收效率偏低。

元空间的特点：

每个加载器有专门的存储空间。
不会单独回收某个类。
元空间里的对象的位置是固定的。
如果发现某个加载器不再存货了，会把相关的空间整个回收。

9. 堆G1垃圾收集器有了解么，有什么特点

G1的特点：

G1的设计原则是"首先收集尽可能多的垃圾(Garbage First)"。因此，G1并不会等内存耗尽(串行、并行)或者快耗尽(CMS)的时候开始垃圾收集，而是在内部采用了启发式算法，在老年代找出具有高收集收益的分区进行收集。同时G1可以根据用户设置的暂停时间目标自动调整年轻代和总堆大小，暂停目标越短年轻代空间越小、总空间就越大;
G1采用内存分区(Region)的思路，将内存划分为一个个相等大小的内存分区，回收时则以分区为单位进行回收，存活的对象复制到另一个空闲分区中。由于都是以相等大小的分区为单位进行操作，因此G1天然就是一种压缩方案(局部压缩);
G1虽然也是分代收集器，但整个内存分区不存在物理上的年轻代与老年代的区别，也不需要完全独立的survivor(to space)堆做复制准备。G1只有逻辑上的分代概念，或者说每个分区都可能随G1的运行在不同代之间前后切换;
G1的收集都是STW的，但年轻代和老年代的收集界限比较模糊，采用了混合(mixed)收集的方式。即每次收集既可能只收集年轻代分区(年轻代收集)，也可能在收集年轻代的同时，包含部分老年代分区(混合收集)，这样即使堆内存很大时，也可以限制收集范围，从而降低停顿。
因为G1建立可预测的停顿时间模型，所以每一次的垃圾回收时间都可控，那么对于大堆(16G左右)的垃圾收集会有明显优势

10. 介绍一下垃圾回收算法?

标记-清除

缺点：产生内存碎片，如上图，如果清理了两个1kb的对象，再添加一个2kb的对象，无法放入这两个位置

标记-整理(老年代)

缺点：移动对象开销较大

复制(新生代)

11. Happens-Before规则?

先行发生原则(Happens-Before)是判断数据是否存在竞争、线程是否安全的主要依据。先行发生是Java内存，模型中定义的两项操作之间的偏序关系，如果操作A先行发生于操作B，那么操作A产生的影响能够被操作B观察到。

口诀：如果两个操作之间具有happen-before关系，那么前一个操作的结果就会对后面的一个操作可见。是Java内存模型中定义的两个操作之间的偏序关系。

常见的happen-before规则：

1.程序顺序规则：一个线程中的每个操作，happen-before在该线程中的任意后续操作。(注解：如果只有一个线程的操作，那么前一个操作的结果肯定会对后续的操作可见。)程序顺序规则中所说的每个操作happen-before于该线程中的任意后续操作并不是说前一个操作必须要在后一个操作之前执行，而是指前一个操作的执行结果必须对后一个操作可见，如果不满足这个要求那就不允许这两个操作进行重排序

2.锁规则：对一个锁的解锁，happen-before在随后对这个锁加锁。(注解：这个最常见的就是synchronized方法和syncronized块)

3.volatile变量规则：对一个volatile域的写，happen-before在任意后续对这个volatile域的读。该规则在CurrentHashMap的读操作中不需要加锁有很好的体现。

4.传递性：如果A happen-before B，且B happen-before C，那么A happen - before C.

5.线程启动规则：Thread对象的start()方法happen-before此线程的每一个动作。

6.线程终止规则：线程的所有操作都happen-before对此线程的终止检测，可以通过Thread.join()方法结束，Thread.isAlive()的返回值等手段检测到线程已经终止执行。

7.线程中断规则：对线程interrupt()方法的调用happen-before发生于被中断线程的代码检测到中断时事件的发生。

12. 描述一下java类加载和初始化的过程?

JAVA类的加载机制：Java类加载分为5个过程,分别为：加载，链接(验证，准备，解析)，初始化，使用，卸载。

加载：加载主要是将.class文件通过二进制字节流读入到JVM中。在加载阶段，JVM需要完成3件事：1)通过classloader在classpath中获取XXX.class文件，将其以二进制流的形式读入内存。2)将字节流所代表的静态存储结构转化为方法区的运行时数据结构;3)在内存中生成一个该类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口。

链接

2.1. 验证主要确保加载进来的字节流符合JVM规范。验证阶段会完成以下4个阶段的检验动作：

1)文件格式验证

2)元数据验证(是否符合Java语言规范)

3)字节码验证(确定程序语义合法，符合逻辑)

4)符号引用验证(确保下一步的解析能正常执行

2.2. 准备准备是连接阶段的第二步，主要为静态变量在方法区分配内存，并设置默认初始值。

2.3. 解析解析是连接阶段的第三步，是虚拟机将常量池内的符号引用替换为直接引用的过程。

初始化初始化阶段是类加载过程的最后一步，主要是根据程序中的赋值语句主动为类变量赋值。当有继承关系时，先初始化父类再初始化子类，所以创建一个子类时其实内存中存在两个对象实例。

使用程序之间的相互调用。

卸载即销毁一个对象，一般情况下中有JVM垃圾回收器完成。代码层面的销毁只是将引用置为null。

13. 吞吐量优先和响应时间优先的回收器是哪些?

吞吐量优先：Parallel Scavenge+Parallel Old(多线程并行)
响应时间优先：cms+par new(并发回收垃圾)

14. 什么叫做阻塞队列的有界和无界，实际中有用过吗?

ArrayBlockingQueue：一个由数组结构组成的有界阻塞队列，线程池，生产者消费者
LinkedBlockingQueue：一个由链表结构组成的无界阻塞队列，线程池，生产者消费者
PriorityBlockingQueue：一个支持优先级排序的无界阻塞队列，可以实现精确的定时任务
DelayQueue：一个使用优先级队列实现的无界阻塞队列，可以实现精确的定时任务
SynchronousQueue：一个不存储元素的阻塞队列，线程池
LinkedTransferQueue：一个由链表结构组成的无界阻塞队列
LinkedBlockingDeque：一个由链表结构组成的双向无界阻塞队列，可以用在“工作窃取”模式中

15. jvm监控系统是通过jmx做的么?

一般都是，但是要是记录比较详细的性能定位指标，都会导致进入 safepoint，从而降低了线上应用性能例如 jstack，jmap打印堆栈，打印内存使用情况，都会让 jvm 进入safepoint，才能获取线程稳定状态从而采集信息。同时，JMX暴露向外的接口采集信息，例如使用jvisualvm，还会涉及rpc和网络消耗，以及JVM忙时，无法采集到信息从而有指标断点。这些都是基于 JMX 的外部监控很难解决的问题。所以，推荐使用JVM内部采集 JFR，这样即使在JVM很忙时，也能采集到有用的信息

16. 内存屏障的汇编指令是啥?

硬件内存屏障 X86
sfence: store| 在sfence指令前的写操作当必须在sfence指令后的写操作前完成。
lfence： load | 在lfence指令前的读操作当必须在lfence指令后的读操作前完成。
mfence： modify/mix | 在mfence指令前的读写操作当必须在mfence指令后的读写操作前完成。2.原子指令，如x86上的”lock …” 指令是一个Full Barrier，执行时会锁住内存子系统来确保执行顺序，甚至跨多个CPU。Software Locks通常使用了内存屏障或原子指令来实现变量可见性和保持程序顺序。3.JVM级别如何规范(JSR133)

LoadLoad屏障：对于这样的语句Load1; LoadLoad; Load2，在Load2及后续读取操作要读取的数据被访问前，保证Load1要读取的数据被读取完毕。

StoreStore屏障：对于这样的语句Store1; StoreStore; Store2，在Store2及后续写入操作执行前，保证Store1的写入操作对其它处理器可见。

LoadStore屏障：对于这样的语句Load1; LoadStore; Store2，在Store2及后续写入操作被刷出前，保证Load1要读取的数据被读取完毕。

StoreLoad屏障：对于这样的语句Store1; StoreLoad; Load2，在Load2及后续所有读取操作执行前，保证Store1的写入对所有处理器可见。

本文转载自微信公众号「牧小农」，可以通过以下二维码关注。转载本文请联系牧小农公众号。