JVM学习整理

1 JVM组成

1.1 JVM由那些部分组成，运行流程是什么？

JVM是什么

1Java Virtual Machine Java程序的运行环境（java二进制字节码的运行环境）

好处：

• 一次编写，到处运行

• 自动内存管理，垃圾回收机制

JVM由哪些部分组成，运行流程是什么？

从图中可以看出 JVM 的主要组成部分

• ClassLoader（类加载器）
• Runtime Data Area（运行时数据区，内存分区）
• Execution Engine（执行引擎）
• Native Method Library（本地库接口）

运行流程：

（1）类加载器（ClassLoader）把Java代码转换为字节码

（2）运行时数据区（Runtime Data Area）把字节码加载到内存中，而字节码文件只是JVM的一套指令集规范，并不能直接交给底层系统去执行，而是有执行引擎运行

（3）执行引擎（Execution Engine）将字节码翻译为底层系统指令，再交由CPU执行去执行，此时需要调用其他语言的本地库接口（Native Method Library）来实现整个程序的功能。

1.2 什么是程序计数器？

程序计数器：线程私有的，内部保存的字节码的行号。

​ java虚拟机对于多线程是通过线程轮流切换并且分配线程执行时间。在任何的一个时间点上，一个处理器只会处理执行一个线程，如果当前被执行的这个线程它所分配的执行时间用完了【挂起】。处理器会切换到另外的一个线程上来进行执行。并且这个线程的执行时间用完了，接着处理器就会又来执行被挂起的这个线程。

 那么现在有一个问题就是，当前处理器如何能够知道，对于这个被挂起的线程，它上一次执行到了哪里？那么这时就需要从程序计数器中来回去到当前的这个线程他上一次执行的行号，然后接着继续向下执行。

​ 程序计数器是JVM规范中唯一一个没有规定出现OOM的区域，所以这个空间也不会进行GC。

1.3 什么是Java堆？

线程共享的区域：主要用来保存对象实例，数组等，当堆中没有内存空间可分配给实例，也无法再扩展时，则抛出OutOfMemoryError异常。

• 年轻代被划分为三部分，Eden区和两个大小严格相同的Survivor区，根据JVM的策略，在经过几次垃圾收集后，任然存活于Survivor的对象将被移动到老年代区间。
• 老年代主要保存生命周期长的对象，一般是一些老的对象
• 元空间保存的类信息、静态变量、常量、编译后的代码

为了避免方法区出现OOM，所以在java8中将堆上的方法区【永久代】给移动到了本地内存上，重新开辟了一块空间，叫做元空间。那么现在就可以避免掉OOM的出现了。

1.4 什么是虚拟机栈

Java Virtual machine Stacks (java 虚拟机栈)

• 每个线程运行时所需要的内存，称为虚拟机栈，先进后出

• 每个栈由多个栈帧（frame）组成，对应着每次方法调用时所占用的内存

• 每个线程只能有一个活动栈帧，对应着当前正在执行的那个方法

1.5方法区

1.5.1 概述

• 方法区(Method Area)是各个线程共享的内存区域

• 主要存储类的信息、运行时常量池

• 虚拟机启动的时候创建，关闭虚拟机时释放

• 如果方法区域中的内存无法满足分配请求，则会抛出OutOfMemoryError: Metaspace

1.5.2 常量池

可以看作是一张表，虚拟机指令根据这张常量表找到要执行的类名、方法名、参数类型、字面量等信息

1.6直接内存

1.7 堆栈的区别是什么？

1、栈内存一般会用来存储局部变量和方法调用，但堆内存是用来存储Java对象和数组的的。堆会GC垃圾回收，而栈不会。

2、栈内存是线程私有的，而堆内存是线程共有的。

3,、两者异常错误不同，但如果栈内存或者堆内存不足都会抛出异常。

栈空间不足：java.lang.StackOverFlowError。

堆空间不足：java.lang.OutOfMemoryError。

2 类加载器

2.1 什么是类加载器，类加载器有哪些?

要想理解类加载器的话，务必要先清楚对于一个Java文件，它从编译到执行的整个过程。

• 类加载器：用于装载字节码文件(.class文件)
• 运行时数据区：用于分配存储空间
• 执行引擎：执行字节码文件或本地方法
• 垃圾回收器：用于对JVM中的垃圾内容进行回收

实现通过类的全限定名获取该类的二进制字节流的代码块叫类加载器。主要作用就是将字节码文件加载到JVM中

主要有四种类加载器：

启动类加载器：

用来加载java核心类库的，java程序无法直接使用。

扩展类加载器：

用来加载java的扩展库，Java 虚拟机的实现会提供一个扩展库目录。该类加载器在此目录里面查找并加载 Java 类。

系统类加载器：

它根据应用的类路径来加载 Java 类

自定义类加载器：

通过继承java.lang.ClassLoader类的方式实现

上述三种类加载器的层次结构如下

类加载器的体系并不是“继承”体系，而是委派体系，类加载器首先会到自己的parent中查找类或者资源，如果找不到才会到自己本地查找。类加载器的委托行为动机是为了避免相同的类被加载多次。

2.2 什么是双亲委派模型？  

        

如果一个类加载器在接到加载类的请求时，它首先不会自己尝试去加载这个类，而是把这个请求任务委托给父类加载器去完成，依次递归，如果父类加载器可以完成类加载任务，就返回成功；只有父类加载器无法完成此加载任务时，才由下一级去加载。

2.3 JVM为什么采用双亲委派机制

（1）通过双亲委派机制可以避免某一个类被重复加载，当父类已经加载后则无需重复加载，保证唯一性。

（2）为了安全，保证类库API不会被修改

3 垃圾收回

3.1 简述Java垃圾回收机制

为了让程序员更专注于代码的实现，而不用过多的考虑内存释放的问题，所以，在Java语言中，有了自动的垃圾回收机制，也就是我们熟悉的GC(Garbage Collection)。

有了垃圾回收机制后，程序员只需要关心内存的申请即可，内存的释放由系统自动识别完成。

3.2 对象什么时候可以被垃圾器回收

简单一句就是：如果一个或多个对象没有任何的引用指向它了，那么这个对象现在就是垃圾，如果定位了垃圾，则有可能会被垃圾回收器回收。

要定位什么是垃圾，有两种方式来确定，第一个是引用计数法，第二个是可达性分析算法.

3.2.1 引用计数法

一个对象被引用了一次，在当前的对象头上递增一次引用次数，如果这个对象的引用次数为0，代表这个对象可回收

3.2.2 可达性分析算法

​ 现在的虚拟机采用的都是通过可达性分析算法来确定哪些内容是垃圾。

​ 会存在一个根节点【GC Roots】，引出它下面指向的下一个节点，再以下一个节点节点开始找出它下面的节点，依次往下类推。直到所有的节点全部遍历完毕。

根对象是那些肯定不能当做垃圾回收的对象，就可以当做根对象

局部变量，静态方法，静态变量，类信息

核心是：判断某对象是否与根对象有直接或间接的引用，如果没有被引用，则可以当做垃圾回收.

 

​ X,Y这两个节点是可回收的，但是并不会马上的被回收！！ 对象中存在一个方法【finalize】。当对象被标记为可回收后，当发生GC时，首先会判断这个对象是否执行了finalize方法，如果这个方法还没有被执行的话，那么就会先来执行这个方法，接着在这个方法执行中，可以设置当前这个对象与GC ROOTS产生关联，那么这个方法执行完成之后，GC会再次判断对象是否可达，如果仍然不可达，则会进行回收，如果可达了，则不会进行回收。

​ finalize方法对于每一个对象来说，只会执行一次。如果第一次执行这个方法的时候，设置了当前对象与RC ROOTS关联，那么这一次不会进行回收。 那么等到这个对象第二次被标记为可回收时，那么该对象的finalize方法就不会再次执行了。

3.3 JVM 垃圾回收算法

3.3.1 标记清除算法

标记清除算法，是将垃圾回收分为2个阶段，分别是标记和清除。

1.根据可达性分析算法得出的垃圾进行标记

2.对这些标记为可回收的内容进行垃圾回收

标记清除算法也是有缺点的：

• 效率较低，标记和清除两个动作都需要遍历所有的对象，并且在GC时，需要停止应用程序，对于交互性要求比较高的应用而言这个体验是非常差的。
• （重要）通过标记清除算法清理出来的内存，碎片化较为严重，因为被回收的对象可能存在于内存的各个角落，所以清理出来的内存是不连贯的。

3.3.2 复制算法

​ 复制算法的核心就是，将原有的内存空间一分为二，每次只用其中的一块，在垃圾回收时，将正在使用的对象复制到另一个内存空间中，然后将该内存空间清空，交换两个内存的角色，完成垃圾的回收。

1）将内存区域分成两部分，每次操作其中一个。

2）当进行垃圾回收时，将正在使用的内存区域中的存活对象移动到未使用的内存区域。当移动完对这部分内存区域一次性清除。

3）周而复始。

优点：

• 在垃圾对象多的情况下，效率较高
• 清理后，内存无碎片

缺点：

• 分配的2块内存空间，在同一个时刻，只能使用一半，内存使用率较低

3.3.3 标记整理算法

​ 标记压缩算法是在标记清除算法的基础之上，做了优化改进的算法。和标记清除算法一样，也是从根节点开始，对对象的引用进行标记，在清理阶段，并不是简单的直接清理可回收对象，而是将存活对象都向内存另一端移动，然后清理边界以外的垃圾，从而解决了碎片化的问题。

 

1）标记垃圾。

2）需要清除向右边走，不需要清除的向左边走。

3）清除边界以外的垃圾。

优缺点同标记清除算法，解决了标记清除算法的碎片化的问题，同时，标记压缩算法多了一步，对象移动内存位置的步骤，其效率也有有一定的影响。

与复制算法对比：复制算法标记完就复制，但标记整理算法得等把所有存活对象都标记完毕，再进行整理

3.4 分代收集算法

3.4.1 概述

在java8时，堆被分为了两份：新生代和老年代【1：2】，在java7时，还存在一个永久代。

对于新生代，内部又被分为了三个区域。Eden区，S0区，S1区【8：1：1】

当对老年代代产生GC：Major GC

当对新生代和老年代产生FullGC： 新生代 + 老年代完整垃圾回收，暂停时间长，应尽力避免

3.4.2工作机制

• 新创建的对象，都会先分配到eden区

 

• 当伊甸园内存不足，标记伊甸园与 from（现阶段没有）的存活对象

• 将存活对象采用复制算法复制到 to 中，复制完毕后，伊甸园和 from 内存都得到释放

 

• 经过一段时间后伊甸园的内存又出现不足，标记eden区域to区存活的对象，将存活的对象复制到from区

 

• 当幸存区对象熬过几次回收（最多15次），晋升到老年代（幸存区内存不足或大对象会导致提前晋升）

MinorGC、 Mixed GC 、 FullGC的区别是什么

 

• MinorGC【young GC】发生在新生代的垃圾回收，暂停时间短（STW）

• Mixed GC 新生代 + 老年代部分区域的垃圾回收，G1 收集器特有

• FullGC： 新生代 + 老年代完整垃圾回收，暂停时间长（STW），应尽力避免？

 3.5  JVM 有哪些垃圾回收器

在jvm中，实现了多种垃圾收集器，包括：

• 串行垃圾收集器

• 并行垃圾收集器

• CMS（并发）垃圾收集器

• G1垃圾收集器

3.5.1 串行垃圾收集器

Serial和Serial Old串行垃圾收集器，是指使用单线程进行垃圾回收，堆内存较小，适合个人电脑

• Serial 作用于新生代，采用复制算法

• Serial Old 作用于老年代，采用标记-整理算法

垃圾回收时，只有一个线程在工作，并且java应用中的所有线程都要暂停（STW），等待垃圾回收的完成。

 3.5.2 并行垃圾收集器 

Parallel New和Parallel Old是一个并行垃圾回收器，JDK8默认使用此垃圾回收器

• Parallel New作用于新生代，采用复制算法

• Parallel Old作用于老年代，采用标记-整理算法

垃圾回收时，多个线程在工作，并且java应用中的所有线程都要暂停（STW），等待垃圾回收的完成。

3.5.3 CMS（并发）垃圾收集器 

CMS全称 Concurrent Mark Sweep，是一款并发的、使用标记-清除算法的垃圾回收器，该回收器是针对老年代垃圾回收的，是一款以获取最短回收停顿时间为目标的收集器，停顿时间短，用户体验就好。其最大特点是在进行垃圾回收时，应用仍然能正常运行。

3.6 G1垃圾回收器 

3.6.1 概述
应用于新生代和老年代，在JDK9之后默认使用****G1

划分成多个区域，每个区域都可以充当 eden，survivor，old， humongous，其中 humongous 专为大对象准备

采用复制算法

响应时间与吞吐量兼顾

分成三个阶段：新生代回收、并发标记、混合收集

如果并发失败（即回收速度赶不上创建新对象速度），会触发 Full GC

3.6.2 Young Collection(年轻代垃圾回收) 

初始时，所有区域都处于空闲状态

创建了一些对象，挑出一些空闲区域作为伊甸园区存储这些对象

 

当伊甸园需要垃圾回收时，挑出一个空闲区域作为幸存区，用复制算法复制存活对象，需要暂停用户线程 

 

 

• 随着时间流逝，伊甸园的内存又有不足

• 将伊甸园以及之前幸存区中的存活对象，采用复制算法，复制到新的幸存区，其中较老对象晋升至老年代

 

 

3.6.3 Young Collection + Concurrent Mark (年轻代垃圾回收+并发标记) 

当老年代占用内存超过阈值(默认是45%)后，触发并发标记，这时无需暂停用户线程

 

• 并发标记之后，会有重新标记阶段解决漏标问题，此时需要暂停用户线程。

• 这些都完成后就知道了老年代有哪些存活对象，随后进入混合收集阶段。此时不会对所有老年代区域进行回收，而是根据暂停时间目标优先回收价值高（存活对象少）的区域（这也是 Gabage First 名称的由来）。

3.6.4 Mixed Collection (混合垃圾回收) 

复制完成，内存得到释放。进入下一轮的新生代回收、并发标记、混合收集.

 4 JVM实践（调优）

4.1 JVM 调优的参数可以在哪里设置参数值

springboot项目，可以在项目启动的时候，java -jar中加入参数就行了

4.2 用的 JVM 调优的参数都有哪些

对于JVM调优，主要就是调整年轻代、年老大、元空间的内存空间大小及使用的垃圾回收器类型。

1）设置堆的初始大小和最大大小，为了防止垃圾收集器在初始大小、最大大小之间收缩堆而产生额外的时间，通常把最大、初始大小设置为相同的值。

-Xms：设置堆的初始化大小

-Xmx：设置堆的最大大小

2） 设置年轻代中Eden区和两个Survivor区的大小比例。该值如果不设置，则默认比例为8:1:1。Java官方通过增大Eden区的大小，来减少YGC发生的次数，但有时我们发现，虽然次数减少了，但Eden区满

的时候，由于占用的空间较大，导致释放缓慢，此时STW的时间较长，因此需要按照程序情况去调优。

-XXSurvivorRatio=3，表示年轻代中的分配比率：survivor:eden = 2:3

 3）年轻代和老年代默认比例为1：2。可以通过调整二者空间大小比率来设置两者的大小。

-XX:newSize   设置年轻代的初始大小
-XX:MaxNewSize   设置年轻代的最大大小，  初始大小和最大大小两个值通常相同

4)使用非占用的垃圾收集器。

XX:+UseConcMarkSweepGC老年代使用CMS收集器降低停顿。

4.3 说一下 JVM 调优的工具？

4.3.1 命令工具

4.3.1.1 jps（Java Process Status）

输出JVM中运行的进程状态信息(现在一般使用jconsole)

4.3.1.2 jstack

查看java进程内线程的堆栈信息。

jstack [option] <pid>  

4.3.1.3 jmap

用于生成堆转存快照

jmap [options] pid 内存映像信息

jmap -heap pid 显示Java堆的信息

jmap -dump:format=b,file=heap.hprof pid

​ format=b表示以hprof二进制格式转储Java堆的内存
​ file=用于指定快照dump文件的文件名。

4.3.1.4 jhat 

用于分析jmap生成的堆转存快照

4.3.1.5 jstat

是JVM统计监测工具。可以用来显示垃圾回收信息、类加载信息、新生代统计信息等。

4.3.2 可视化工具

4.3.2.1 jconsole

用于对jvm的内存，线程，类 的监控，是一个基于 jmx 的 GUI 性能监控工具

打开方式：java 安装目录 bin目录下 直接启动 jconsole.exe 就行

可以内存、线程、类等信息

 

 4.3.2.2 VisualVM：故障处理工具

能够监控线程，内存情况，查看方法的CPU时间和内存中的对 象，已被GC的对象，反向查看分配的堆栈

打开方式：java 安装目录 bin目录下 直接启动 jvisualvm.exe就行

监控程序运行情况

 

查看运行中的dump

 

 查看堆中的信息

4.4 java内存泄露的排查思路 

原因：

如果线程请求分配的栈容量超过java虚拟机栈允许的最大容量的时候，java虚拟机将抛出一个StackOverFlowError异常

如果java虚拟机栈可以动态拓展，并且扩展的动作已经尝试过，但是目前无法申请到足够的内存去完成拓展，或者在建立新线程的时候没有足够的内存去创建对应的虚拟机栈，那java虚拟机将会抛出一个OutOfMemoryError异常

如果一次加载的类太多，元空间内存不足，则会报OutOfMemoryError: Metaspace

1、通过jmap指定打印他的内存快照 dump

 

有的情况是内存溢出之后程序则会直接中断，而jmap只能打印在运行中的程序，所以建议通过参数的方式的生成dump文件，配置如下：

-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/home/app/dumps/ 指定生成后文件的保存目录

 

2、通过工具， VisualVM（Ecplise MAT）去分析 dump文件

VisualVM可以加载离线的dump文件，如下图

文件–>装入—>选择dump文件即可查看堆快照信息

3、通过查看堆信息的情况，可以大概定位内存溢出是哪行代码出了问题 

 4、找到对应的代码，通过阅读上下文的情况，进行修复即可

4.5 CPU飙高排查方案与思路

1.使用top命令查看占用cpu的情况

2.通过top命令查看后，可以查看是哪一个进程占用cpu较高，上图所示的进程为：30978

3.查看当前线程中的进程信息

ps H -eo pid,tid,%cpu | grep 40940

pid 进行id

tid 进程中的线程id

% cpu使用率

 

 4.通过上图分析，在进程30978中的线程30979占用cpu较高

注意：上述的线程id是一个十进制，我们需要把这个线程id转换为16进制才行，因为通常在日志中展示的都是16进制的线程id名称

转换方式：

在linux中执行命令

printf "%x\n" 30979

5.可以根据线程 id 找到有问题的线程，进一步定位到问题代码的源码行号

执行命令

jstack 30978   此处是进程id