jvm面试题目补充

jdk&jre

Java程序设计语言、Java虚拟机、Java API类库这三部分统称为JDK（Java Development Kit）。

把Java API类库中的Java SE API子集 [1] 和Java虚拟机这两部分统称为JRE（Java Runtime Environment），JRE是支持Java程序运行的标准环境

HotSpot VM：

HotSpot指的就是它的热点代码探测技术

垃圾回收中的空间分配担保

为了减少垃圾回收时间

minor gc前，检查老年代最大连续可用空间是否大于新生代对象总大小，如大于，则进行minor gc；

如小于，检查是否开启了分配担保，未开启，直接full gc；

开启后，检查老年代最大连续可用空间是否大于历次晋升老年代对象大小，小于则进行minorgc,同时将新生代放不下的对象提前放到老年代中，大于则full gc

根节点枚举

在特定位置时就记录对象关系到OopMap中

暂停用户线程；使用OopMap存储：类加载完成时，将什么对象存储在什么位置取出来；即时编译时，将对象存储取出放到特定位置；不需要一字不漏的将gcroot从方法区等位置取出

安全点

在特定的位置生成OopMap记录，称为安全点；到安全点时，用户线程才停止，进行垃圾回收

用户线程主动式中断：主动轮询中断标识，为true时，中断

• 循环的末尾
• 方法返回前
• 调用方法的 call 之后
• 抛出异常的位置

安全区

用户线程sleep或者blocked状态时，无法响应系统的中断请求，挂起自己线程

某个区域内，引用关系不会发生变化，进行垃圾回收是安全的

记忆集和卡表

存在跨区域垃圾回收时，GC root并不是包含所有区域的root节点，非回收区域存在回收区域的指针时，才需要加入gc root节点；用于缩小gc root扫描范围

使用以下结构存储了这些引用关系

记忆集：是否存在非回收区域指向回收区域的指针

卡表是记忆集（一种抽象概念）的实现，一个卡表存在多个卡页，一个卡页存在一个（或多个对象）对象存在跨代指针时，记录变脏标志为1，后续将这个内存页的数据加入GC ROOT一并扫描

写屏障

卡表变脏时间：引用类型对象赋值时，卡表可能变脏

引用类型对象赋值后，使用写后屏障，更新卡表。

写前屏障在G1垃圾处理器后才使用到

三色标记:并发标记阶段(可达性分析)

gcroot向下遍历对象时的算法

按照是否被垃圾回收器访问过，分为白色（没被访问过，不可达），黑色（被访问过，所有引用都被访问过，不能直接指向白色，需通过灰色间接指向白色，原因是黑色是被遍历完成的，下次标记不能重新扫描引用，此时白色会被误清理），灰色（至少一个引用未被访问过,正在枚举过程中）

假设访问对象A，访问对象A的所有引用，变为灰色对象，访问完成时，将A变为黑色对象；所有对象遍历完成时，剩余的白色对象即为垃圾；

并发标记阶段，用户线程同步进行，对象的引用关系发生了变化，因此在重新标记阶段需要对变化的引用进行处理；

引用关系两种变化场景：

1 删除引用，黑色对象引用被删除，成为浮动垃圾，下次垃圾回收时回收即可；

2 新增引用，黑色对象下添加白色对象A->F，当原来引用白色的关系被删除时B.f=null，此时进行重新标记时，B变为黑色，F还是白色，会被误清理

解决方案

增量更新

从增量角度，A.f=F，增加引用时，添加写屏障，将黑色引用白色的引用关系记录一下，重新标记时，将引用关系重新扫描，实现方案是将A变为灰色，a的引用关系重新扫描

原始快照

从删除角度，在执行B.f=nul,插入一个写屏障，记录B.f，再进行置空操作，重新标记时，将B.F变为黑色对象，不管吧B.F是否还有引用都不会被清理，如果没有引用下次垃圾回收会清理掉。宁可放过，不可杀错的思想。

引用逃逸

如果一个对象的指针被多个方法或者线程引用时，那么我们就称这个对象的指针发生了逃逸。

gcroot包含静态类，synch锁定对象、常量池中对象

垃圾回收

fullgc场景

大对象（sql未分页等）分配

metaspace溢出，classloader未回收导致元空间溢出，发生full gc

内存泄漏，由于内存泄漏会导致内存溢出

jvm参数设置不合理

内存溢出

不断创建对象时，gc root存在引用关系时，堆空间不足时会发生内存溢出

堆

确认oom对象是否是必要的，即内存泄漏还是内存溢出，内存泄漏需要使用工具判断引用链，内存溢出需要判断堆大小相关配置

栈

StackOverflow

虚拟机容量太小，栈帧太大，都会引起新的栈帧无法分配内存

线程请求栈的深度大于虚拟机允许的最大深度时

oom

创建线程时无法获得内存时会出现oom（jvm实现上不允许栈自动扩容，理论上允许）

方法区（类型信息（类名，父类，修饰符，实现的接口列表等）、域（属性）、方法、常量、静态变量，运行时的常量池，编译后的代码缓存）

垃圾回收主要包含：常量池和类的卸载

jdk1.6 PerGen OOM

jdk1.7 java heap

jdk1.8 metasapce oom

本地直接内存

使用NIO时，日志内容较少

永久代和方法区的关系？和元空间的关系？

收集器的分代设计扩展到方法区时，用永久代的概念实现方法区的垃圾回收，效果不理想，因此从jdk7开始逐步将永久代的字符串常量池和静态变量等移出（堆中），jdk8中永久代消失，将剩余内容（主要是类型信息）移动到直接内存metaspace元空间中

gc和内存溢出的关系

分配空间时，发现空间不足（应用空闲时也会）时会进行gc，gc后空间还不够，抛出内存溢出相关异常

减少GC开销的措施　

　(1)不要显式调用System.gc()　　此函数建议JVM进行主GC,虽然只是建议而非一定,但很多情况下它会触发主GC,从而增加主GC的频率,也即增加了间歇性停顿的次数。　

　(2)尽量减少临时对象的使用　　临时对象在跳出函数调用后,会成为垃圾,少用临时变量就相当于减少了垃圾的产生,从而延长了出现上述第二个触发条件出现的时间,减少了主GC的机会。　

　(3)对象不用时最好显式置为Null　　一般而言,为Null的对象都会被作为垃圾处理,所以将不用的对象显式地设为Null,有利于GC收集器判定垃圾,从而提高了GC的效率。　

　(4)尽量使用StringBuffer,而不用String来累加字符串　　由于String是固定长的字符串对象,累加String对象时,并非在一个String对象中扩增,而是重新创建新的String对象,如Str5=Str1+Str2+Str3+Str4,这条语句执行过程中会产生多个垃圾对象,因为对次作“+”操作时都必须创建新的String对象,但这些过渡对象对系统来说是没有实际意义的,只会增加更多的垃圾。避免这种情况可以改用StringBuffer来累加字符串,因StringBuffer是可变长的,它在原有基础上进行扩增,不会产生中间对象。　

　(5)能用基本类型如Int,Long,就不用Integer,Long对象　　基本类型变量占用的内存资源比相应对象占用的少得多,如果没有必要,最好使用基本变量。　

　(6)尽量少用静态对象变量　　静态变量属于全局变量,不会被GC回收,它们会一直占用内存。

　(7)分散对象创建或删除的时间　　集中在短时间内大量创建新对象,特别是大对象,会导致突然需要大量内存,JVM在面临这种情况时,只能进行主GC,以回收内存或整合内存碎片,从而增加主GC的频率。集中删除对象,道理也是一样的。它使得突然出现了大量的垃圾对象,空闲空间必然减少,从而大大增加了下一次创建新对象时强制主GC的机会。