JVM必知必会的十道题

JVM必知必会题

一、JVM的主要组成部分有哪些？并画图说明

二、jvm的作用？

JVM是java字节码执行的引擎，还能优化java字节码，使之转化成效率更高的机器指令。
JVM中类的装载是由类加载器和它的子类来实现的，类加载是java运行时一个重要的系统组件，负责在运行时查找和装入类文件的类。不同的平台对应着不同的JVM，在执行字节码(class文件)时，JVM负责将每一条要执行的字节码送给解释器，解释器再将其翻译成特定平台换将的机器指令并执行，这样就实现了跨平台运行。

三、JVM工作原理

JVM在整个JDK中处于最底层，负责与操作系统的交互。操作系统装入jvm是通过JDK中的java.exe来实现的，具体步骤如下：
a、创建JVM装载环境和配置；
b、装载jvm.dll;
c、初始化jvm.dll;
d、调用JNIEnv实例装载并处理class类；
e、运行java程序

四、说下堆和栈的区别？

栈（Stack）、堆（Heap）
栈：由操作系统自动分配释放 ，存放函数的参数值，局部变量的值等；
堆： 一般由程序员分配释放， 若程序员不释放，程序结束时可能被回收，若无法被回收，可能造成内存溢出；
堆：堆可以被看成是一棵树，如：堆排序；
栈：一种先进后出的数据结构；
栈和堆的区别：
管理方式不同:栈由操作系统自动分配释放，无需我们手动控制；堆的申请和释放工作由程序员控制，容易产生内存泄漏；
分配方式不同:堆都是动态分配的，没有静态分配的堆。栈有2种分配方式：静态分配和动态分配。
空间大小不同:栈的大小要远远小于堆的大小。
生长方向不同:堆的生长方向向上，内存地址由低到高；栈的生长方向向下，内存地址由高到低

五、谈谈java内存泄露？

不再会被使用的对象的内存不能被回收，就是内存泄露；
在Java中，我们不用（也没办法）自己释放内存，无用的对象由GC自动清理，这也极大的简化了我们的编程工作。但，实际有时候一些不再会被使用的对象，在GC看来不能被释放，就会造成内存泄露。
对象都是有生命周期的，有的长，有的短，如果长生命周期的对象持有短生命周期的引用，就很可能会出现内存泄露。

六、jvm有哪些垃圾回收算法？

分代收集理论

当前虚拟机的垃圾收集都采用分代收集算法，这种算法没有什么新的思想，只是根据对象存活周期的不同将内存分为几
块。一般将java堆分为新生代和老年代，这样我们就可以根据各个年代的特点选择合适的垃圾收集算法。
比如在新生代中，每次收集都会有大量对象(近99%)死去，所以可以选择复制算法，只需要付出少量对象的复制成本就可以完成每次垃圾收集。而老年代的对象存活几率是比较高的，而且没有额外的空间对它进行分配担保，所以我们必须选择“标记-清除”或“标记-整理”算法进行垃圾收集。注意，“标记-清除”或“标记-整理”算法会比复制算法慢10倍以
上。

标记-复制算法

为了解决效率问题，“复制”收集算法出现了。它可以将内存分为大小相同的两块，每次使用其中的一块。当这一块的
内存使用完后，就将还存活的对象复制到另一块去，然后再把使用的空间一次清理掉。这样就使每次的内存回收都是对
内存区间的一半进行回收。

标记-清除算法

算法分为“标记”和“清除”阶段：标记存活的对象， 统一回收所有未被标记的对象(一般选择这种)；也可以反过来，标
记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象 。它是最基础的收集算法，比较简单，但是会带来
两个明显的问题：

1. 效率问题 (如果需要标记的对象太多，效率不高)
2. 空间问题（标记清除后会产生大量不连续的碎片）
   

标记-整理算法

根据老年代的特点特出的一种标记算法，标记过程仍然与“标记-清除”算法一样，但后续步骤不是直接对可回收对象回
收，而是让所有存活的对象向一端移动，然后直接清理掉端边界以外的内存。
根据老年代的特点特出的一种标记算法，标记过程仍然与“标记-清除”算法一样，但后续步骤不是直接对可回收对象回
收，而是让所有存活的对象向一端移动，然后直接清理掉端边界以外的内存。

七、jvm有哪些垃圾收集器？

Serial收集器(-XX:+UseSerialGC -XX:+UseSerialOldGC)

Serial（串行）收集器是最基本、历史最悠久的垃圾收集器了。大家看名字就知道这个收集器是一个单线程收集器了。它的 “单线程” 的意义不仅仅意味着它只会使用一条垃圾收集线程去完成垃圾收集工作，更重要的是它在进行垃圾收集工
作的时候必须暂停其他所有的工作线程（ “Stop The World” ），直到它收集结束。新生代采用复制算法，老年代采用标记-整理算法。

虚拟机的设计者们当然知道Stop The World带来的不良用户体验，所以在后续的垃圾收集器设计中停顿时间在不断缩短
（仍然还有停顿，寻找最优秀的垃圾收集器的过程仍然在继续）。
但是Serial收集器有没有优于其他垃圾收集器的地方呢？当然有，它简单而高效（与其他收集器的单线程相比）。Serial
收集器由于没有线程交互的开销，自然可以获得很高的单线程收集效率。
Serial Old收集器是Serial收集器的老年代版本，它同样是一个单线程收集器。它主要有两大用途：一种用途是在JDK1.5
以及以前的版本中与Parallel Scavenge收集器搭配使用，另一种用途是作为CMS收集器的后备方案。

Parallel Scavenge收集器(-XX:+UseParallelGC(年轻代),-XX:+UseParallelOldGC(老年代))

Parallel收集器其实就是Serial收集器的多线程版本，除了使用多线程进行垃圾收集外，其余行为（控制参数、收集算
法、回收策略等等）和Serial收集器类似。默认的收集线程数跟cpu核数相同，当然也可以用参数(-
XX:ParallelGCThreads)指定收集线程数，但是一般不推荐修改。
Parallel Scavenge收集器关注点是吞吐量（高效率的利用CPU）。CMS等垃圾收集器的关注点更多的是用户线程的停
顿时间（提高用户体验）。所谓吞吐量就是CPU中用于运行用户代码的时间与CPU总消耗时间的比值。 Parallel Scavenge收集器提供了很多参数供用户找到最合适的停顿时间或最大吞吐量，如果对于收集器运作不太了解的话，可以选择把内存管理优化交给虚拟机去完成也是一个不错的选择。
新生代采用复制算法，老年代采用标记-整理算法。

Parallel Old收集器是Parallel Scavenge收集器的老年代版本。使用多线程和“标记-整理”算法。在注重吞吐量以及
CPU资源的场合，都可以优先考虑 Parallel Scavenge收集器和Parallel Old收集器(JDK8默认的新生代和老年代收集
器)。

ParNew收集器(-XX:+UseParNewGC)

ParNew收集器其实跟Parallel收集器很类似，区别主要在于它可以和CMS收集器配合使用。
新生代采用复制算法，老年代采用标记-整理算法。

它是许多运行在Server模式下的虚拟机的首要选择，除了Serial收集器外，只有它能与CMS收集器（真正意义上的并发收集器，后面会介绍到）配合工作。

CMS收集器(-XX:+UseConcMarkSweepGC(old))

CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。它非常符合在注重用户体
验的应用上使用，它是HotSpot虚拟机第一款真正意义上的并发收集器，它第一次实现了让垃圾收集线程与用户线程
（基本上）同时工作。
从名字中的Mark Sweep这两个词可以看出，CMS收集器是一种 “标记-清除”算法实现的，它的运作过程相比于前面
几种垃圾收集器来说更加复杂一些。整个过程分为四个步骤：
初始标记： 暂停所有的其他线程(STW)，并记录下gc roots直接能引用的对象，速度很快。
并发标记： 并发标记阶段就是从GC Roots的直接关联对象开始遍历整个对象图的过程， 这个过程耗时较长但
是不需要停顿用户线程， 可以与垃圾收集线程一起并发运行。因为用户程序继续运行，可能会有导致已经标记过的对象状态发生改变。
重新标记： 重新标记阶段就是为了修正并发标记期间因为用户程序继续运行而导致标记产生变动的那一部分对
象的标记记录，这个阶段的停顿时间一般会比初始标记阶段的时间稍长，远远比并发标记阶段时间短。主要用到三
色标记里的增量更新算法(见下面详解)做重新标记。
并发清理： 开启用户线程，同时GC线程开始对未标记的区域做清扫。这个阶段如果有新增对象会被标记为黑
色不做任何处理(见下面三色标记算法详解)。
并发重置：重置本次GC过程中的标记数据。

从它的名字就可以看出它是一款优秀的垃圾收集器，主要优点：并发收集、低停顿。但是它有下面几个明显的缺点：
对CPU资源敏感（会和服务抢资源）；
无法处理浮动垃圾(在并发标记和并发清理阶段又产生垃圾，这种浮动垃圾只能等到下一次gc再清理了)；
它使用的回收算法-“标记-清除”算法会导致收集结束时会有大量空间碎片产生，当然通过参数XX:+UseCMSCompactAtFullCollection可以让jvm在执行完标记清除后再做整理
执行过程中的不确定性，会存在上一次垃圾回收还没执行完，然后垃圾回收又被触发的情况，特别是在并
发标记和并发清理阶段会出现，一边回收，系统一边运行，也许没回收完就再次触发full gc，也就是"concurrent
mode failure"，此时会进入stop the world，用serial old垃圾收集器来回收
CMS的相关核心参数

1. -XX:+UseConcMarkSweepGC：启用cms
2. -XX:ConcGCThreads：并发的GC线程数
3. -XX:+UseCMSCompactAtFullCollection：FullGC之后做压缩整理（减少碎片）
4. -XX:CMSFullGCsBeforeCompaction：多少次FullGC之后压缩一次，默认是0，代表每次FullGC后都会压缩一
   次
5. -XX:CMSInitiatingOccupancyFraction: 当老年代使用达到该比例时会触发FullGC（默认是92，这是百分比）
6. -XX:+UseCMSInitiatingOccupancyOnly：只使用设定的回收阈值(-XX:CMSInitiatingOccupancyFraction设
   定的值)，如果不指定，JVM仅在第一次使用设定值，后续则会自动调整
7. -XX:+CMSScavengeBeforeRemark：在CMS GC前启动一次minor gc，目的在于减少老年代对年轻代的引
   用，降低CMS GC的标记阶段时的开销，一般CMS的GC耗时 80%都在标记阶段
8. -XX:+CMSParallellnitialMarkEnabled：表示在初始标记的时候多线程执行，缩短STW
9. -XX:+CMSParallelRemarkEnabled：在重新标记的时候多线程执行，缩短STW;

八、说下类加载执行过程？

其中loadClass的类加载过程有如下几步：
加载 >> 验证 >> 准备 >> 解析 >> 初始化 >> 使用 >> 卸载
加载：在硬盘上查找并通过IO读入字节码文件，使用到类时才会加载，例如调用类的
main()方法，new对象等等，在加载阶段会在内存中生成一个代表这个类的
java.lang.Class对象，作为方法区这个类的各种数据的访问入口
验证：校验字节码文件的正确性
准备：给类的静态变量分配内存，并赋予默认值
解析：将符号引用替换为直接引用，该阶段会把一些静态方法(符号引用，比如
main()方法)替换为指向数据所存内存的指针或句柄等(直接引用)，这是所谓的静态链接过
程(类加载期间完成)，动态链接是在程序运行期间完成的将符号引用替换为直接引用，下
节课会讲到动态链接
初始化：对类的静态变量初始化为指定的值，执行静态代码块

类被加载到方法区中后主要包含 运行时常量池、类型信息、字段信息、方法信息、类加载器的
引用、对应class实例的引用等信息。
类加载器的引用：这个类到类加载器实例的引用
对应class实例的引用：类加载器在加载类信息放到方法区中后，会创建一个对应的Class 类型的
对象实例放到堆(Heap)中, 作为开发人员访问方法区中类定义的入口和切入点。
注意，主类在运行过程中如果使用到其它类，会逐步加载这些类。
jar包或war包里的类不是一次性全部加载的，是使用到时才加载。

九、什么是双亲委派？为什么要使用双亲委派？

类加载过程主要是通过类加载器来实现的，Java里有如下几种类加载器：
引导类加载器：负责加载支撑JVM运行的位于JRE的lib目录下的核心类库，比如rt.jar、charsets.jar等
扩展类加载器：负责加载支撑JVM运行的位于JRE的lib目录下的ext扩展目录中的JAR类包
应用程序类加载器：负责加载ClassPath路径下的类包，主要就是加载你自己写的那些类
自定义加载器：负责加载用户自定义路径下的类包

这里类加载其实就有一个双亲委派机制，加载某个类时会先委托父加载器寻找目标类，找不到再
委托上层父加载器加载，如果所有父加载器在自己的加载类路径下都找不到目标类，则在自己的
类加载路径中查找并载入目标类。
比如我们的Math类，最先会找应用程序类加载器加载，应用程序类加载器会先委托扩展类加载
器加载，扩展类加载器再委托引导类加载器，顶层引导类加载器在自己的类加载路径里找了半天
没找到Math类，则向下退回加载Math类的请求，扩展类加载器收到回复就自己加载，在自己的
类加载路径里找了半天也没找到Math类，又向下退回Math类的加载请求给应用程序类加载器，
应用程序类加载器于是在自己的类加载路径里找Math类，结果找到了就自己加载了。。
双亲委派机制说简单点就是，先找父亲加载，不行再由儿子自己加载

为什么要设计双亲委派机制？

沙箱安全机制：自己写的java.lang.String.class类不会被加载，这样便可以防止核心
API库被随意篡改
避免类的重复加载：当父亲已经加载了该类时，就没有必要子ClassLoader再加载一
次，保证被加载类的唯一性

十、常用的jvm调优参数有哪些？

-Xms2g：初始化推大小为2g；
-Xms2g：堆最大内存为2g；
-XX:NewRatio=4：设置年轻的和老年代的内存比例为1:4；
-XX:SurvivorRatio=8：设置新生代Eden和Survivor比例为8:2；
-XX:+UseParNewGC：指定使用ParNew + Serial Old垃圾回收器组合；
-XX:+UseParallelOldGC：指定使用ParNew + ParNew Old垃圾回收器组合；
-XX:+UseConcMarkSweepGC：指定使用CMS + Serial Old垃圾回收器组合；
-XX:+PrintGC：开启打印gc信息；
-XX:+PrintGCDetails：打印gc详细信息；

---

-Xms:初始大小内存，默认为物理内存的1/64等价于-XX:InitialHeapSize
-Xmx:最大分配内存，默认为物理内存的1/4等价于-XX:MaxHeapSize
-Xss:设置单个线程栈的大小，一般默认为512k~1024k等价于-XX:ThreadStackSize
当值等于0的时候，代表使用得是默认大小
-Xmn：设置年轻代大小
-XX:MetaspaceSize：设置元空间大小（元空间与永久代最大的区别为：元空间并不在虚拟机中，而使用的是本地内存，因此，元空间只收本地内存的限制）
手动设置：-XX：MetaspaceSize=1024m
-XX：+PrintGCDetails：输出详细GC收集日志信息
-XX:SurvivorRatio：设置新生代中 eden 和 S0/S1 空间比例，默认 -XX:SurvivorRatio=8，Eden : S0 : S1 = 8 : 1 : 1
​ -XX:SurvivorRatio=4==》Eden : S0 : S1 = 4 : 1 : 1
-XX:NewRatio：配置年轻代和老年代在堆结构的占比，默认 -XX:NewRatio=2 新生代占1，老年代占2，年轻代占整个堆的 1/3
​ -XX:NewRatio=4 新生代占1，老年代占4，年轻代占整个堆的 1/5
-XX:MaxTenuringThreshold：设置垃圾最大年龄。默认是15。
-XX:MaxTenuringThreshold=0：设置垃圾最大年龄。如果设置为0的话，则年轻代对象不经过Survivor区，直接进入老年代。对于老年代比较多的应用，可以提高效率。如果此值设置为一个较大的值，则年前对象会在Survivor区进行多次复制，这样可以增加对象在年轻代的存活时间，增加在年轻代被回收的概率！

---

Xms
中文释义：堆区初始值
使用方法：-Xms2g 或 -XX:InitialHeapSize=2048m

Xmx
中文释义：堆区最大值
使用方法：-Xmx2g 或 -XX:MaxHeapSize=2048m

Xmn
中文释义：新生代最大值
使用方法：-Xmn512m 或 -XX:MaxNewSize=512m

PermSize(JDK1.8以后已废弃)
中文释义：永久代初始大小
使用方法：-XX:PermSize=128m

MaxPermSize(JDK1.8以后已废弃)
中文释义：永久代最大值
使用方法：-XX:MaxPermSize=256m

MetaspaceSize(JDK1.8以后用于替换PermSize)
中文释义：元数据区初始大小
使用方法：-XX:MetaspaceSize=128m

MaxMetaspaceSize(JDK1.8以后用于替换MaxPermSize)
中文释义：元数据区最大值
使用方法：-XX:MaxMetaspaceSize=256m

Xss
中文释义：线程栈最大值
使用方法：-Xss256k 或 -XX:ThreadStackSize=256k

MaxDirectMemorySize
中文释义：最大直接内存（堆外）大小
使用方法：-XX:MaxDirectMemorySize=256m

NewRatio
中文释义：老年代和新生代的比值
使用方法：-XX:NewRatio=2
使用经验：假如设为2，则表示老年代最大内存占堆最大内存的2/3，新生代则为1/3。如果设置了Xmn或者NewSize/MaxNewSize，那么NewRatio配置无效

SurvivorRatio
中文释义：新生代中eden区和survivor区的比值
使用方法：-XX:SurvivorRatio=6
使用经验：假如设为6，则表示每个survivor区跟eden区的比值为1:6,每个survivor区占新生代的八分之一

PretenureSizeThreshold
中文释义：可以在新生代直接分配的对象最大值，0表示没有最大值
使用方法：-XX:PretenureSizeThreshold=1000000
使用经验：设置该参数，可以使大于这个值的对象直接在老年代分配，避免在Eden区和Survivor区发生大量的内存复制，该参数只对Serial和ParNew收集器有效，Parallel Scavenge并不认识该参数

MaxTenuringThreshold
中文释义：年轻代最大年龄
使用方法：-XX:MaxTenuringThreshold=10
使用经验：每个对象在坚持过一次Minor GC之后，年龄就增加1，当超过这个参数值时就进入老年代，最大支持15

UseSerialGC
中文释义：年轻代使用Serial垃圾收集器
使用方法：
开启 -XX:+UseSerialGC
使用经验：不推荐使用，性能太差，老年代将会使用SerialOld垃圾收集器

UseParNewGC
中文释义：年轻代使用ParNew垃圾收集器
使用方法：
开启 -XX:+UseParNewGC

ParallelGCThreads
中文释义：并行执行gc的线程数
使用方法：-XX:ParallelGCThreads=16

UseParallelGC
中文释义：年轻代使用Parallel Scavenge垃圾收集器
使用方法：
开启 -XX:+UseParallelGC
使用经验：Linux下1.6,1.7,1.8默认开启，老年代将会使用SerialOld垃圾收集器

UseParallelOldGC
中文释义：年轻代使用Parallel Scavenge收集器
使用方法：
开启 -XX:+UseParallelOldGC
使用经验：老年代将会使用Parallel Old收集器

UseConcMarkSweepGC
中文释义：老年代使用CMS收集器（如果出现"Concurrent Mode Failure"，会使用SerialOld收集器）
使用方法：
开启 -XX:+UseConcMarkSweepGC
使用经验：年轻代将会使用ParNew收集器

Xloggc
中文释义：GC日志文件路径
使用方法：-Xloggc:/data/gclog/gc.log

UseGCLogFileRotation
中文释义：滚动GC日志文件，须配置Xloggc
使用方法：
开启 -XX:+UseGCLogFileRotation

NumberOfGCLogFiles
中文释义：滚动GC日志文件数，默认0，不滚动
使用方法：-XX:NumberOfGCLogFiles=4

GCLogFileSize
中文释义：GC文件滚动大小，需配置UseGCLogFileRotation，设置为0表示仅通过jcmd命令触发
使用方法：-XX:GCLogFileSize=100k

PrintGCDetails
中文释义：GC时打印更多详细信息，默认关闭
使用方法：
开启 -XX:+PrintGCDetails
可以通过jinfo -flag [+|-]PrintGCDetails 或 jinfo -flag PrintGCDetails= 来动态开启或设置值

PrintGCDateStamps
中文释义：GC时打印时间戳信息，默认关闭
使用方法：
开启 -XX:+PrintGCDateStamps
可以通过jinfo -flag [+|-]PrintGCDateStamps 或 jinfo -flag PrintGCDateStamps= 来动态开启或设置值

PrintTenuringDistribution
中文释义：打印存活实例年龄信息，默认关闭
使用方法：
开启 -XX:+PrintTenuringDistribution

PrintGCApplicationStoppedTime
中文释义：打印应用暂停时间，默认关闭
使用方法：
开启 -XX:+PrintGCApplicationStoppedTime

PrintHeapAtGC
中文释义：GC前后打印堆区使用信息，默认关闭
使用方法：
开启 -XX:+PrintHeapAtGC

HeapDumpOnOutOfMemoryError
中文释义：抛出内存溢出错误时导出堆信息到指定文件，默认关闭
使用方法：
开启 -XX:+HeapDumpOnOutOfMemoryError
可以通过jinfo -flag [+|-]HeapDumpOnOutOfMemoryError 或 jinfo -flag HeapDumpOnOutOfMemoryError= 来动态开启或设置值

HeapDumpPath
中文释义：当HeapDumpOnOutOfMemoryError开启的时候，dump文件的保存路径，默认为工作目录下的java_pid.hprof文件
使用方法：-XX:HeapDumpPath=/data/dump/jvm.dump
使用经验：除非必要，建议不设置

OmitStackTraceInFastThrow
中文释义：在优化代码里面忽略热点异常回溯
使用方法：
关闭 -XX:-OmitStackTraceInFastThrow
使用经验：某些热点异常抛的太多的话，JVM默认会做优化，会使用JVM初始化的时候创建的异常代替实际的异常，这些异常是没有异常栈信息的，不方便定位问题，如果有碰到这种情况，可以考虑关闭这个配置