性能优化专题 - JVM 性能优化 - 04 - GC算法与调优
目录导航
-
- 前言
- Garbage Collect(垃圾回收)
-
- 如何确定一个对象是垃圾？
-
- 引用计数法
- 可达性分析
- 垃圾收集算法
-
- 标记-清除(Mark-Sweep)
- 复制(Copying)
- 标记-整理(Mark-Compact)
- 分代收集算法
- 内存分配策略
- 垃圾收集器分类
- 垃圾收集器
-
- Serial收集器
- ParNew收集器
- Parallel Scavenge收集器
- Serial Old收集器
- Parallel Old收集器
- CMS收集器
- G1收集器
- GZC收集器
- 常见问题
-
- 吞吐量和停顿时间
- 如何选择合适的垃圾收集器？
- 对于G1收集
- 如何开启需要的垃圾收集器
- 内存调优
-
- 虚拟机工具
- 工具命令测试
- 写在最后
前言
性能优化专题共计四个部分，分别是：
- Tomcat 性能优化
- MySql 性能优化
- JVM 性能优化
- 性能测试
本节是性能优化专题第三部分 —— JVM 性能优化篇，共计六个小节，分别是：
- JVM介绍与入门
- 类文件讲解
- 字节码执行引擎
- GC算法与调优
- Java内存模型与锁优化
- Linux性能监控与调优
通过这六节的学习，你将学到：
➢ 了解JVM内存模型以及每个分区详解。
➢ 熟悉运行时数据区，特别是堆内存结构和特点。
➢ 熟悉GC三种收集方法的原理和特点。
➢ 熟练使用GC调优工具，快速诊断线上问题。
➢ 生产环境CPU负载升高怎么处理？
➢ 生产环境给应用分配多少线程合适？
➢ JVM字节码是什么东西？
Garbage Collect(垃圾回收)
之前说堆内存中有垃圾回收，比如Young区的Minor GC，Old区的Major GC，Young区和Old区的Full GC。
但是对于一个对象而言，怎么确定它是垃圾？是否需要被回收？怎样对它进行回收？等等这些问题我们还需要详细探索。
因为Java是自动做内存管理和垃圾回收的，如果不了解垃圾回收的各方面知识，一旦出现问题我们很难进行排查和解决，自动垃圾回收机制就是寻找Java堆中的对象，并对对象进行分类判别，寻找出正在使用的对象和已经不会使用的对象，然后把那些不会使用的对象从堆上清除 。
关于运行时数据区各个部门的垃圾回收问题
程序计数器、 虚拟机栈、 本地方法栈3个区域随线程而生，随线程而灭；栈中的栈帧随着方法的进入和退出而有条不紊地执行着出栈和入栈操作。 每一个栈帧中分配多少内存基本上是在类结构确定下来时就已知的（尽管在运行期会由JIT编译器进行一些优化，但在本章基于概念模型的讨论中，大体上可以认为是编译期可知的），因此这几个区域的内存分配和回收都具备确定性，在这几个区域内就不需要过多考虑回收的问题，因为方法结束或者线程结束时，内存自然就跟随着回收了。 而Java堆和方法区则不一样，一个接口中的多个实现类需要的内存可能不一样，一个方法中的多个分支需要的内存也可能不一样，我们只有在程序处于运行期间时才能知道会创建哪些对象，这部分内存的分配和回收都是动态的，垃圾收集器所关注的是这部分内存。
回收方法区
很多人认为方法区（或者HotSpot虚拟机中的永久代）是没有垃圾收集的，Java虚拟机规范中确实说过可以不要求虚拟机在方法区实现垃圾收集，而且在方法区进行垃圾收集的“性价比”一般比较低：在堆中，尤其是在新生代中，常规应用进行一次垃圾收集一般可以回收70%~95%的空间，而永久代的垃圾收集效率远低于此。
永久代的垃圾收集主要回收两部分内容：废弃常量和无用的类。回收废弃常量与回收Java堆中的对象非常类似。以常量池中字面量的回收为例，假如一个字符串“abc”已经进入了常量池中，但是当前系统没有任何一个String对象是叫做“abc”的，换句话说是没有任何String对象引用常量池中的“abc”常量，也没有其他地方引用了这个字面量，如果在这时候发生内存回收，而且必要的话，这个“abc”常量就会被系统“请”出常量池。常量池中的其他类（接口）、方法、字段的符号引用也与此类似。
如何确定一个对象是垃圾？
要想进行垃圾回收，得先知道什么样的对象是垃圾。
引用计数法
对于某个对象而言，只要应用程序中持有该对象的引用，就说明该对象不是垃圾，如果一个对象没有任何指针对其引用，它就是垃圾。
弊端 :如果AB相互持有引用，导致永远不能被回收。
所以，现在的GC通常不采用此方法，我们以jdk1.8为例，做一个测试：
public class RefCountGC {
public Object instance = null;
private byte[] bigSize = new byte[2 * 1034 * 1024];
public static void main(String[] args) {
RefCountGC obj1 = new RefCountGC();
RefCountGC obj2 = new RefCountGC();
obj1.instance = obj2;
obj2.instance = obj1;
obj1 = null;
obj2 = null;
System.gc();
}
}
通过两个对象互相引用看是否被回收，我们知道，在引用计数法里，相互引用的对象是不会被回收的。
此时我们将此类的VM参数加入：
-verbose:gc -XX:+PrintGCDetails
# java -verbose[:class|gc|jni] 在输出设备上显示虚拟机运行信息。开启了GC日志输出
运行结果：
由4282k变为512k，说明被回收，也说明了引用计数法是不常用的。
可达性分析
通过GC Root的对象，开始向下寻找，看某个对象是否可达
能作为GC Root:类加载器、Thread、虚拟机栈的本地变量表、static成员、常量引用、本地方法栈的变量等。
-
虚拟机栈（栈帧中的本地变量表）中引用的对象。
-
方法区中类静态属性引用的对象。
-
方法区中常量引用的对象。
-
本地方法栈中JNI（即一般说的Native方法）引用的对象。
垃圾收集算法
已经能够确定一个对象为垃圾之后，接下来要考虑的就是回收，怎么回收呢？得要有对应的算法，下面介绍常见的垃圾回收算法。
标记-清除(Mark-Sweep)
标记
找出内存中需要回收的对象，并且把它们标记出来
此时堆中所有的对象都会被扫描一遍，从而才能确定需要回收的对象，比较耗时
清除
清除掉被标记需要回收的对象，释放出对应的内存空间
缺点：
标记清除之后会产生大量不连续的内存碎片，空间碎片太多可能会导致以后在程序运行过程中需要分配较大对象时，无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。
(1)标记和清除两个过程都比较耗时，效率不高
(2)会产生大量不连续的内存碎片，空间碎片太多可能会导致以后在程序运行过程中需要分配较大对象时，无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。
复制(Copying)
将内存划分为两块相等的区域，每次只使用其中一块，如下图所示：
当其中一块内存使用完了，就将还存活的对象复制到另外一块上面，然后把已经使用过的内存空间一次清除掉。
缺点: 空间利用率降低。
标记-整理(Mark-Compact)
复制收集算法在对象存活率较高时就要进行较多的复制操作，效率将会变低。更关键的是，如果不想浪费50%的空间，就需要有额外的空间进行分配担保，以应对被使用的内存中所有对象都有100%存活的极端情况，所以老年代一般不能直接选用这种算法。
标记过程仍然与"标记-清除"算法一样，但是后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存。
其实上述过程相对"复制算法"来讲，少了一个"保留区“”
让所有存活的对象都向一端移动，清理掉边界意外的内存。
分代收集算法
既然上面介绍了3中垃圾收集算法，那么在堆内存中到底用哪一个呢？
为了增加垃圾回收的效率，JVM会根据对象存活周期的不同将内存分为几块，堆中分为新生代和老年代。
这样可以根据各个年代的特点采用最适当的收集算法。
在新生代中，每次垃圾收集时都发现有大批对象死去，只有少量存活，那就选用复制算法，只需要付出少量存活对象的复制成本就可以完成收集。
而老年代中因为对象存活率高、没有额外空间对它进行分配担保，就必须使用"标记-清除"或者"标记-整 理"算法来进行回收。
Young区：复制算法(对象在被分配之后，可能生命周期比较短，Young区复制效率比较高)
Old区：标记清除或标记整理(Old区对象存活时间比较长，复制来复制去没必要，不如做个标记再清理)
内存分配策略
- 优先分配Eden区
public class EdenTest {
public static void main(String[] args) {
byte[] data = new byte[1 * 1024 * 1024];
}
}
我们使用VM参数开启GC日志输出：
-verbose:gc -XX:+PrintGCDetails
得出结果为：
堆内存分配中，新生代的Eden区占用80%空间，接下来我们改变代码为：
public class EdenTest {
public static void main(String[] args) {
byte[] data = new byte[2 * 1024 * 1024];
}
}
得到结果为：
这里我们看到Eden区由原来的80%变为99%，说明，JVM在堆中的内存分配，优先放入Eden区中。
我个人机器测试的环境为：windows10、8G内存。这里分配的内存因人而异，看你的内存的大小而定，否则设置过大会出现直接分配到老年代的现象。
- 大对象直接分配到老年代
public class BigObjectIntoOldGen {
public static void main(String[] args) {
byte[] d1 = new byte[6 * 1024 * 1024];
}
}
-verbose:gc -XX:+PrintGCDetails -Xmx20M -Xms20M -Xmn10M -XX:PretenureSizeThreshold=6M
-Xmx：最大堆大小
-Xms：初始堆大小
-Xmn:年轻代大小
-XX:PretenureSizeThreshold:大于这个值的参数直接在老年代分配。
打印结果：
老年代占有60%，通过此参数的配置，对象的被直接分配到了老年代。
- 长期存活的对象分配老年代
-XX:MaxTenuringThreshold=15
每次GC还活着的对象，通过设置阈值，强行通过指令分配到老年代。
- 空间分配担保
-XX:+HandlePromotionFailure
检查老年代最大可用的连续空间是否大于历次晋升到老年代对象的平均大小。
我们测试一下：
public class SpaceGuarantee {
public static void main(String[] args) {
byte[] d1 = new byte[2 * 1024 * 1024];
byte[] d2 = new byte[2 * 1024 * 1024];
byte[] d3 = new byte[2 * 1024 * 1024];
byte[] d4 = new byte[4 * 1024 * 1024];
System.gc();
}
}
VM参数配置：
-verbose:gc -XX:+PrintGCDetails -Xmx20M -Xms20M -Xmn10M
打印结果：
新生代设置为10m，当内存分配到d4数组时，已经分配了6m给老生代，剩余4m新生代进行分配。
- 动态对象年龄对象
如果在Survivor空间中相同年龄所有对象大小的总和大于Survivor空间的一半，年龄大于或等于该年龄的对象就可以直接进入老年代
-XX:TargetSurvivorRatio
垃圾收集器分类
- 串行收集器->Serial和Serial Old
只能有一个垃圾回收线程执行，用户线程暂停。适用于内存比较小的嵌入式设备 。
- 并行收集器[吞吐量优先]->Parallel Scanvenge、Parallel Old
多条垃圾收集线程并行工作，但此时用户线程仍然处于等待状态。适用于科学计算、后台处理等若交互场景 。
- 并发收集器[停顿时间优先]->CMS、G1
用户线程和垃圾收集线程同时执行(但并不一定是并行的，可能是交替执行的)，垃圾收集线程在执行的时候不会停顿用户线程的运行。 适用于相对时间有要求的场景，比如Web 。
垃圾收集器
HotSpot有哪些收集器呢？
下图橙色部分代表新生代，绿色部分代表老生代
如果说收集算法是内存回收的方法论，那么垃圾收集器就是内存回收的具体实现。
Serial收集器
Serial收集器是最基本、发展历史最悠久的收集器，曾经（在JDK1.3.1入之前）是虚拟机新生代收集的唯一选择。
它是一种单线程收集器，不仅仅意味着它只会使用一个CPU或者一条收集线程去完成垃圾收集工作，更重要的是其到
在进行垃圾收集的时候需要暂停其他线程。
优点：简单高效，拥有很高的单线程收集效率
缺点：收集过程需要暂停所有线程
算法：复制算法 JVM
适用范围：新生代
应用：Client模式下的默认新生代收集器
ParNew收集器
可以把这个收集器理解为Serial收集器的多线程版本。
优点：在多CPU时，比Serial效率高。
缺点：收集过程暂停所有应用程序线程，单CPU咕时比Serial效率差。
算法：复制算法
适用范围：新生代
应用：运行在Server模式下的虚拟机中首选的新生代收集器
Parallel Scavenge收集器
Parallel Scavenge收集器是一个新生代收集器，它也是适用复制算法的收集器，又是并行的多线程收集器，看上去和ParNew一样，但是Parallel Scanvenge更关注系统的吞吐量 。
吞吐量=运行用户代码的时间/(运行用户代码的时间+垃圾收集时间)
比如虚拟机总共运行了100分钟，垃圾收集时间用了1分钟，吞吐量=(100-1)/100=99%。
若吞吐量越大，意味着垃圾收集的时间越短，则用户代码可以充分利用CPU资源，尽快完成程序的运算任务。
-XX:MaxGCPauseMillis
# 控制最大的垃圾收集停顿时间
-XX:GCRatio
# 直接设置吞吐量的大小。
Serial Old收集器
Serial Old收集器是Serial收集器的老年代版本，也是一个单线程收集器，不同的是采用"标记-整理算法"，运行过程和Serial收集器一样。
Parallel Old收集器
Parallel Old收集器是Parallel Scavenge收集器的老年代版本，使用多线程和"标记-整理算法"进行垃圾回收。
CMS收集器
CMS(Concurrent Mark Sweep)收集器是一种以获取 最短回收停顿时间 为目标的收集器。
采用的是"标记-清除算法",整个过程分为5步：
(1)初始标记: CMS initial mark 标记GC Roots能关联到的对象 Stop The World—>速度很快。
- 标记老年代中所有的GC Roots对象，如下图节点1；
- 标记年轻代中活着的对象引用到的老年代的对象，如下图节点2、3；
(2)并发标记 ：CMS concurrent mark 进行GC Roots Tracing。
从“初始标记”阶段标记的对象开始找出所有存活的对象;
(3)预清理阶段。这个阶段就是用来处理前一个阶段因为引用关系改变导致没有标记到的存活对象的，它会扫描所有标记为Direty的Card 如下图所示。
在并发标记阶段，节点3的引用指向了6；则会把节点3的card标记为Dirty。
预清理：预清理，也是用于标记老年代存活的对象，目的是为了让重新标记阶段的STW尽可能短
(3)重新标记： CMS remark 修改并发标记因用户程序变动的内容 Stop The World。
该阶段的任务是完成标记整个年老代的所有的存活对象。
(4)并发清除 ：CMS concurrent sweep。
这个阶段主要是清除那些没有标记的对象并且回收空间。
由于整个过程中，并发标记和并发清除，收集器线程可以与用户线程一起工作，所以总体上来说，CMS收集
器的内存回收过程是与用户线程一起并发地执行的。
优点：并发收集、低停顿 缺点：产生大量空间碎片、并发阶段会降低吞吐量。
G1收集器
G1收集器在JDK 7正式作为商用的收集器。
与前几个收集器相比，G1有以下特点
-
并行与并发
-
分代收集（仍然保留了分代的概念）
-
空间整合（整体上属于“标记-整理”算法，不会导致空间碎片）
-
可预测的停顿（比CMS更先进的地方在于能让使用者明确指定一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒）
使用G1收集器时，Java堆的内存布局与就与其他收集器有很大差别，它将整个Java堆划分为多个大小相等的独立区域（Region），虽然还保留有新生代和老年代的概念，但新生代和老年代不再是物理隔离的了，它们都是一部分Region（不需要连续）的集合。
工作过程可以分为如下几步:
- 初始标记（Initial Marking） 标记以下GC Roots能够关联的对象，并且修改TAMS的值，需要暂停用户线程。
- 并发标记（Concurrent Marking） 从GC Roots进行可达性分析，找出存活的对象，与用户线程并发执行。
- 最终标记（Final Marking） 修正在并发标记阶段因为用户程序的并发执行导致变动的数据，需暂停用户线程。
- 筛选回收（Live Data Counting and Evacuation） 对各个Region的回收价值和成本进行排序，根据用户所期望的。
G1的内存模型：
G1的分代模型：
G1的分区模型：
G1的收集集合：
GZC收集器
ZGC原理:
ZGC在指针上做标记，在访问指针时加入Load Barrier（读屏障），比如当对象正被GC移动，指针上的颜色就会不对，这个屏障就会先把指针更新为有效地址再返回，也就是，永远只有单个对象读取时有概率被减速，而不存在为了保持应用与GC一致而粗暴整体的Stop The World。
Colored Pointer 和 Load Barrier（并发执行的保证机制）
GZC的内存结构：
ZGC将堆划分为Region作为清理，移动，以及并行GC线程工作分配的单位。分为有2MB，32MB，N× 2MB 三种Size Groups，动态地创建和销毁Region，动态地决定Region的大小。
GZC的回收过程：
- Pause Mark Start ：初始停顿标记
停顿JVM，标记Root对象，1、2、4 三个被标记为live
- Concurrent Mark ：并发标记
并发地递归标记其他对象，5、8也被标记为live
- Relocate ：移动对象
对比发现3、6、7是过期对象，也就是中间的两个灰色region需要被压缩清理，所以陆续将4、5、8 对象移动到最右边的新Region。移动过程中，有个forward table记录这种转向
- Remap ： 修正指针
最后将指针更新指向新地址
常见问题
吞吐量和停顿时间
停顿时间->垃圾收集器做垃圾回收终端应用执行响应的时间
吞吐量->运行用户代码时间/(运行用户代码时间+垃圾收集时间)
停顿时间越短就越适合需要和用户交互的程序，良好的响应速度能提升用户体验；
高吞吐量则可以高效地利用CPU时间，尽快完成程序的运算任务，主要适合在后台运算而不需要太多交互的任务。
这两个指标也是评价垃圾回收器好处的标准，其实调优也就是在观察者两个变量。
如何选择合适的垃圾收集器？
-
优先调整堆的大小让服务器自己来选择
-
如果内存小于100M，使用串行收集器
-
如果是单核，并且没有停顿时间要求，使用串行或JVM自己选
-
如果允许停顿时间超过1秒，选择并行或JVM自己选
-
如果响应时间最重要，并且不能超过1秒，使用并发收集器
对于G1收集
JDK 7开始使用，JDK 8非常成熟，JDK 9默认的垃圾收集器，适用于新老生代。
G1收集器的使用场景？
（1）50%以上的堆被存活对象占用
（2）对象分配和晋升的速度变化非常大
（3）垃圾回收时间比较长
如何开启需要的垃圾收集器
（1）串行
-XX：+UseSerialGC
-XX：+UseSerialOldGC
（2）并行(吞吐量优先)：
-XX：+UseParallelGC
-XX：+UseParallelOldGC
（3）并发收集器(响应时间优先)
-XX：+UseConcMarkSweepGC
-XX：+UseG1GC
内存调优
虚拟机工具
在调优之前，我们需要了解以下几个常见的JVM分析工具：
- 指令集：
- jps： JavaVirtual Machine Process Status Tool。 jps是jdk提供的一个查看当前java进程的小工具。非常简单实用。
- jstat：Java Virtual Machine statistics monitoring tool。Jstat是JDK自带的一个轻量级小工具。它位于java的bin目录下，主要利用JVM内建的指令对Java应用程序的资源和性能进行实时的命令行的监控，包括了对Heap size和垃圾回收状况的监控。
- jinfo：Java Configuration Info。实时调整和查看虚拟机参数。
- jmap：Java Virtual Machine Memory Map。它可以生成 java 程序的 dump 文件， 也可以查看堆内对象示例的统计信息、查看 ClassLoader 的信息以及 finalizer 队列。
- jhat：Java Heap Analysis Tool。是用来分析java堆的命令，可可以将对中的对象以html的形式展示，包括对象的数量、大小等信息，并支持对象查询语言 （OQL）。
- jstack：Java Virtual Machine Stack Trace for Java。jstack是java虚拟机自带的一种堆栈跟踪工具。jstack用于打印出给定的java进程ID或core file或远程调试服务的Java堆栈信息。
- JMX：Java Management Extensions。可以方便的管理正在运行中的Java程序。常用于管理线程，内存，日志Level，服务重启，系统环境等。
JConsole和JVisualVM中能够监控到JAVA应用程序和JVM的相关信息都是通过JMX实现的。
- 工具类：
EclipseMemoryAnalyzer
工具命令测试
- jstack
首先我们上一段死锁代码，通过jstack分析堆信息。
//运行主类
public class DeadLockDemo {
public static void main(String[] args) {
DeadLock d1=new DeadLock(true);
DeadLock d2=new DeadLock(false);
Thread t1=new Thread(d1);
Thread t2=new Thread(d2);
t1.start();
t2.start();
}
}
//定义锁对象
class MyLock{
public static Object obj1= new Object();
public static Object obj2= new Object();
}
//死锁代码
class DeadLock implements Runnable{
private boolean flag;
DeadLock(boolean flag){
this.flag=flag;
}
public void run() {
if(flag) {
while(true) {
synchronized(MyLock.obj1) {
System.out.println(Thread.currentThread().getName()+"----if获得obj1锁");
synchronized(MyLock.obj2) {
System.out.println(Thread.currentThread().getName()+"----if获得obj2锁");
}
}
}
} else {
while(true){
synchronized(MyLock.obj2) {
System.out.println(Thread.currentThread().getName()+"----否则获得obj2锁");
synchronized(MyLock.obj1) {
System.out.println(Thread.currentThread().getName()+"----否则获得obj1锁");
}
}
}
}
}
}
运行此DEMO，然后通过jps查看进程号：
输出日志：
通过堆文件也可以定位到问题所在：
- jstat
首先我们准备了一个关于Netty客户端与服务端的demo，这里略过内容，详情代码参考文末github地址链接。
这里值得一提的是服务端的VM参数配置：
-Xmx1024m
-Xms1024m
-XX:+PrintGCDetails
-XX:+HeapDumpOnOutOfMemoryError
-Xloggc:e:\gc.log
#指定GC log的位置，以文件输出
-XX:HeapDumpPath=e:\server.dump
# Heap Dump 是 Java进程所使用的内存情况在某一时间的一次快照。这里以文件的形式持久化到磁盘中。
分别运行服务端与客户端后，我们发现：
这里我通过不断地使客户端给服务端发送消息，导致内存溢出。我们依据自定义目录生成的dump文件进行分析：
打开mat软件：选择：
然后选择Leak Suspects Report，查看内存泄露分析的相关内容：
这里就看到概览和问题报告：
我们可以通过不同的视图查看堆内存引用以及对象引用的占用情况，从而进行一系列分析与调优。
这里给出mat关于软件使用的官方文档说明：https://help.eclipse.org/2020-12/index.jsp?topic=/org.eclipse.mat.ui.help/welcome.html
写在最后
本节代码下载地址为：https://github.com/harrypottry/jvmDemo
更多架构知识，欢迎关注本套系列文章：Java架构师成长之路