面试必问之jvm

  • Z时代
  • 2024-01-10
  • 分类：综合

编程

问题1 说一下jvm内存模型

问题1.1 jvm内存模型

栈区：

栈分为java虚拟机栈和本地方法栈

重点是Java虚拟机栈，它是线程私有的，生命周期与线程相同。

每个方法执行都会创建一个栈帧，用于存放局部变量表，操作栈，动态链接，方法出口等。每个方法从被调用，直到被执行完。对应着一个栈帧在虚拟机中从入栈到出栈的过程。

通常说的栈就是指局部变量表部分，存放编译期间可知的8种基本数据类型，及对象引用和指令地址。局部变量表是在编译期间完成分配，当进入一个方法时，这个栈中的局部变量分配内存大小是确定的。

会有两种异常StackOverFlowError和 OutOfMemoneyError。当线程请求栈深度大于虚拟机所允许的深度就会抛出StackOverFlowError错误；虚拟机栈动态扩展，当扩展无法申请到足够的内存空间时候，抛出OutOfMemoneyError。

本地方法栈为虚拟机使用到本地方法服务（native）

堆区：

堆被所有线程共享区域，在虚拟机启动时创建，唯一目的存放对象实例。

方法区：

被所有线程共享区域，用于存放已被虚拟机加载的类信息，常量，静态变量等数据。被Java虚拟机描述为堆的一个逻辑部分。习惯是也叫它永久代（permanment generation）

垃圾回收很少光顾这个区域，不过也是需要回收的，主要针对常量池回收，类型卸载。

常量池用于存放编译期生成的各种字节码和符号引用，常量池具有一定的动态性，里面可以存放编译期生成的常量；运行期间的常量也可以添加进入常量池中，比如string的intern()方法。

程序计数器：

当前线程所执行的行号指示器。通过改变计数器的值来确定下一条指令，比如循环，分支，跳转，异常处理，线程恢复等都是依赖计数器来完成。

Java虚拟机多线程是通过线程轮流切换并分配处理器执行时间的方式实现的。为了线程切换能恢复到正确的位置，每条线程都需要一个独立的程序计数器，所以它是线程私有的。

唯一一块Java虚拟机没有规定任何OutofMemoryError的区块。

1.2 jvm堆空间是怎么划分的

通常情况下分为两个区块年轻代和年老代。更细一点年轻代又分为Eden区最要放新创建对象，From survivor 和 To survivor 保存gc后幸存下的对象，默认情况下各自占比 8:1:1。

不过很多文章介绍分为3个区块，把方法区算着为永久代。这大概是基于Hotspot虚拟机划分，然后比如IBM j9就不存在永久代概论。不管怎么分区，都是存放对象实例。

1.3 jvm内存有哪些初始化参数

1.JVM运行时堆的大小

-Xms堆的最小值
-Xmx堆空间的最大值

2.新生代堆空间大小调整

-XX:NewSize新生代的最小值
-XX:MaxNewSize新生代的最大值
-XX:NewRatio设置新生代与老年代在堆空间的大小
-XX:SurvivorRatio新生代中Eden所占区域的大小

3.永久代大小调整

-XX:MaxPermSize

问题2 jvm垃圾回收机制有了解吗？

在java中，程序员是不需要显示的去释放一个对象的内存的，而是由虚拟机自行执行。在JVM中，有一个垃圾回收线程，它是低优先级的，在正常情况下是不会执行的，只有在虚拟机空闲或者当前堆内存不足时，才会触发执行，扫面那些没有被任何引用的对象，并将它们添加到要回收的集合中，进行回收。

问题2.1 java中垃圾收集的方法有哪些?

  1. 标记-清除:

    这是垃圾收集算法中最基础的，根据名字就可以知道，它的思想就是标记哪些要被回收的对象，然后统一回收。这种方法很简单，但是会有两个主要问题：1.效率不高，标记和清除的效率都很低；2.会产生大量不连续的内存碎片，导致以后程序在分配较大的对象时，由于没有充足的连续内存而提前触发一次GC动作。

  2. 复制算法:

    为了解决效率问题，复制算法将可用内存按容量划分为相等的两部分，然后每次只使用其中的一块，当一块内存用完时，就将还存活的对象复制到第二块内存上，然后一次性清楚完第一块内存，再将第二块上的对象复制到第一块。但是这种方式，内存的代价太高，每次基本上都要浪费一般的内存。

    于是将该算法进行了改进，内存区域不再是按照1：1去划分，而是将内存划分为8:1:1三部分，较大那份内存交Eden区，其余是两块较小的内存区叫Survior区。每次都会优先使用Eden区，若Eden区满，就将对象复制到第二块内存区上，然后清除Eden区，如果此时存活的对象太多，以至于Survivor不够时，会将这些对象通过分配担保机制复制到老年代中。(java堆又分为新生代和老年代)

  3. 标记-整理

    该算法主要是为了解决标记-清除，产生大量内存碎片的问题；当对象存活率较高时，也解决了复制算法的效率问题。它的不同之处就是在清除对象的时候现将可回收对象移动到一端，然后清除掉端边界以外的对象，这样就不会产生内存碎片了。

  4. 分代收集

    现在的虚拟机垃圾收集大多采用这种方式，它根据对象的生存周期，将堆分为新生代和老年代。在新生代中，由于对象生存期短，每次回收都会有大量对象死去，那么这时就采用复制算法。老年代里的对象存活率较高，没有额外的空间进行分配担保，所以可以使用标记-整理 或者 标记-清除。

问题2.2 jvm垃圾收集器有哪几种？

  • Serial收集器： 单线程的收集器，收集垃圾时，必须stop the world，使用复制算法。

  • ParNew收集器： Serial收集器的多线程版本，也需要stop the world，复制算法。

  • Parallel Scavenge收集器： 新生代收集器，复制算法的收集器，并发的多线程收集器，目标是达到一个可控的吞吐量。如果虚拟机总共运行100分钟，其中垃圾花掉1分钟，吞吐量就是99%。

  • Serial Old收集器： 是Serial收集器的老年代版本，单线程收集器，使用标记整理算法。

  • Parallel Old收集器： 是Parallel Scavenge收集器的老年代版本，使用多线程，标记-整理算法。

  • CMS(Concurrent Mark Sweep) 收集器： 是一种以获得最短回收停顿时间为目标的收集器，标记清除算法，运作过程：初始标记，并发标记，重新标记，并发清除，收集结束会产生大量空间碎片。

  • G1收集器： 标记整理算法实现，运作流程主要包括以下：初始标记，并发标记，最终标记，筛选标记。不会产生空间碎片，可以精确地控制停顿。

问题2.3 CMS收集器和G1收集器的区别：

  • CMS收集器是老年代的收集器，可以配合新生代的Serial和ParNew收集器一起使用；

  • G1收集器收集范围是老年代和新生代，不需要结合其他收集器使用；

  • CMS收集器以最小的停顿时间为目标的收集器；

  • G1收集器可预测垃圾回收的停顿时间

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

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

问题2.4 JVM中一次完整的GC流程是怎样的，对象如何晋升到老年代

Java堆 = 老年代 + 新生代

新生代 = Eden + S0 + S1

1、当 Eden 区的空间满了， Java虚拟机会触发一次 Minor GC，以收集新生代的垃圾，存活下来的对象，则会转移到 Survivor区。

2、大对象（需要大量连续内存空间的Java对象，如那种很长的字符串）直接进入老年态；

3、如果对象在Eden出生，并经过第一次Minor GC后仍然存活，并且被Survivor容纳的话，年龄设为1，每熬过一次Minor GC，年龄+1，若年龄超过一定限制（15），则被晋升到老年态。即长期存活的对象进入老年态。

4、老年代满了而无法容纳更多的对象，Minor GC 之后通常就会进行Full GC，Full GC 清理整个内存堆 – 包括年轻代和年老代。

5、Major GC 发生在老年代的GC，清理老年区，经常会伴随至少一次Minor GC，比Minor GC慢10倍以上。

问题2.5 什么情况下会触发fullgc

  • 老年代空间不足

    老年代空间只有在新生代对象转入及创建为大对象、大数组时才会出现不足的现象，当执行Full GC后空间仍然不足，则抛出如下错误：

    java.lang.OutOfMemoryError: Java heap space

    为避免以上两种状况引起的Full GC，调优时应尽量做到让对象在Minor GC阶段被回收、让对象在新生代多存活一段时间及不要创建过大的对象及数组。

  • 永生区空间不足

    JVM规范中运行时数据区域中的方法区，在HotSpot虚拟机中又被习惯称为永生代或者永生区，Permanet Generation中存放的为一些class的信息、常量、静态变量等数据，当系统中要加载的类、反射的类和调用的方法较多时，Permanet Generation可能会被占满，在未配置为采用CMS GC的情况下也会执行Full GC。如果经过Full GC仍然回收不了，那么JVM会抛出如下错误信息：

    java.lang.OutOfMemoryError: PermGen space

    为避免Perm Gen占满造成Full GC现象，可采用的方法为增大Perm Gen空间或转为使用CMS GC。

  • CMS GC时出现promotion failed和concurrent mode failure

    对于采用CMS进行老年代GC的程序而言，尤其要注意GC日志中是否有promotion failed和concurrent mode failure两种状况，当这两种状况出现时可能 会触发Full GC。

    promotion failed是在进行Minor GC时，survivor space放不下、对象只能放入老年代，而此时老年代也放不下造成的；concurrent mode failure是在 执行CMS GC的过程中同时有对象要放入老年代，而此时老年代空间不足造成的（有时候“空间不足”是CMS GC时当前的浮动垃圾过多导致暂时性的空间不足触发Full GC）。

    对措施为：增大survivor space、老年代空间或调低触发并发GC的比率，但在JDK 5.0+、6.0+的版本中有可能会由于JDK的bug29导致CMS在remark完毕 后很久才触发sweeping动作。对于这种状况，可通过设置-XX: CMSMaxAbortablePrecleanTime=5（单位为ms）来避免。 统计得到的Minor GC晋升到旧生代的平均大小大于老年代的剩余空间

    这是一个较为复杂的触发情况，Hotspot为了避免由于新生代对象晋升到旧生代导致旧生代空间不足的现象，在进行Minor GC时，做了一个判断，如果之 前统计所得到的Minor GC晋升到旧生代的平均大小大于旧生代的剩余空间，那么就直接触发Full GC。

    例如程序第一次触发Minor GC后，有6MB的对象晋升到旧生代，那么当下一次Minor GC发生时，首先检查旧生代的剩余空间是否大于6MB，如果小于6MB， 则执行Full GC。

    当新生代采用PS GC时，方式稍有不同，PS GC是在Minor GC后也会检查，例如上面的例子中第一次Minor GC后，PS GC会检查此时旧生代的剩余空间是否 大于6MB，如小于，则触发对旧生代的回收。

    除了以上4种状况外，对于使用RMI来进行RPC或管理的Sun JDK应用而言，默认情况下会一小时执行一次Full GC。可通过在启动时通过- java - Dsun.rmi.dgc.client.gcInterval=3600000来设置Full GC执行的间隔时间或通过-XX:+ DisableExplicitGC来禁止RMI调用System.gc。

  • 堆中分配很大的对象

    所谓大对象，是指需要大量连续内存空间的java对象，例如很长的数组，此种对象会直接进入老年代，而老年代虽然有很大的剩余空间，但是无法找到足够大的连续空间来分配给当前对象，此种情况就会触发JVM进行Full GC。 为了解决这个问题，CMS垃圾收集器提供了一个可配置的参数，即-XX:+UseCMSCompactAtFullCollection开关参数，用于在“享受”完Full GC服务之后额外免费赠送一个碎片整理的过程，内存整理的过程无法并发的，空间碎片问题没有了，但提顿时间不得不变长了，JVM设计者们还提供了另外一个参数 -XX:CMSFullGCsBeforeCompaction,这个参数用于设置在执行多少次不压缩的Full GC后,跟着来一次带压缩的。

问题2.6 怎么判断一个对象是否存活

jvm中有两种方式判断对象是否存活

  • 引用计数：每个对象有一个引用计数属性，新增一个引用时计数加1，引用释放时计数减1，计数为0时可以回收。此方法简单，无法解决对象相互循环引用的问题。

  • 可达性分析（Reachability Analysis）：从GC Roots开始向下搜索，搜索所走过的路径称为引用链。当一个对象到GC Roots没有任何引用链相连时，则证明此对象是不可用的，不可达对象。

问题2.7 哪些对象可作为GC Roots对象？

  • 虚拟机栈中应用的对象

  • 方法区里面的静态对象

  • 方法区常量池的对象

  • 本地方法栈JNI应用的对象

问题3 jvm类加载原理

问题3.1 说一下类的生命周期

java类加载过程：加载-->验证-->准备-->解析-->初始化，之后类就可以被使用了。绝大部分情况下是按这

样的顺序来完成类的加载全过程的。但是是有例外的地方，解析也是可以在初始化之后进行的，这是为了支持

java的运行时绑定，并且在一个阶段进行过程中也可能会激活后一个阶段，而不是等待一个阶段结束再进行后一个阶段。

1.加载

加载时jvm做了这三件事：

 1）通过一个类的全限定名来获取该类的二进制字节流
 2）将这个字节流的静态存储结构转化为方法区运行时数据结构
 3）在内存堆中生成一个代表该类的java.lang.Class对象，作为该类数据的访问入口

2.验证

验证、准备、解析这三步可以看做是一个连接的过程，将类的字节码连接到JVM的运行状态之中

验证是为了确保Class文件的字节流中包含的信息符合当前虚拟机的要求，不会威胁到jvm的安全

验证主要包括以下几个方面的验证：

　　1）文件格式的验证，验证字节流是否符合Class文件的规范，是否能被当前版本的虚拟机处理

 2）元数据验证，对字节码描述的信息进行语义分析，确保符合java语言规范

　　3）字节码验证 通过数据流和控制流分析，确定语义是合法的，符合逻辑的

　　4）符号引用验证 这个校验在解析阶段发生

3.准备 为类的静态变量分配内存，初始化为系统的初始值。对于final static修饰的变量，

直接赋值为用户的定义值。如下面的例子：这里在准备阶段过后的初始值为0，而不是7

public static int a=7

4.解析

解析是将常量池内的符号引用转为直接引用（如物理内存地址指针）

5.初始化

到了初始化阶段，jvm才真正开始执行类中定义的java代码

  1）初始化阶段是执行类构造器<clinit>()方法的过程。类构造器<clinit>()方法是由编译器自动收集
       类中的所有类变量的赋值动作和静态语句块(static块)中的语句合并产生的。
  2）当初始化一个类的时候，如果发现其父类还没有进行过初始化、则需要先触发其父类的初始化。
  3）虚拟机会保证一个类的<clinit>()方法在多线程环境中被正确加锁和同步。

问题3.2 说一下类加载机制

双亲委派

jvm自带三种类加载器，分别是：

启动类加载器。

扩展类加载器。

应用程序类加载器

他们的继承关系如下图：

双亲委派机制工作过程如下：

当前ClassLoader首先从自己已经加载的类中查询是否此类已经加载，如果已经加载则直接返回原来已经加载的类。每个类加载器都有自己的加载缓存，当一个类被加载了以后就会放入缓存，等下次加载的时候就可以直接返回了。

当前classLoader的缓存中没有找到被加载的类的时候，委托父类加载器去加载，父类加载器采用同样的策略，首先查看自己的缓存，然后委托父类的父类去加载，一直到bootstrp ClassLoader.

当所有的父类加载器都没有加载的时候，再由当前的类加载器加载，并将其放入它自己的缓存中，以便下次有加载请求的时候直接返回。

为啥要搞这么复杂？自己处理不好吗？

双亲委派的优点如下：

避免重复加载。当父亲已经加载了该类的时候，就没有必要子ClassLoader再加载一次。

为了安全。避免核心类，比如String被替换。

</clinit></clinit></clinit>

以上是 面试必问之jvm 的全部内容， 来源链接： utcz.com/z/517839.html

回到顶部