jvm面试相关

2019年6月4日 195次阅读 来源: 檀文渊

转载自 http://ginobefunny.com/post/jvm_interview_questions/

Java内存区域是如何划分的？

  • Java堆：线程共享的，唯一目的就是用于存放对象实例，是垃圾收集器管理的主要区域；
  • Java虚拟机栈：线程私有的，每个方法在执行的同时都会创建一个栈帧用于存储局部变量等，局部变量表存放了编译器可知的各种基本数据类型和对象引用；
  • 本地方法栈：和虚拟机栈类似，不过它是为Native方法服务；
  • 程序计数器：线程私有的，可以看作是当前线程所执行的字节码的行号指示器，以便线程切换后恢复执行使用；
  • 方法区：线程共享的，用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据；该区域的内存回收主要是针对常量池的回收和类型的卸载（特别是要注意一些动态字节码框架和自定义ClassLoader的场景下）；在HotSpot里经常被称为永久代，在Java 8里已被废除了，被元空间取代；

《jvm面试相关》
Java内存区域

对象是否可用以及引用类型。

  • 由于引用计数法无法解决循环引用的问题，所以一般都是使用可达性分析来判断的，即通过一系列称为“GC Roots”的对象（比如虚拟机栈引用的对象、方法区中的类静态属性和常量引用对象）作为起点，从这些节点一直往下搜索，走过的路径称为引用链；而那些没有与引用链相连的对象即为不可达，会被回收；
  • 可以通过覆盖finalize方法来实现对象的“自救”，避免在标记后被回收，但通常不建议这么做；
  • 对象的引用类型可分为：强引用、软引用（在内存溢出前会将这种类型的对象进行第二次回收）、弱引用（弱引用对象只能生存到下次垃圾回收之前）、虚引用（不会对生存时间存在影响，也无法通过它获取对象，主要目的就是在回收时收到一个系统通知）；

有哪些常见的垃圾收集算法？

  • 标记-清除算法：首先标记出所有需要回收的对象，然后统一回收所有被标记的对象；缺点是效率不高且容易产生大量不连续的内存碎片；
  • 复制算法：将可用内存分为大小相等的两块，每次只使用其中一块；当这一块用完了，就将还活着的对象复制到另一块上，然后把已使用过的内存清理掉。在HotSpot里，考虑到大部分对象存活时间很短，将内存分为Eden和两块Survivor，默认比例为8:1:1。代价是存在部分内存空间浪费，且可能存在空间不够需要分配担保的情况，所以适合在新生代使用；
  • 标记-整理算法：首先标记出所有需要回收的对象，然后让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存。适用于老年代。
  • 分代收集算法：一般把Java堆分新生代和老年代，在新生代用复制算法，在老年代用标记-清理或标记-整理算法，是现代虚拟机通常采用的算法。

PS：堆的划分及回收过程详解

1\. Eden区最大，对外提供堆内存。当Eden区快要满了，则进行Minor GC，把存活对象放入Survivor A区，清空Eden区；
2\. Eden区被清空后，继续对外提供堆内存；
3\. 当Eden区再次被填满，此时对Eden区和Survivor A区同时进行Minor GC，把存活对象放入Survivor B区，同时清空Eden 区和Survivor A区；
4\. Eden区继续对外提供堆内存，并重复上述过程，即在Eden区填满后，把Eden区和某个Survivor区的存活对象放到另一个Survivor区；
5\. 当某个Survivor区被填满，且仍有对象未被复制完毕时或者某些对象在反复Survive 15次左右时，则把这部分剩余对象放到Old区；
6\. 当Old区也被填满时，进行Major GC，对Old区进行垃圾回收。

有哪些常见的垃圾收集器？

这里讨论JDK 1.7 Update 14之后的HotSpot虚拟机，包含的虚拟机如下图所示（存在连线的表示可以搭配使用）：

《jvm面试相关》
HotSpot垃圾收集器

Serial收集器

《jvm面试相关》
Serial收集器

  • 最基本、发展历史最悠久，在JDK 1.3之前是新生代收集的唯一选择；
  • 是一个单线程（只会使用一个收集线程，且必须暂停所有工作线程）的收集器，采用的是复制算法；
  • 现在依然是虚拟机运行在Client模式下的默认新生代收集器，主要就是因为它简单而高效（没有线程交互的开销）；

ParNew收集器

《jvm面试相关》
ParNew收集器

  • 其实就是Serial收集器的多线程版本，采用的也是复制算法；
  • ParNew收集器在单CPU环境中绝对不会有比Serial收集器更好的效果；
  • 是许多运行在Server模式下虚拟机首选的新生代收集器，重要原因就是除了Serial收集器外，只有它能与CMS收集器配合工作；

PS：关于垃圾收集器的并行和并发

  • 并行（Parallel）：指多条垃圾收集线程并行工作，但此时用户线程仍处于等待状态；
  • 并发（Concurrent）：指用户线程与垃圾收集线程同时执行，用户线程在继续执行而垃圾收集程序运行在另外一个CPU上；

CMS收集器

《jvm面试相关》
CMS收集器

  • 是一种以获取最短回收停顿时间为目标的收集器，特别适合互联网站或者B/S的服务端；
  • 它是基于标记-清除 算法实现的，主要包括4个步骤：初始标记（STW，只是初始标记一下GC Roots能直接关联到的对象，速度很快）、并发标记（非STW，执行GC RootsTracing，耗时比较长）、重新标记（STW，修正并发标记期间因用户程序继续导致变动的那一部分对象标记）和并发清除（非STW，耗时较长）；
  • 还有3个明显的缺点：CMS收集器对CPU非常敏感（占用部分线程及CPU资源，影响总吞吐量）、无法处理浮动垃圾（默认达到92%就触发垃圾回收）、大量内存碎片产生（可以通过参数启动压缩）；

介绍一下G1收集器的原理和实现。

《jvm面试相关》
G1收集器

  • 一款面向服务端应用的垃圾收集器，后续会替换掉CMS垃圾收集器；
  • 特点：
并行与并发（充分利用多核多CPU缩短STW时间）
分代收集（独立管理整个Java堆，但针对不同年龄的对象采取不同的策略）
空间整合（局部看是基于复制算法，从整体来看是基于标记-整理算法，都不会产生内存碎片）
可预测的停顿（可以明确指定在一个长度为M毫秒的时间片内垃圾收集不会超过N毫秒）
  • 将堆分为大小相等的独立区域，避免全区域的垃圾收集；新生代和老年代不再物理隔离，只是部分Region的集合；
  • G1跟踪各个Region垃圾堆积的价值大小，在后台维护一个优先列表，根据允许的收集时间优先回收价值最大的Region；
  • Region之间的对象引用以及其他收集器中的新生代与老年代之间的对象引用，采用Remembered Set来避免全堆扫描；
  • 分为几个步骤，和CMS的过程比较类似：
初始标记（标记一下GC Roots能直接关联的对象并修改TAMS值，需要STW但耗时很短）
并发标记（从GC Root从堆中对象进行可达性分析找存活的对象，耗时较长但可以与用户线程并发执行）
最终标记（为了修正并发标记期间产生变动的那一部分标记记录，这一期间的变化记录在Remembered 
Set Log里，然后合并到Remembered Set里，该阶段需要STW但是可并行执行）
筛选回收（对各个Region回收价值排序，根据用户期望的GC停顿时间制定回收计划来回收）；

你们的服务配置的虚拟机参数是怎么样的？

我们的服务的虚拟机参数：

-server       --启用能够执行优化的编译器，显著提高服务器的性能
-Xmx4000M     --堆最大值
-Xms4000M     --堆初始大小
-Xmn600M      --年轻代大小
-XX:PermSize=200M         --持久代初始大小
-XX:MaxPermSize=200M      --持久代最大值
-Xss256K                  --每个线程的栈大小
-XX:+DisableExplicitGC    --关闭System.gc()
-XX:SurvivorRatio=1       --年轻代中Eden区与两个Survivor区的比值
-XX:+UseConcMarkSweepGC   --使用CMS内存收集
-XX:+UseParNewGC          --设置年轻代为并行收集
-XX:+CMSParallelRemarkEnabled        --降低标记停顿
-XX:+UseCMSCompactAtFullCollection   --在FULL GC的时候，对年老代进行压缩，可能会影响性能，但是可以消除碎片
-XX:CMSFullGCsBeforeCompaction=0     --此值设置运行多少次GC以后对内存空间进行压缩、整理
-XX:+CMSClassUnloadingEnabled        --回收动态生成的代理类 SEE：http://stackoverflow.com/questions/3334911/what-does-jvm-flag-cmsclassunloadingenabled-actually-do
-XX:LargePageSizeInBytes=128M        --内存页的大小不可设置过大， 会影响Perm的大小
-XX:+UseFastAccessorMethods          --原始类型的快速优化
-XX:+UseCMSInitiatingOccupancyOnly   --使用手动定义初始化定义开始CMS收集，禁止hostspot自行触发CMS GC
-XX:CMSInitiatingOccupancyFraction=80  --使用cms作为垃圾回收，使用80％后开始CMS收集
-XX:SoftRefLRUPolicyMSPerMB=0          --每兆堆空闲空间中SoftReference的存活时间
-XX:+PrintGCDetails                    --输出GC日志详情信息
-XX:+PrintGCApplicationStoppedTime     --输出垃圾回收期间程序暂停的时间
-Xloggc:$WEB_APP_HOME/.tomcat/logs/gc.log  --把相关日志信息记录到文件以便分析.
-XX:+HeapDumpOnOutOfMemoryError            --发生内存溢出时生成heapdump文件
-XX:HeapDumpPath=$WEB_APP_HOME/.tomcat/logs/heapdump.hprof  --heapdump文件地址

如何进行性能调优以及常用的JDK的命令行工具有哪些？

  • JVM调优：CPU使用率与Load值偏大（Thread count以及GC count）、关键接口响应时间很慢（GC time以及GC log中的STW的时间）、发生Full GC或者Old CMS GC非常频繁（内存泄露）；
  • JVM停顿（尽量避免Full GC、关闭偏向锁、输出GC日志到内存文件系统、关闭JVM输出的jstat日志）；
  • 将Java性能优化分为4个层级：应用层、数据库层、框架层、JVM层。每层优化难度逐级增加，涉及的知识和解决的问题也会不同。比如应用层需要理解代码逻辑，通过Java线程栈定位有问题代码行等；数据库层面需要分析SQL、定位死锁等；框架层需要懂源代码，理解框架机制；JVM 层需要对GC的类型和工作机制有深入了解，对各种 JVM 参数作用了然于胸；
  • 围绕Java性能优化，有两种最基本的分析方法：现场分析法和事后分析法。现场分析法通过保留现场，再采用诊断工具分析定位。现场分析对线上影响较大，部分场景不太合适。事后分析法需要尽可能多收集现场数据，然后立即恢复服务，同时针对收集的现场数据进行事后分析和复现。
  • OS 的诊断主要关注的是 CPU、Memory、I/O 三个方面。top、vmstat、 free –m、iostat；常用的Java应用诊断包括线程、堆栈、GC 等方面的诊断，可以使用jstack 、jstat、jmap；

《jvm面试相关》
JDK的命令行工具

类的加载器是什么？

  • 虚拟机设计团队把类加载阶段的“通过一个类的全限定名来获取描述此类的二进制字节流”这个动作放到虚拟机外部去实现，实现这个动作的代码模块称为类加载器；这种设计给Java语言带来了非常强大的灵活性；
  • 双亲委派模型要求除了顶层的启动类加载器外，其他的类加载器都应当有自己的父类加载器，如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，只有父类加载器反馈自己无法完成这个加载请求时，子加载器才会尝试自己去加载；这对于保证程序的稳定运作很重要；

《jvm面试相关》
类加载器

  • OSGI实现模块化热部署的关键是它自定义的类加载机制的实现，每个Bundle（通过Import-Package和Export-Package导入和导出依赖）都有自己的类加载器，类加载器之间形成了更加复杂的网状结构；

谈谈你对Java内存模型的理解。

  • 虚拟机规范视图通过JMM来屏蔽掉各种硬件和操作系统的内存访问差异，主要目标是定义程序中各个变量的访问限制，即在虚拟机将变量存储到内存和从内存中取出变量这样的底层细节；
  • 主内存与工作内存：Java内存模型规定了所有的变量都存储在主内存中，每个线程还有自己的工作内存，线程的工作内存中保存了被该线程使用到的变量的主内存副本拷贝，线程对变量的所有操作都必须在工作内存中进行，而不能直接读写主内存中的变量；

《jvm面试相关》
主内存与工作内存

  • 可见性（主内存和工作内存）、原子性（volatile的long是具备原子性的）、有序性（happen—before规则）；
  • Java语言中有一个“先行发生”（happen—before）的规则，它是Java内存模型中定义的两项操作之间的偏序关系，如果操作A先行发生于操作B，其意思就是说，在发生操作B之前，操作A产生的影响都能被操作B观察到，“影响”包括修改了内存中共享变量的值、发送了消息、调用了方法等，它与时间上的先后发生基本没有太大关系。下面是Java内存模型中的八条可保证happen—before的规则，它们无需任何同步器协助就已经存在，可以在编码中直接使用。如果两个操作之间的关系不在此列，并且无法从下列规则推导出来的话，它们就没有顺序性保障，虚拟机可以对它们进行随机地重排序。
1、程序次序规则：在一个单独的线程中，按照程序代码的执行流顺序，（时间上）先执行的操作happen—before（时间上）后执行的操作。
2、管理锁定规则：一个unlock操作happen—before后面（时间上的先后顺序，下同）对同一个锁的lock操作。
3、volatile变量规则：对一个volatile变量的写操作happen—before后面对该变量的读操作。
4、线程启动规则：Thread对象的start（）方法happen—before此线程的每一个动作。
5、线程终止规则：线程的所有操作都happen—before对此线程的终止检测，可以通过Thread.join（）方法结束、Thread.isAlive（）的返回值等手段检测到线程已经终止执行。
6、线程中断规则：对线程interrupt（）方法的调用happen—before发生于被中断线程的代码检测到中断时事件的发生。
7、对象终结规则：一个对象的初始化完成（构造函数执行结束）happen—before它的finalize（）方法的开始。
8、传递性：如果操作A happen—before操作B，操作B happen—before操作C，那么可以得出A happen—before操作C。

《jvm面试相关》
锁的优缺点对比

    原文作者：檀文渊
    原文地址: https://www.jianshu.com/p/bf59d75bfe94
    本文转自网络文章，转载此文章仅为分享知识，如有侵权，请联系博主进行删除。
点赞