JVM基础面试题

1.什么情况下会发生栈内存溢出。

常见是递归，在递归调用一个函数时，每次都会将局部变量等存到栈中，在过程中变量不会被释放只会累加，直到溢出为止。

2.JVM 的内存结构，Eden 和 Survivor 比例。

Eden，From Survivor和To Survivor分别为8:1:1。

3.jvm 中一次完整的 GC 流程是怎样的，对象如何晋升到老年代。

  1. 对象首先进入新生代(Eden)通过minor gc后，把存活的移到From Survivor，年龄+1
  2. 第二次minor gc会把Eden，From Survivor存活的对象移动到To Survivor，To更名为From，年龄+1
  3. 以此类推，直到年龄大于15就会将这个对象移到老年代。

4.你知道哪几种垃圾收集器，各自的优缺点，重点讲下 cms，包括原理，流程，优缺点

  1. Serial收集器

    Serial收集器是一个新生代收集器，单线程执行，使用复制算法。它在进行垃圾收集时，必须暂停其他所有的工作线程(用户线程)也就是传说中的Stop The World。是Jvm client模式下默认的新生代收集器。对于限定单个CPU的环境来说，Serial收集器由于没有线程交互的开销，专心做垃圾收集自然可以获得最高的单线程收集效率。

  2. ParNew收集器

    ParNew收集器其实就是serial收集器的多线程版本，除了使用多条线程进行垃圾收集之外，其余行为与Serial收集器一样。 使用方式可以使用-XX:+UseConcMarkSweepGC，或者是使用-XX:+UseParNewGC来强制开启，可以通过-XX:ParallelGCThreads 来调整或者限制垃圾收集的线程数量。

  3. Parallel Scavenge收集器

    Parallel Scavenge收集器也是一个新生代收集器，它也是使用复制算法的收集器，又是并行多线程收集器。parallel Scavenge收集器的特点是它的关注点与其他收集器不同，CMS等收集器的关注点是尽可能地缩短垃圾收集时用户线程的停顿时间，而parallel Scavenge收集器的目标则是达到一个可控制的吞吐量。吞吐量= 程序运行时间/(程序运行时间 + 垃圾收集时间)，虚拟机总共运行了100分钟。其中垃圾收集花掉1分钟，那吞吐量就是99%。

  4. Serial Old收集器

    Serial Old是Serial收集器的老年代版本，它同样是一个单线程收集器，使用“标记－整理”算法。这个收集器的主要意义也是在于给Client模式下的虚拟机使用。如果在Server模式下，那么它主要还有两大用途：一种用途是在JDK 1.5以及之前的版本中与Parallel Scavenge收集器搭配使用，另一种用途就是作为CMS收集器的后备预案，在并发收集发生Concurrent Mode Failure时使用。这两点都将在后面的内容中详细讲解。

  5. Parallel Old 收集器

    Parallel Old是Parallel Scavenge收集器的老年代版本，使用多线程和“标记－整理”算法。这个收集器是在JDK 1.6中才开始提供的，在此之前，新生代的Parallel Scavenge收集器一直处于比较尴尬的状态。原因是，如果新生代选择了Parallel Scavenge收集器，老年代除了Serial Old（PS MarkSweep）收集器外别无选择（还记得上面说过Parallel Scavenge收集器无法与CMS收集器配合工作吗？）。由于老年代Serial Old收集器在服务端应用性能上的“拖累”，使用了Parallel Scavenge收集器也未必能在整体应用上获得吞吐量最大化的效果，由于单线程的老年代收集中无法充分利用服务器多CPU的处理能力，在老年代很大而且硬件比较高级的环境中，这种组合的吞吐量甚至还不一定有ParNew加CMS的组合“给力”。

    直到Parallel Old收集器出现后，“吞吐量优先”收集器终于有了比较名副其实的应用组合，在注重吞吐量以及CPU资源敏感的场合，都可以优先考虑Parallel Scavenge加Parallel Old收集器。

  6. CMS 收集器

    CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。目前很大一部分的Java应用集中在互联网站或者B/S系统的服务端上，这类应用尤其重视服务的响应速度，希望系统停顿时间最短，以给用户带来较好的体验。CMS收集器就非常符合这类应用的需求。

    从名字（包含“Mark Sweep”）上就可以看出，CMS收集器是基于“标记—清除”算法实现的，它的运作过程相对于前面几种收集器来说更复杂一些，整个过程分为4个步骤，包括：

    初始标记（CMS initial mark）

    并发标记（CMS concurrent mark）

    重新标记（CMS remark）

    并发清除（CMS concurrent sweep）

    其中，初始标记、重新标记这两个步骤仍然需要“Stop The World”。初始标记仅仅只是标记一下GC Roots能直接关联到的对象，速度很快，并发标记阶段就是进行GC Roots Tracing的过程，而重新标记阶段则是为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段稍长一些，但远比并发标记的时间短。

    CMS收集器无法处理浮动垃圾（Floating Garbage），可能出现“Concurrent Mode Failure”失败而导致另一次Full GC的产生。由于CMS并发清理阶段用户线程还在运行着，伴随程序运行自然就还会有新的垃圾不断产生，这一部分垃圾出现在标记过程之后，CMS无法在当次收集中处理掉它们，只好留待下一次GC时再清理掉。这一部分垃圾就称为“浮动垃圾”。也是由于在垃圾收集阶段用户线程还需要运行，那也就还需要预留有足够的内存空间给用户线程使用，因此CMS收集器不能像其他收集器那样等到老年代几乎完全被填满了再进行收集，需要预留一部分空间提供并发收集时的程序运作使用。在JDK 1.5的默认设置下，CMS收集器当老年代使用了68%的空间后就会被激活，这是一个偏保守的设置，如果在应用中老年代增长不是太快，可以适当调高参数-XX:CMSInitiatingOccupancyFraction的值来提高触发百分比，以便降低内存回收次数从而获取更好的性能，在JDK 1.6中，CMS收集器的启动阈值已经提升至92%。要是CMS运行期间预留的内存无法满足程序需要，就会出现一次“Concurrent Mode Failure”失败，这时虚拟机将启动后备预案：临时启用Serial Old收集器来重新进行老年代的垃圾收集，这样停顿时间就很长了。所以说参数-XX:CMSInitiatingOccupancyFraction设置得太高很容易导致大量“Concurrent Mode Failure”失败，性能反而降低。

    CMS是一款基于“标记—清除”算法实现的收集器，如果读者对前面这种算法介绍还有印象的话，就可能想到这意味着收集结束时会有大量空间碎片产生。空间碎片过多时，将会给大对象分配带来很大麻烦，往往会出现老年代还有很大空间剩余，但是无法找到足够大的连续空间来分配当前对象，不得不提前触发一次Full GC。为了解决这个问题，CMS收集器提供了一个-XX:+UseCMSCompactAtFullCollection开关参数（默认就是开启的），用于在CMS收集器顶不住要进行FullGC时开启内存碎片的合并整理过程，内存整理的过程是无法并发的，空间碎片问题没有了，但停顿时间不得不变长。虚拟机设计者还提供了另外一个参数-XX:CMSFullGCsBeforeCompaction，这个参数是用于设置执行多少次不压缩的Full GC后，跟着来一次带压缩的（默认值为0，表示每次进入Full GC时都进行碎片整理）。

  7. G1收集器

    G1是一款面向服务端应用的垃圾收集器。HotSpot开发团队赋予它的使命是（在比较长期的）未来可以替换掉JDK 1.5中发布的CMS收集器。与其他GC收集器相比，G1具备如下特点。

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

    分代收集：与其他收集器一样，分代概念在G1中依然得以保留。虽然G1可以不需要其他收集器配合就能独立管理整个GC堆，但它能够采用不同的方式去处理新创建的对象和已经存活了一段时间、熬过多次GC的旧对象以获取更好的收集效果。

    空间整合：与CMS的“标记—清理”算法不同，G1从整体来看是基于“标记—整理”算法实现的收集器，从局部（两个Region之间）上来看是基于“复制”算法实现的，但无论如何，这两种算法都意味着G1运作期间不会产生内存空间碎片，收集后能提供规整的可用内存。这种特性有利于程序长时间运行，分配大对象时不会因为无法找到连续内存空间而提前触发下一次GC。

    可预测的停顿：这是G1相对于CMS的另一大优势，降低停顿时间是G1和CMS共同的关注点，但G1除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒，这几乎已经是实时Java（RTSJ）的垃圾收集器的特征了。

    在G1之前的其他收集器进行收集的范围都是整个新生代或者老年代，而G1不再是这样。使用G1收集器时，Java堆的内存布局就与其他收集器有很大差别，它将整个Java堆划分为多个大小相等的独立区域（Region），虽然还保留有新生代和老年代的概念，但新生代和老年代不再是物理隔离的了，它们都是一部分Region（不需要连续）的集合。

参考文章：https://blog.csdn.net/weixin_46421629/article/details/112524107

5.垃圾回收算法的实现原理。

http://www.importnew.com/13493.html

6.当出现了内存溢出，你怎么排错。

年老代堆空间被占满

年老代堆空间被占满
异常： java.lang.OutOfMemoryError: Java heap space

问题：老年代的内存长时间无法释放导致

解决方案：

  1. 通过分析工具(JVisualVM)进行分析，找到问题代码进行改善。

持久代被占满

持久代被占满
异常：java.lang.OutOfMemoryError: PermGen space

问题：持久代被占满很可能是大量的反射类被不停加载导致

解决方案：

  1. 增大持久代空间：-XX:MaxPermSize=100M。
  2. 排查加载的类是否存在问题

堆栈溢出

堆栈溢出
异常：java.lang.StackOverflowError

问题：死循环导致

线程堆栈满

线程堆栈满
异常：Fatal: Stack size too small

问题：线程空间大小默认是1M，当线程空间满了就会出现这个异常。

解决方案：

  1. 增加线程栈大小。-Xss2m。

系统内存被占满

系统内存被占满
异常：java.lang.OutOfMemoryError: unable to create new native thread

参考文章：https://wangkang007.gitbooks.io/jvm/content/4jvmdiao_you.html

7.JVM 内存模型的相关知识了解多少，比如重排序，内存屏障，happen-before，主内存，工作内存等。

  1. 指令重排序指的是指令执行顺序可能会与代码逻辑顺序不一致，导致异常。
  2. 内存屏障主要作用是阻止两侧指令重排序，以及强制写入主内存，并让缓存失效。
  3. happens-before是一套规则，指令重排序需要根据规则定义一些禁止编译优化的场景，保证并发编程的正确性。
  4. 每个线程创建jvm都会创建一个工作内存，需要的数据就从主内存拷贝到自己的工作内存中，修改完后再写会主内存中。

参考文章：

重排序，内存屏障：https://www.cnblogs.com/nicori/p/13713336.html

主内存，工作内存：https://blog.csdn.net/qq_41174684/article/details/90612265

8.简单说说你了解的类加载器。

JVM内置三大类加载器

  1. BootStrapClassLoader(负责加载虚拟机核心类库)
  2. ExtClassLoader(扩展类加载器)
  3. AppClassLoader(应用类加载器)

9.讲讲 JAVA 的反射机制。

java在运行时动态加载类的所有属性方法，并可以实例化该类，调用方法。

10.你们线上应用的 JVM 参数有哪些。

  1. Xms - 初始堆大小
  2. Xmx - 最大堆大小
  3. Xmn - 年轻代大小
  4. XX:PermSize - 持久代初始值
  5. XX:MaxPermSize - 持久代最大值
  6. XX:SurvivorRatio - Eden区与Survivor区的大小比值
  7. XX:MaxTenuringThreshold - 设置垃圾最大年龄

11.g1 和 cms 区别,吞吐量优先和响应优先的垃圾收集器选择。

posted @ 2021-01-13 15:52  Ninon  阅读(130)  评论(0)  编辑  收藏  举报