对象的销毁
java语言开始学习的时候，就骄傲的告诉大家作为一个java程序员我们具有c++们羡慕不已的技能：不用关心内存是怎么收回来的。
前面讲的都是类、对象是怎么来的，这节我们讲讲它是怎么没的。
# 6.1 jvm参数
在学垃圾回收器之前，我们先要知道，jvm参数是怎么回事。因为配置各种回收器，必须对应各种参数设置。
在jvm中有很多的参数可以进行设置，绝大部分的参数保持默认即可。
# 6.1.1 分类
jvm的参数类型看上去杂乱，其实一共就三类，分别是：
标准参数（-）
所有的JVM实现都必须实现这些参数的功能，而且向后兼容
- -help
- -version
非标准参数（-X）
默认jvm实现这些参数的功能，但是并不保证所有jvm实现都满足，且不保证向后兼容
- -Xint
- -Xcomp
非Stable参数（-XX）
各个jvm实现会有所不同，将来可能会随时取消，需要慎重使用
- -XX:newSize
- -XX:+UseSerialGC
在使用X或XX参数的时候，一定要先知道自己的jdk版本，并查对应的手册确认。
# 6.1.2 标准参数
1）概述
jvm的标准参数，一般都是很稳定的，在未来的JVM版本中不会改变。
使用java -help列出来的就是标准参数。
#打印帮助信息
shawn@macpro:~ > java -help
用法：java [options] <主类> [args...]
（执行类）
或 java [options] -jar <jar 文件> [args...]
（执行 jar 文件）
……
此处省略n行
2）实例一
我们最熟悉的jdk版本查看
shawn@macpro:~ > java -version
java version "11.0.2" 2019-01-15 LTS #版本号
Java(TM) SE Runtime Environment 18.9 (build 11.0.2+9-LTS)
Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.2+9-LTS, mixed mode) #运行模式：server
附：关于运行模式（了解）
- Server VM的初始堆空间会大一些，启动慢运行快。
- Client VM相对来讲会保守一些，初始堆空间会小一些，启动快速度慢。
- JVM在启动的时候会根据硬件和操作系统自动选择使用Server还是Client类型的JVM。
- 32位操作系统
- 如果是Windows系统，不论硬件配置如何，都默认使用Client类型的JVM。
- 如果是其他操作系统上，2G，2核以上默认使用server模式，否则使用client模式。
- 64位操作系统
- 只有server类型，不支持client类型。
3）实例二
通过-D设置系统属性参数
public class TestJVM {
public static void main(String[] args) {
//获取命令行 -D设置的参数
String str = System.getProperty("str");
System.out.println(str);
}
}
将会输出abc
# 6.1.3 -X参数
1）概述
jvm的-X参数是非标准参数，也就意味着，在不同版本的jvm中，参数可能会有所不同
可以通过java -X查看非标准参数
这部分参数非常多，知道常用的几个即可
[root@node01 test]# java -X
-Xmixed 混合模式执行 (默认) #了解！
-Xint 仅解释模式执行 #了解！
-Xbootclasspath:<用 : 分隔的目录和 zip/jar 文件>
设置搜索路径以引导类和资源
-Xbootclasspath/a:<用 : 分隔的目录和 zip/jar 文件>
附加在引导类路径末尾
-Xbootclasspath/p:<用 : 分隔的目录和 zip/jar 文件>
置于引导类路径之前
-Xdiag 显示附加诊断消息
-Xnoclassgc 禁用类垃圾收集
-Xincgc 启用增量垃圾收集
-Xloggc:<file> 将 GC 状态记录在文件中 (带时间戳)
-Xbatch 禁用后台编译
-Xms<size> 设置初始 Java 堆大小 #掌握！
-Xmx<size> 设置最大 Java 堆大小 #掌握！
-Xss<size> 设置 Java 线程堆栈大小 #掌握！
-Xprof 输出 cpu 配置文件数据
-Xfuture 启用最严格的检查, 预期将来的默认值
-Xrs 减少 Java/VM 对操作系统信号的使用 (请参阅文档)
-Xcheck:jni 对 JNI 函数执行其他检查
-Xshare:off 不尝试使用共享类数据
-Xshare:auto 在可能的情况下使用共享类数据 (默认)
-Xshare:on 要求使用共享类数据, 否则将失败。
-XshowSettings 显示所有设置并继续
-XshowSettings:all
显示所有设置并继续
-XshowSettings:vm 显示所有与 vm 相关的设置并继续
-XshowSettings:properties
显示所有属性设置并继续
-XshowSettings:locale
显示所有与区域设置相关的设置并继续
-X 选项是非标准选项, 如有更改, 恕不另行通知。
2）案例一：-Xint、-Xcomp、-Xmixed
在解释模式(interpreted mode)下，-Xint标记会强制JVM执行所有的字节码，当然这会降低运行速度，通常低10倍或更多。
-Xcomp参数与它（-Xint）正好相反，JVM在第一次使用时会把所有的字节码编译成本地代码，从而带来最大程度的优化。
- 然而，很多应用在使用-Xcomp也会有一些性能损失，当然这比使用-Xint损失的少，原因是-xcomp没有让JVM启用JIT编译器的全部功能。JIT编译器可以对是否需要编译做判断，如果所有代码都进行编译的话，对于一些只执行一次的代码就没有意义了。
-Xmixed是混合模式，将解释模式与编译模式进行混合使用，由jvm自己决定，这是jvm默认的模式，也是推荐使用的模式。
示例：强制设置运行模式
#强制设置为解释模式
shawn@macpro:~ > java -Xint -version
java version "11.0.2" 2019-01-15 LTS
Java(TM) SE Runtime Environment 18.9 (build 11.0.2+9-LTS)
Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.2+9-LTS, interpreted mode)
#强制设置为编译模式
shawn@macpro:~ > java -Xcomp -version
java version "11.0.2" 2019-01-15 LTS
Java(TM) SE Runtime Environment 18.9 (build 11.0.2+9-LTS)
Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.2+9-LTS, compiled mode)
#默认的混合模式
shawn@macpro:~ > java -Xmixed -version
java version "11.0.2" 2019-01-15 LTS
Java(TM) SE Runtime Environment 18.9 (build 11.0.2+9-LTS)
Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.2+9-LTS, mixed mode)
3）案例二：-Xms与-Xmx参数
-Xms与-Xmx分别是设置jvm的堆内存的初始大小和最大大小。
- -Xmx2048m：等价于-XX:MaxHeapSize，设置JVM最大堆内存为2048M。
- -Xms512m：等价于-XX:InitialHeapSize，设置JVM初始堆内存为512M。
具体案例前面设置溢出的时候配置过，不再赘述。
# 6.1.4 -XX参数
-XX参数也是非标准参数，主要用于改变jvm的一些基础行为，比如垃圾回收行为、jvm的调优、输出debug调试信息等。
可以通过以下方式查看（非常多！）：
- java -XX:+PrintFlagsFinal ： 被修改过，最终生效的配置
- java -XX:+PrintFlagsInitial ： jvm初始化的配置
-XX参数的使用有2种方式，一种是boolean类型，一种是非boolean类型：
- boolean类型
- 格式：
-XX:[+-]<name>表示启用或禁用<name>属性 - 如：
-XX:+DisableExplicitGC表示禁用手动调用gc操作，也就是说调用System.gc()无效
- 格式：
- 非boolean类型
- 格式：
-XX:<name>=<value>表示<name>属性的值为<value> - 如：
-XX:NewRatio=4表示新生代和老年代的比值为1:4
- 格式：
这类参数的案例，下面多得是，我们到垃圾收集一节再详细讲解。
#行为参数(功能开关)
-XX:-DisableExplicitGC 禁止调用System.gc()；但jvm的gc仍然有效
-XX:+MaxFDLimit 最大化文件描述符的数量限制
-XX:+ScavengeBeforeFullGC 新生代GC优先于Full GC执行
-XX:+UseGCOverheadLimit 在抛出OOM之前限制jvm耗费在GC上的时间比例
-XX:-UseConcMarkSweepGC 对老生代采用并发标记交换算法进行GC
-XX:-UseParallelGC 启用并行GC
-XX:-UseParallelOldGC 对Full GC启用并行，当-XX:-UseParallelGC启用时该项自动启用
-XX:-UseSerialGC 启用串行GC
-XX:+UseThreadPriorities 启用本地线程优先级
#性能调优
-XX:LargePageSizeInBytes=4m 设置用于Java堆的大页面尺寸
-XX:MaxHeapFreeRatio=70 GC后java堆中空闲量占的最大比例
-XX:MaxNewSize=size 新生成对象能占用内存的最大值
-XX:MaxPermSize=64m 老生代对象能占用内存的最大值
-XX:MinHeapFreeRatio=40 GC后java堆中空闲量占的最小比例
-XX:NewRatio=2 新生代内存容量与老生代内存容量的比例
-XX:NewSize=2.125m 新生代对象生成时占用内存的默认值
-XX:ReservedCodeCacheSize=32m 保留代码占用的内存容量
-XX:ThreadStackSize=512 设置线程栈大小，若为0则使用系统默认值
-XX:+UseLargePages 使用大页面内存
#调试参数
-XX:-CITime 打印消耗在JIT编译的时间
-XX:ErrorFile=./hs_err_pid<pid>.log 保存错误日志或者数据到文件中
-XX:-ExtendedDTraceProbes 开启solaris特有的dtrace探针
-XX:HeapDumpPath=./java_pid<pid>.hprof 指定导出堆信息时的路径或文件名
-XX:-HeapDumpOnOutOfMemoryError 当首次遭遇OOM时导出此时堆中相关信息
-XX:OnError="<cmd args>;<cmd args>" 出现致命ERROR之后运行自定义命令
-XX:OnOutOfMemoryError="<cmd args>;<cmd args>" 当首次遭遇OOM时执行自定义命令
-XX:-PrintClassHistogram 遇到Ctrl-Break后打印类实例的柱状信息，与jmap -histo功能相同
-XX:-PrintConcurrentLocks 遇到Ctrl-Break后打印并发锁的相关信息，与jstack -l功能相同
-XX:-PrintCommandLineFlags 打印在命令行中出现过的标记
-XX:-PrintCompilation 当一个方法被编译时打印相关信息
-XX:-PrintGC 每次GC时打印相关信息
-XX:-PrintGCDetails 每次GC时打印详细信息
-XX:-PrintGCTimeStamps 打印每次GC的时间戳
-XX:-TraceClassLoading 跟踪类的加载信息
-XX:-TraceClassLoadingPreorder 跟踪被引用到的所有类的加载信息
-XX:-TraceClassResolution 跟踪常量池
-XX:-TraceClassUnloading 跟踪类的卸载信息
-XX:-TraceLoaderConstraints 跟踪类加载器约束的相关信息
# 6.1.5 参数查询
如果想要查看正在运行的jvm就需要借助于jinfo命令查看。
1）起一个进程，让它处于运行中
public class App {
public static void main( String[] args ) throws InterruptedException {
while (true) {
System.out.println(System.currentTimeMillis());
Thread.sleep(1000);
}
}
}
2）jps查到他的进程号
shawn@macpro:~ > jps
44561
2691 Launcher
2692 App
2693 Jps
3）查询看运行参数
shawn@macpro:~ > jinfo -flags 2692
VM Flags:
-XX:CICompilerCount=3 -XX:InitialHeapSize=134217728 -XX:MaxHeapSize=2147483648 -XX:MaxNewSize=715653120 -XX:MinHeapDeltaBytes=524288 -XX:NewSize=44564480 -XX:OldSize=89653248 -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseFastUnorderedTimeStamps -XX:+UseParallelGC
#查看某一参数的值，用法：jinfo -flag <参数名> <进程id>
shawn@macpro:~ > jinfo -flag MaxHeapSize 2692
-XX:MaxHeapSize=2147483648
# 6.2 垃圾回收概述
# 6.2.1 背景
实际上，垃圾回收并不是java首创的。垃圾收集的历史远比java语言本身还要久
最早使用垃圾回收功能的语言是Lisp，于1960年诞生于麻省理工学院。
# 6.2.2 意义
jdk发展到今天垃圾回收已经相当完善，为什么还要学习它？
- 面试必问！（无力吐槽）
- 排查内存泄露、溢出等问题
- 系统默认配置不适合当前业务特殊场景的时候，必须手动调整参数
# 6.3 回收事件三要素
语文老师告诉我们：任何事情发生一定有三要素：时间、地点、人物
# 6.3.1 在哪收（地点）
根据上面我们的学习，大家对jvm里的内存空间有了清晰的认识。那么：
程序计数器、jvm虚拟机栈、本地方法栈，这些随着线程诞生和消亡，线程释放它就释放，无需回收。
方法区，这里是一些类信息和静态变量，也有回收的可能性，但是很鸡肋，收不回多少东西。
实际上，虚拟机规范也并不强制要求回收这里。
堆，这才是大头。因为运行期频繁创建和丢弃对象的事件都在这里发生！
所以，谈回收我们主要看堆。
# 6.3.2 什么时候收（时间）
回收我们是不需要管的，那么必然有对应的机制，或者说什么条件下满足了，触发了jvm的内存回收。
哪些条件呢？
在堆内存存储达到一定阈值之后
当年轻代或者老年代达到一定阈值，Java虚拟机无法再为新的对象分配内存空间了，那么Java虚拟机就会触发一次GC去回收掉那些已经不会再被使用到的对象
主动调用System.gc() 后尝试进行回收
手动调用System.gc()方法，通常这样会触发一次的Full GC，所以一般不推荐这个东西的使用，你会干扰jvm的运作
# 6.3.3 回收谁（人物）
回收谁？哪些对象能够被回收，哪些还不能？总得有个判断标准。
在编程语言界，有两种办法判定一个对象是否已消亡：
# 6.3.3.1 引用计数法
引用计数是历史最悠久的一种算法，最早George E. Collins在1960的时候首次提出，50年后的今天，该算法依然被很多编程语言使用。（了解即可，因为JVM不用！）
1）原理
假设有一个对象A，任何一个对象对A的引用，那么对象A的引用计数器+1，当引用失败时，对象A的引用计数器就-1，如果对象A的计数器的值为0，就说明对象A没有引用了，可以被回收。
2）优缺点
优点：
- 实时性较高，无需等到内存不够的时候，才开始回收，运行时根据对象的计数器是否为0，就可以直接回收。
- 在垃圾回收过程中，应用无需挂起。如果申请内存时，内存不足，则立刻报outofmember 错误。
- 区域性，更新对象的计数器时，只是影响到该对象，不会扫描全部对象。
缺点：
- 每次对象被引用时，都需要去更新计数器，有一点时间开销。
- 浪费CPU资源，即使内存够用，仍然在运行时进行计数器的统计。
- 无法解决循环引用问题。（最大的缺点）
3）案例：什么是循环引用？
class TestA{
public TestB b;
}
class TestB{
public TestA a;
}
public class Main{
public static void main(String[] args){
A a = new A();
B b = new B();
a.b=b;
b.a=a;
a = null; //释放资源
b = null; //释放资源
}
}
虽然a和b都为null，但是由于a和b存在循环引用，根据引用的理论，a和b永远都不会被回收。
事实上，以上代码我们在开发中是很可能存在的，我们的jvm也没有被撑爆。因为jvm没有采用这种算法。
那它用的啥呢？
# 6.3.3.2 可达性分析
1）概述
通过一系列称为“GC Roots”的根对象作为起始节点集，从这些节点开始，根据引用关系向下搜索，搜索过程所走过的路径称为“引用链”（Reference Chain），如果某个对象到GC Roots间没有任何引用链相连，就说明从GC Roots到这个对象不可达时，则证明此对象是不可能再被使用的，就是可以回收的对象。
JVM用的是这种算法！
2）GC Roots清单
在JVM虚拟机中，可作为GC Roots的对象包括以下几种：
- 在虚拟机栈（栈帧中的本地变量表）中引用的对象
- 在方法区中类静态属性引用的对象（类变量）。
- 在方法区中常量引用的对象，譬如字符串常量池（String Table）里的引用。
- 在本地方法栈中JNI（即通常所说的Native方法）引用的对象。
- 所有被同步锁（synchronized关键字）持有的对象。
- Java虚拟机内部的引用，如基本数据类型对应的Class对象，一些常驻的异常对象（比如NullPointExcepiton、OutOfMemoryError）等，还有系统类加载器。
- 反映Java虚拟机内部情况的JMXBean、JVMTI中注册的回调、本地代码缓存等。
3）附：对象的四类引用
在java中，对象的引用主要有4种，从上到下级别依次降低。不同的引用回收的态度不同
- 强引用
- 在程序代码之中普遍存在的引用赋值，即类似“Object obj=new Object()”这种引用关系。
- 无论任何情况下，内存用不回收，够就够，不够抛内存溢出异常。
- 软引用
- 用来描述一些还有用，但非必须的对象。被SoftReference包装的那些类
- 先回收没用的对象，收完后发现还不够，再触发二次回收，对软引用对象下手。
- 弱引用
- 用来描述那些非必须对象，强度比软引用更弱。被WeakReference包装的那些类
- 无论当前内存是否足够，垃圾收集一旦发生，弱引用直接回收。
- 虚引用（实际开发基本不用）
- 最弱的一种引用关系，一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象实例。
- 为一个对象设置虚引用关联的唯一目的只是为了能在这个对象被收集器回收时收到一个系统通知。
# 6.4 回收算法（策略）
回收是做一件事情，要完成这件事，我们需要采用什么样的策略？用什么样的思想会更稳妥？
这就涉及到回收的具体算法
# 6.4.1 标记清除法
1）概述
标记清除算法，是将垃圾回收分为2个阶段，分别是标记和清除。
- 标记：从根节点开始标记引用的对象。
- 清除：未被标记引用的对象就是垃圾对象，清理掉。
标记清除法可以说是最基础的收集算法，因为后续的收集算法大多都是以标记-清除算法为基础，对其缺点进行改进而得到的。
2）执行过程：
3）缺点：
- 执行效率较低，标记和清除两个动作都需要遍历所有的对象，并且在GC时，需要停止应用程序，对于交互性要求比较高的应用而言这个体验是非常差的。
- 通过标记清除算法清理出来的内存，碎片化较为严重，因为被回收的对象可能存在于内存的各个角落，所以清理出来的内存是不连贯的。
# 6.4.2 标记压缩算法
1）概述
也叫标记-整理，标记压缩算法是在标记清除算法的基础之上，做了优化改进的算法。
和标记清除算法一样，也是从根节点开始，对对象的引用进行标记
在清理阶段，并不是简单的清理未标记的对象，而是将存活的对象压缩到内存的一端，然后清理边界以外的垃圾，从而解决了碎片化的问题。
2）执行过程：
3）特点
- 该算法解决了标记清除算法的碎片化的问题，下一步分配内存的时候更方便
- 多了一步整理操作，对象需要移动内存位置，效率也好不到哪去。
# 6.4.3 标记复制算法
1）概述
复制算法的核心就是，将原有的内存空间一分为二，每次只用其中的一块，在垃圾回收时，将正在使用的对象复制到另一个内存空间中，然后将该内存空间清空，交换两个内存的角色，完成垃圾的回收。
2）过程
3）优缺点
优点：
- 在垃圾对象多的情况下，效率较高，因为要把存活的全部移动一遍
- 清理后，内存无碎片
缺点：
- 在垃圾对象比例少的情况下，不适用，如：年轻代这么用可以，老年代就不合适
- 分配的2块内存空间，在同一个时刻，只能使用一半，内存使用率较低
4）附：年轻代的标记复制算法
年轻代内存的回收就是典型的标记复制法
- sruvivor区有两个，一个from，另一个叫to，这俩交替互换角色
- 在GC开始的时候，对象只会存在于Eden区和名为“From”的Survivor区，Survivor区“To”是空的。
- 紧接着进行GC，Eden区中所有存活的对象都会被复制到“To”，而在“From”区中，仍存活的对象会根据他们的年龄值来决定去向。
- 年龄达到一定值(年龄阈值，可以通过-XX:MaxTenuringThreshold来设置) 的对象会被移动到年老代中，没有达到阈值的对象会被复制到“To”区域。
- 经过这次GC后，Eden区和From区已经被清空。这个时候，“From”和“To”会交换他们的角色，也就是新的“To”就是上次GC前的“From”，新的“From”就是上次GC前的“To”。不管怎样，都会保证名为To的Survivor区域是空的。
- GC会一直重复这样的过程，直到“To”区被填满，“To”区被填满之后，会将所有对象移动到年老代中。
# 6.4.4 分代
1）具体思想
确切的说，分代不算是一种算法，它是一种解决回收问题的思路：具体情况具体分析
在堆内存中，有些对象短暂存活有些则是长久存活，所以需要将堆内存进行分代，将短暂存活的对象放到一起，进行高频率的回收，长久存活的对象集中放到一起，进行低频率的回收
细粒度的控制不同区域，调节不同的回收频率，节约系统资源（回收期间系统要额外干活的！）。
分代算法其实就是这样的，根据回收对象的特点进行选择，在jvm中，年轻代适合使用复制算法，老年代适合使用标记清除或标记压缩算法。
2）相关概念
- 部分收集（Partial GC）
- 新生代收集（Minor GC/Young GC）：指目标只是新生代的垃圾收集。
- 老年代收集（Major GC/Old GC）：指目标只是老年代的垃圾收集。（CMS收集器）
- 混合收集（Mixed GC）：指目标是收集整个新生代以及部分老年代的垃圾收集。（G1收集器）
- 整堆收集（Full GC）
- 所有的内存整理一遍，包括堆和方法区。轻易不要触发
# 6.5 回收器（执行者）
前面我们讲了垃圾回收的算法，还需要有具体的实现。
策略有了，谁来执行呢？这事就落到任劳任怨的收集器头上了
在jvm中，实现了多种垃圾收集器，这些收集器种类繁多，看似乱七八糟，其实理清楚后很简单。
1）先明白几件事情
用户线程：java程序运行后，用户不停请求操作jvm内存，这些称为用户线程
GC线程：jvm系统进行垃圾回收启动的线程
串行：GC采用单线程，收集时停掉用户线程
并行：GC采用多线程，收集时同样要停掉用户线程
并发：用户线程和GC线程同步进行，这意义就不一样了
STW：stop the world ，暂停响应用户线程，只提供给GC线程工作来回收垃圾（很不爽的事情）
分代：垃圾收集器是要工作在某个代上的，可能是年轻代，老年代，有的可能两个代都能工作
组合：因为分代，所以得有组合，你懂得……
2）准备案例
在开始前，我们先准备一个内存堆积的案例，下面学习收集器，只需要在启动时指定不同的XX参数即可：
package cn.itcast.jvm;
import java.util.ArrayList;
import java.util.List;
import java.util.Properties;
import java.util.Random;
public class TestGC {
public static void main(String[] args) throws Exception {
List<Object> list = new ArrayList<Object>();
//模拟web中不停请求
while (true){
int sleep = new Random().nextInt(100);
if(System.currentTimeMillis() % 2 ==0){
//模拟释放，如果恰好请求时间是偶数，清空列表
list.clear();
}else{
//模拟业务，从db中查询了10000条记录
for (int i = 0; i < 10000; i++) {
Properties properties = new Properties();
properties.put("key_"+i, "value_" + System.currentTimeMillis() + i);
list.add(properties);
}
}
System.out.println("list大小为：" + list.size());
//模拟请求间隔，0-100ms随机
Thread.sleep(sleep);
}
}
}
# 6.5.1 串行
1）概述
其实是两个收集器，年轻代的叫 Serial ， 老年代的叫 Serial Old，很好记！
这是最基础的，历史最悠久的收集器。
听名字就知道，这个属于串行收集器，即：GC时，停掉用户线程，同时，GC本身也是只有一个线程在跑
2）原理
很简单，GC时暂停用户进程，新生代 Serial 采用复制算法，Serial Old采用标记整理算法。
3）优缺点
单线程 + STW，那么这个收集器还有存在的价值吗？
答案是：有！我们在吐槽单线程的同时，不要忘了，单线程带来的便捷性
实际上，Serial收集器依然是hotspot在客户端模式下的默认收集器，因为它足够简单有效，没有多线程GC的协调和额外开销，在单核或资源有限的环境下，单线程甚至比多线程还要高效。
而Serial Old则作为下面几款垃圾收集器的兜底措施，比如CMS、G1等处理不了老年代时，他们会自动启用SOld来做FullGC进行收集。
4）配置参数
- -XX:+UseSerialGC
- 指定年轻代和老年代都使用串行垃圾收集器
- -XX:+PrintGCDetails
- 打印垃圾回收的详细信息
5）操作案例
# 为了测试GC，将堆的初始和最大内存都设置为16M
# java代码使用本节开头的例子
-XX:+UseSerialGC -XX:+PrintGCDetails -Xms16m -Xmx16m
6）启动程序，可以看到下面信息：
[GC (Allocation Failure) [DefNew: 4416K->512K(4928K), 0.0046102 secs] 4416K->1973K(15872K), 0.0046533 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
[Full GC (Allocation Failure) [Tenured: 10944K->3107K(10944K), 0.0085637 secs] 15871K->3107K(15872K), [Metaspace: 3496K->3496K(1056768K)], 0.0085974 secs] [Times: user=0.02 sys=0.00, real=0.01 secs]
- DefNew
- 表示使用的是串行垃圾收集器。
- 4416K->512K (4928K)
- 表示，年轻代GC前，占有4416K内存，GC后，占有512K内存，总大小4928K
- 0.0046102 secs
- 表示，GC所用的时间，单位为秒。
- 4416K->1973K (15872K)
- 表示，GC前，堆内存占有4416K，GC后，占有1973K，总大小为15872K
- Full GC
- 表示，内存空间全部进行GC，老年代、元空间
# 6.5.2 并行
1）概述
ParNew收集器：
新生代的，无非就是将Serial的单线程换成多线程，它现在存在的唯一价值就是作为新生代收集器配合老年代的CMS收集器一起工作，并且在jdk9里也已不再推荐这套组合，而是推荐G1。
我们只需要知道的是：曾经，它存在过。
另外一对并行收集器：
Parallel Scavenge （新生代的） / Parallel Old （老年代的）
关于并行收集器，我们重点看Parallel这一对，这一对也是主流的jdk8下默认收集器
2）详解
Parallel这一对，它所关注的是系统的吞吐量。所谓吞吐量，反映的是用户线程在系统整体时间里可用的比例：
即： 吞吐量 = 用户代码运行时间 / ( 用户代码运行时间 + 垃圾收集器运行时间 )
这一点，从它的配置参数上直接就能看出来
3）参数
- -XX:+UseParallelGC
- 年轻代使用ParallelGC垃圾回收器，老年代使用串行回收器。
- -XX:+UseParallelOldGC
- 年轻代使用ParallelGC垃圾回收器，老年代使用ParallelOldGC垃圾回收器。
- -XX:MaxGCPauseMillis
- 设置最大的垃圾收集时的停顿时间，单位为毫秒
- 需要注意，ParallelGC为了达到设置的停顿时间，可能会调整堆大小或其他的参数，如果堆的大小设置的较小，就会导致GC工作变得很频繁，反而可能会影响到性能。
- 该参数使用需谨慎。
- -XX:GCTimeRatio
- 直接设置垃圾回收时间占程序运行时间的最大百分比，公式为1/(1+n)。
- 它的值为0~100之间的数字，默认值为99，也就是垃圾回收时间不能超过1%
- -XX:UseAdaptiveSizePolicy
- 自适应GC模式，垃圾回收器将自动调整年轻代、老年代等参数，达到吞吐量、堆大小、停顿时间之间的平衡。
- 一般用于，手动调整参数比较困难的场景，让收集器自动进行调整。
3）调试
#参数
-XX:+UseParallelGC -XX:+UseParallelOldGC -XX:MaxGCPauseMillis=100 -XX:+PrintGCDetails -Xms16m -Xmx16m
#打印的信息
[GC (Allocation Failure) [PSYoungGen: 4096K->480K(4608K)] 4096K->1840K(15872K), 0.0034307 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
[Full GC (Ergonomics) [PSYoungGen: 505K->0K(4608K)] [ParOldGen: 10332K->10751K(11264K)] 10837K->10751K(15872K), [Metaspace: 3491K->3491K(1056768K)], 0.0793622 secs] [Times: user=0.13 sys=0.00, real=0.08 secs]
PSYoungGen：年轻代，Parallel Scavenge
ParOldGen：老年代，Parallel Old
# 6.5.3 并发 - CMS
1）简介
CMS收集器，工作在老年代。
前面的收集器都是要停止用户线程的，而CMS收集器这是真正意义上的并行处理器，也就是用户线程和GC线程在同一时间一起工作。
2）执行过程
- 初始化标记(CMS-initial-mark) ：标记root直接关联的对象，会导致stw，但是这个没多少对象，时间短
- 并发标记(CMS-concurrent-mark)：沿着上一步的root，往下追踪，这步耗时最长，但是与用户线程同时运行
- 重新标记(CMS-remark) ：因为上一步是并发进行的，所以再增量过一遍有变化的，会导致stw，但比上一步少很多
- 并发清除(CMS-concurrent-sweep)：标记完的干掉，因为是标记-清除算法，不需要移动存活对象，所以这一步与用户线程同时运行
- 重置线程：重置状态等待下次CMS的触发(CMS-concurrent-reset)，与用户线程同时运行
3）测试
#设置启动参数
-XX:+UseConcMarkSweepGC -XX:+PrintGCDetails -Xms16m -Xmx16m
#运行日志
#注意，cms默认搭配的新生代是 parnew ：
[GC (Allocation Failure) [ParNew: 4926K->512K(4928K), 0.0041843 secs] 9424K->6736K(15872K), 0.0042168 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
#老年代开始：
#第一步，初始标记
[GC (CMS Initial Mark) [1 CMS-initial-mark: 6224K(10944K)] 6824K(15872K), 0.0004209 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
#第二步，并发标记
[CMS-concurrent-mark-start]
[CMS-concurrent-mark: 0.002/0.002 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
#第三步，预处理
[CMS-concurrent-preclean-start]
[CMS-concurrent-preclean: 0.000/0.000 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
#第四步，重新标记
[GC (CMS Final Remark) [YG occupancy: 1657 K (4928 K)][Rescan (parallel) , 0.0005811 secs][weak refs processing, 0.0000136 secs][class unloading, 0.0003671 secs][scrub symbol table, 0.0006813 secs][scrub string table, 0.0001216 secs][1 CMS-remark: 6224K(10944K)] 7881K(15872K), 0.0018324 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
#第五步，并发清理
[CMS-concurrent-sweep-start]
[CMS-concurrent-sweep: 0.004/0.004 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
#第六步，重置
[CMS-concurrent-reset-start]
[CMS-concurrent-reset: 0.000/0.000 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
由以上日志信息，可以看出CMS执行的过程。
4）优缺点
优点：
- 不可否认，一款优秀的收集器，并发收集，低停顿。
- 互联网服务器上低停顿的现实要求很吻合，一个网站总不能告诉用户你用10分钟，歇会再来用。
但是，CMS也不是完美的：
- 它不能等到内存吃紧了才启动收集。因为收集期间用户线程还在跑，得预留。
- 浮动垃圾干不掉，在并发标记、并发清理时，产生的新垃圾必须到下一次收集时处理。
- 标记-清除算法，免不了产生碎片，可以开启压缩但这些参数在jdk9里也已废弃掉
- 最后，搭配CMS的年轻代现在只剩下了ParNew，是那么的苍白无力。实际上，jdk9开始已经把它逐步淘汰
那么替代它的是谁呢？G1出场……
# 6.5.4 并发 - G1
1）概述
为解决CMS算法产生空间碎片和其它一系列的问题缺陷，G1（Garbage First）算法，在JDK 7u4版本被正式推出
oracle官方计划在jdk9中将G1变成默认的垃圾收集器，以替代CMS。
JDK9默认G1为垃圾收集器的提案：https://openjdk.java.net/jeps/248
将CMS标记为丢弃的提案：https://openjdk.java.net/jeps/291
G1的设计原则就是简化JVM性能调优，开发人员只需要简单的三步即可完成调优：
- 第一步，开启G1垃圾收集器
- 第二步，设置堆的最大内存
- 第三步，设置最大的停顿时间
2）原理
G1打破了之前的传统观念，它依然把内存划分为eden、survivor、old，同时多了一个humongous（巨大的）区来存巨型对象。
但是，这些区在物理地址上不再连续。而是把整个物理地址分成一个个大小相等的region，每一个region可以是上面角色中的一个，还可以在某个时刻转变角色，从eden变成old ！（就是个标签）
这样收集的时候，它收集某些性价比高的region回收就可以了。所以某个时刻，G1可能连老带少一起收拾。
这是一个划时代的改变！
那它是怎么做的呢？收拾哪些区块呢？
先看两个概念，容易搞混：
Remembered Set：记忆集，简称RS，每个 Region关联一个。RS 比较复杂，简单来说就是记录Region之间对象的引用关系。
Collection Set：简称CSet，在一次收集中，那些性价比高的Region揪出来组成一个回收集，将来一口气回收掉。这个集合里是筛选出来的一些Region
至于Region里面剩下的存活的对象，多个Region压缩到一个空闲Region里去，这样就完成了一次收集。
3）模式
G1中提供了三种模式垃圾回收模式，Young GC、Mixed GC 和 Full GC，在不同的条件下被触发。
所谓的模式，其实也就是G1收集的时候，Region选哪种，是只选年轻代的Region？还是两种都筛选？
Young GC
选定所有年轻代里的Region。通过控制年轻代的region个数，即年轻代内存大小，来控制young GC的时间开销。
参数 含义 -XX:MaxGCPauseMillis 设置G1收集过程目标时间，默认值200ms -XX:G1NewSizePercent 新生代最小值，默认值5% -XX:G1MaxNewSizePercent 新生代最大值，默认值60% Mixed GC
选定所有年轻代里的Region，外加统计的在用户指定的开销目标范围内选择收益高的老年代Region。
参数 含义 -XX:InitiatingHeapOccupancyPercent 当老年代大小占整个堆大小百分比达到该阈值时，会触发一次mixed gc. full GC
严格意义上讲，这不属于G1的模式。但是使用G1时是有可能发生的。
当mixed GC实在无法跟上程序分配内存的速度，导致老年代填满无法继续进行Mixed GC，就会改为使用serial old GC（full GC）来收集整个堆。
4） 运行过程
初始标记：标记出 GC Roots 直接关联的对象，这个阶段速度较快，STW，单线程执行。
并发标记：从 GC Root 开始对堆中的对象进行可达新分析，找出存活对象，这个阶段耗时较长，但可以和用户线程并发执行。
重新标记：修正在并发标记阶段因用户程序执行而产生变动的标记记录。STW，并发执行。
筛选回收：筛选回收阶段会对各个 Region 的回收价值和成本进行排序，根据用户所期望的 GC 停顿时间来制定回收计划，筛出CSet后移动合并存活对象到空Region，清除旧的，完工。因为这个阶段需要移动对象内存地址，所以必须STW。
思考一下，这属于什么算法呢？？？
答：从Region的动作来看G1使用的是标记-复制算法。而在全局视角上，类似标记 - 整理
总结：
G1前面的几步和CMS差不多，只有在最后一步，CMS是标记清除，G1需要合并Region属于标记整理
5）优缺点
- 并发性：继承了CMS的优点，可以与用户线程并发执行。当然只是在并发标记阶段。其他还是需要STW
- 分代GC：G1依然是一个分代回收器，但是和之前的各类回收器不同，它同时兼顾年轻代和老年代。而其他回收器，或者工作在年轻代，或者工作在老年代；
- 空间整理：G1在回收过程中，会进行适当的对象移动，不像CMS只是简单地标记清理对象。在若干次GC后，CMS必须进行一次碎片整理。而G1不同，它每次回收都会有效地复制对象，减少空间碎片，进而提升内部循环速度。
- 可预见性：为了缩短停顿时间，G1建立可预存停顿的模型，这样在用户设置的停顿时间范围内，G1会选择适当的区域进行收集，确保停顿时间不超过用户指定时间。
6）建议
- 如果应用程序追求低停顿，可以尝试选择G1；
- 经验值上，小内存6G以内，CMS优于G1，超过8G，尽量选择G1
- 是否代替CMS只有需要实际场景测试才知道。（如果使用G1后发现性能还不如CMS，那么还是选择CMS）
7）附：配置参数清单
=======G1 让垃圾回收配置简单很多，只需要打开并指定你预计的时间要求即可=======
指定使用G1收集器：
"-XX:+UseG1GC"
为G1设置暂停时间目标，默认值为200毫秒；这个值不是越小越好。
太小的话会造成可供收集的Region数量偏少，跟不上对象产生的速度，反而会频繁触发GC降低吞吐量
G1会根据这个目标决定收集行为：
"-XX:MaxGCPauseMillis"
=======附：其他参数，一般采用默认即可=======
设置每个Region大小，范围1MB到32MB；目标是在最小Java堆时可以拥有约2048个Region:
"-XX:G1HeapRegionSize"
新生代最小值，默认值5%:
"-XX:G1NewSizePercent"
新生代最大值，默认值60%:
"-XX:G1MaxNewSizePercent"
设置STW期间，并行GC线程数:
"-XX:ParallelGCThreads"
设置并发标记阶段，并行执行的线程数:
"-XX:ConcGCThreads"
当整个Java堆的占用率达到参数值时，开始触发mix gc；默认为45：
"-XX:InitiatingHeapOccupancyPercent"
8）操作案例
-XX:+UseG1GC -XX:MaxGCPauseMillis=100 -XX:+PrintGCDetails -Xmx256m
#G1的日志不像CMS是严格按照事件顺序来的。
#属于分类统计，包含子操作
#总停顿时间
[GC pause (G1 Evacuation Pause) (young), 0.0044882 secs]
#并发处理耗时，线程数
[Parallel Time: 3.7 ms, GC Workers: 3]
#各个子项耗时情况……
[GC Worker Start (ms): Min: 14763.7, Avg: 14763.8, Max: 14763.8, Diff: 0.1]
[Ext Root Scanning (ms): Min: 0.2, Avg: 0.3, Max: 0.3, Diff: 0.1, Sum: 0.8]
[Update RS (ms): Min: 1.8, Avg: 1.9, Max: 1.9, Diff: 0.2, Sum: 5.6]
[Processed Buffers: Min: 1, Avg: 1.7, Max: 3, Diff: 2, Sum: 5]
[Scan RS (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0]
[Code Root Scanning (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0]
[Object Copy (ms): Min: 1.1, Avg: 1.2, Max: 1.3, Diff: 0.2, Sum: 3.6]
[Termination (ms): Min: 0.0, Avg: 0.1, Max: 0.2, Diff: 0.2, Sum: 0.2]
[Termination Attempts: Min: 1, Avg: 1.0, Max: 1, Diff: 0, Sum: 3]
[GC Worker Other (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0]
[GC Worker Total (ms): Min: 3.4, Avg: 3.4, Max: 3.5, Diff: 0.1, Sum: 10.3]
[GC Worker End (ms): Min: 14767.2, Avg: 14767.2, Max: 14767.3, Diff: 0.1]
[Code Root Fixup: 0.0 ms]
[Code Root Purge: 0.0 ms]
[Clear CT: 0.0 ms]
[Other: 0.7 ms]
[Choose CSet: 0.0 ms]
[Ref Proc: 0.5 ms]
[Ref Enq: 0.0 ms]
[Redirty Cards: 0.0 ms]
[Humongous Register: 0.0 ms]
[Humongous Reclaim: 0.0 ms]
[Free CSet: 0.0 ms]
#重点：总的各个区的收集情况 收集前使用空间（总空间） -> 收集后使用空间（总空间）
[Eden: 7168.0K(7168.0K)->0.0B(13.0M) Survivors: 2048.0K->2048.0K Heap: 55.5M(192.0M)->48.5M(192.0M)]
[Times: user=0.00 sys=0.00, real=0.00 secs]
# 6.5.5 并发 - ZGC（了解）
1）概述
ZGC是一款在JDK 11中新加入的低延迟垃圾收集器，是由Oracle公司研发的。（注意！还在试验阶段）
ZGC的目标是希望在尽可能对吞吐量影响不太大的前提下，实现在任意堆内存大小下都可以把垃圾收集的停顿时间限制在10毫秒以内的低延迟。
还在试验阶段，了解原理即可，投产的话还需等待观察。
2）设计
ZGC的内存布局与G1一样，也采用基于Region的堆内存布局，但不同的是，ZGC的Page（ZGC中称之为页面，道理和Region一样）具有动态性——动态创建和销毁，以及动态的区域容量大小。在x64硬件平台下，ZGC的Page可以具有大、中、小三类容量：
- 小型页面（Small Page）：容量固定为2MB，用于放置小于256KB的小对象。
- 中型页面（Medium Page）：容量固定为32MB，用于放置大于等于256KB但小于4MB的对象。
- 大型页面（Large Page）：容量不固定，可以动态变化，但必须为2MB的整数倍，用于放置4MB或以上的大对象。
- 每个大页面中只会存放一个大对象，这也预示着虽然名字叫作“大型Page”，但它的实际容量完全有可能小于中型Page，最小容量可低至4MB。
- 大型Page在ZGC的实现中是不会被重分配（重分配是ZGC的一种处理动作）的，因为复制一个大对象的代价非常高昂。
3）染色指针
ZGC打上了内存指针的主意。我们来看看它在指针上做了什么
- 在64位系统中，理论可以访问的内存高达16EB（2的64次幂）字节。
- 实际上用不了这么多，操作系统也不让你用全部的。
- 64位的Linux可用46位（64TB）的物理地址空间，64位的Windows系统只支持44位（16TB）的物理地址空间。
我们以linux为例，即便是这64TB内存，现实中依然用不了这么多。ZGC就盯上了这块。
它把系统允许它使用的46位，拿出来4位，来记录这个内存地址的一些额外信息，剩下的42位用于真正的寻址操作。
这也造成了一个问题，就是ZGC可以管理的内存空间不可以超过4TB（2的42次幂），但是！这依然是够用的
那么我们来看一下，它拿走4位，都做了什么？
- 简单来说，所谓染色就是用这4位来标记当前对象有没有被移动过。
- 如果对象从一个Page移动到了另一个，如果没有染色标记，比如G1做垃圾收集时，那就必须停掉用户进程，修改所有指向自己的引用。
- 而有了染色标记，只需要在指向自己的引用上标注一下，移动就可以了。同时，将新旧地址记录到一张表中，叫转发表
- 那么再有用户程序访问到这个引用时，发现已改动，到转发表查新的地址，去新地址访问即可。
这么操作有什么意义呢？
- 他把对象迁移，和与他关联的地址修改做了解耦。
- 这就省去了大量同步修改地址值的操作（这个操作需要STW）。
- 一个Page里如果对象都被迁移过，那么无需挨个修改所有的指针值就可以回收掉这个Page。
关于ZGC的详细内容非常多，足够讲完一本书，想深入了解的同学参考以下拓展资料：
- 资料文件夹： ZGC-染色指针.pdf （Oracle官网）
- 一本参考书：《新一代垃圾回收器ZGC设计与实现》
4）工作过程
ZGC的运作过程大致可划分为四个大的阶段，这四个阶段都是可以并发执行的。仅在Mark Start、Initial Mark 阶段中会存在短暂的STW。
- 并发标记（Concurrent Mark）
- 与G1一样，并发标记是遍历对象图做可达性分析的阶段，前后也要经过初始标记、最终标记的短暂停顿。
- ZGC的标记是在指针上而不是在对象上进行的，标记阶段会更新染色指针中的Marked 0、Marked 1标志位。
- 并发预备重分配（Concurrent Prepare for Relocate）
- 这个阶段需要根据特定的查询条件统计得出本次收集过程要清理哪些Region，将这些Region组成：重分配集（Relocation Set）。
- ZGC每次回收都会扫描所有的Region，用范围更大的扫描成本换取省去G1中记忆集的维护成本。
- ZGC的重分配集只是决定了里面的存活对象会被重新复制到其他的Region中，里面的Region会被释放。
- 并发重分配（Concurrent Relocate）
- 重分配是ZGC执行过程中的核心阶段，这个过程要把重分配集中的存活对象复制到新的Region上，并为重分配集中的每个Region维护一个转发表（Forward Table），记录从旧对象到新对象的转向关系。
- 由于使用了染色指针的支持，ZGC收集器能仅从引用上就明确得知一个对象是否处于重分配集之中，如果用户线程此时并发访问了位于重分配集中的对象，这次访问将会被预置的内存屏障所截获，然后立即根据Region上的转发表记录将访问转发到新复制的对象上，并同时修正更新该引用的值，使其直接指向新对象，ZGC将这种行为称为指针的“自愈”（Self-Healing）能力。
- 并发重映射（Concurrent Remap）
- 重映射所做的就是修正整个堆中指向重分配集中旧对象的所有引用。
- 并发重映射并不是一个必须要“迫切”去完成的任务，但是当所有指针都被修正之后，原来记录新旧对象关系的转发表就可以释放掉了。
5）调试
注意：ZGC低版本jdk是无法开启和使用的：
linux64 ： jdk11 +
windows & mac ：jdk 14+
配置启动参数
-XX:+UnlockExperimentalVMOptions -XX:+UseZGC -Xmx256m -Xlog:gc*=info
#执行日志
[1.141s][info][gc,start ] GC(2) Garbage Collection (Warmup)
[1.141s][info][gc,phases ] GC(2) Pause Mark Start 0.190ms
[1.143s][info][gc,phases ] GC(2) Concurrent Mark 1.837ms #并发标记
[1.143s][info][gc,phases ] GC(2) Pause Mark End 0.136ms
[1.144s][info][gc,phases ] GC(2) Concurrent Process Non-Strong References 0.308ms
[1.144s][info][gc,phases ] GC(2) Concurrent Reset Relocation Set 0.001ms
[1.144s][info][gc,phases ] GC(2) Concurrent Destroy Detached Pages 0.000ms
[1.145s][info][gc,phases ] GC(2) Concurrent Select Relocation Set 1.219ms #重分配集
[1.145s][info][gc,phases ] GC(2) Concurrent Prepare Relocation Set 0.009ms #预备重分配
[1.145s][info][gc,phases ] GC(2) Pause Relocate Start 0.230ms
[1.146s][info][gc,phases ] GC(2) Concurrent Relocate 0.853ms #并发重分配
[1.146s][info][gc,load ] GC(2) Load: 0.00/0.02/0.05
[1.146s][info][gc,mmu ] GC(2) MMU: 2ms/78.1%, 5ms/88.9%, 10ms/93.4%, 20ms/96.7%, 50ms/98.7%, 100ms/99.0%
[1.146s][info][gc,marking ] GC(2) Mark: 1 stripe(s), 1 proactive flush(es), 1 terminate flush(es), 0 completion(s), 0 continuation(s)
[1.146s][info][gc,reloc ] GC(2) Relocation: Successful, 1M relocated #重分配完成
[1.146s][info][gc,nmethod ] GC(2) NMethods: 59 registered, 0 unregistered
#释放情况，元空间、各种引用、堆……
[1.146s][info][gc,metaspace] GC(2) Metaspace: 4M used, 4M capacity, 5M committed, 8M reserved
[1.146s][info][gc,ref ] GC(2) Soft: 131 encountered, 0 discovered, 0 enqueued
[1.146s][info][gc,ref ] GC(2) Weak: 222 encountered, 215 discovered, 0 enqueued
[1.146s][info][gc,ref ] GC(2) Final: 0 encountered, 0 discovered, 0 enqueued
[1.146s][info][gc,ref ] GC(2) Phantom: 1 encountered, 1 discovered, 0 enqueued
[1.146s][info][gc,heap ] GC(2) Mark Start Mark End Relocate Start Relocate End High Low
[1.146s][info][gc,heap ] GC(2) Capacity: 114M (45%) 114M (45%) 114M (45%) 114M (45%) 114M (45%) 114M (45%)
[1.146s][info][gc,heap ] GC(2) Reserve: 36M (14%) 36M (14%) 36M (14%) 36M (14%) 36M (14%) 36M (14%)
[1.146s][info][gc,heap ] GC(2) Free: 142M (55%) 142M (55%) 184M (72%) 184M (72%) 184M (72%) 142M (55%)
[1.146s][info][gc,heap ] GC(2) Used: 78M (30%) 78M (30%) 36M (14%) 36M (14%) 78M (30%) 36M (14%)
[1.146s][info][gc,heap ] GC(2) Live: - 1M (1%) 1M (1%) 1M (1%) - -
[1.146s][info][gc,heap ] GC(2) Allocated: - 0M (0%) 0M (0%) 4M (2%) - -
[1.146s][info][gc,heap ] GC(2) Garbage: - 76M (30%) 34M (14%) 34M (14%) - -
[1.146s][info][gc,heap ] GC(2) Reclaimed: - - 42M (16%) 42M (16%) - -
[1.146s][info][gc ] GC(2) Garbage Collection (Warmup) 78M(30%)->36M(14%)
# 6.5.6 归纳总结
1）我们先把所学的收集器做个汇总：
| 名称 | 算法 | 工作区域 | 线程 | 模式 | 适用场合 | 优缺点 |
|---|---|---|---|---|---|---|
| Serial | 复制 | 新生 | 单 | 串行 | 单CPU；Client模式下 | 缺：stop the world；优：简单高效,没有线程交互开销,专注于GC; |
| ParNew | 复制 | 新生 | 多 | 并行 | 多CPU；Server模式下 | 缺：stop the world；优：并行并发GC |
| Parallel Scavenge | 复制 | 新生 | 多 | 并行 | 吞吐量控制，Client，server均可以 | 主要关注吞吐量,通过吞吐量的设置控制停顿时间,适应不同的场景 |
| Serial Old | 整理 | 老年 | 单 | 串行 | 主要Client模式下 | 缺：stop the world；其他收集器搞不定时的保底选择 |
| Parallel Old | 整理 | 老年 | 多 | 并行 | 吞吐量控制，Client，server均可以 | 主要关注吞吐量，通过吞吐量的设置控制停顿时间，适应不同的场景 |
| CMS | 清除 | 老年 | 多 | 并发 | 互联网站；B/S系统服务端 | 缺：CPU资源敏感,无法处理浮动垃圾，产生大量内存碎片；优：并发收集,低停顿 |
| G1 | 整理 | 均可 | 多 | 并发 | 面向服务端应用 | 优：并行与并发,分代收集,空间整合(标记整理算法),可预测停顿 |
2）一些规律
- 新生代都是标记 - 复制算法，老年代采用标记 - 整理，或清除（CMS）
- 历史性的收集器大多针对某个代，但是G1，以及未来的ZGC都是全代可用
- 没有绝对好用的收集器，需要在 吞吐量、延迟性、内存占用量上做权衡
- 数据分析、科学计算等场合，偏重吞吐量
- 互联网服务器、web网站，偏重服务的延迟度，不能出现严重顿挫
- 客户端、微型终端、嵌入式应用，内存占用低是关键
3）搭配组合
除了G1和ZGC这些全能选手，其他垃圾收集器需要搭配工作
但是组合不是想怎么来就怎么来的，下图展示可用组合，以及在某些版本中废弃掉的组合：
4）如何查看当前jdk的垃圾回收器呢？
java -XX:+PrintCommandLineFlags -version
#jdk8，默认Parallel
shawn@macpro:~ > java -XX:+PrintCommandLineFlags -version
-XX:InitialHeapSize=134217728 -XX:MaxHeapSize=2147483648 -XX:+PrintCommandLineFlags -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseParallelGC
java version "1.8.0_181"
Java(TM) SE Runtime Environment (build 1.8.0_181-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.181-b13, mixed mode)
#jdk11，默认换成了G1
shawn@macpro:~ > java -XX:+PrintCommandLineFlags -version
-XX:G1ConcRefinementThreads=4 -XX:GCDrainStackTargetSize=64 -XX:InitialHeapSize=134217728 -XX:MaxHeapSize=2147483648 -XX:+PrintCommandLineFlags -XX:ReservedCodeCacheSize=251658240 -XX:+SegmentedCodeCache -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseG1GC
java version "11.0.2" 2019-01-15 LTS
Java(TM) SE Runtime Environment 18.9 (build 11.0.2+9-LTS)
Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.2+9-LTS, mixed mode)
#jdk14，默认还是G1，但是已经支持ZGC了，需要打开实验性参数开关
shawn@macpro:~ > java -XX:+PrintCommandLineFlags -version
-XX:G1ConcRefinementThreads=4 -XX:GCDrainStackTargetSize=64 -XX:InitialHeapSize=134217728 -XX:MaxHeapSize=2147483648 -XX:MinHeapSize=6815736 -XX:+PrintCommandLineFlags -XX:ReservedCodeCacheSize=251658240 -XX:+SegmentedCodeCache -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseG1GC
java version "14.0.2" 2020-07-14
Java(TM) SE Runtime Environment (build 14.0.2+12-46)
Java HotSpot(TM) 64-Bit Server VM (build 14.0.2+12-46, mixed mode, sharing)