【JVM】垃圾收集概述
JVM如何定位垃圾
什么样的对象是垃圾？
如何定位到垃圾对象？
引用计数法
可达性分析法
• 虚拟机栈中引用的对象，即栈帧中的本地变量表；
• 方法去中类静态属性引用的对象；
• 方法去中常量引用的对象；
• 本地方法栈JNI引用的对象；
• 强引用：是代码中普遍存在的引用，垃圾收集器不会主动回收掉被引用的对象；
• 软引用：主要用来描述一下还有用但不是必须的对象，JVM在内存不足时会回收这部分对象，一般用于缓存 ；
• 弱引用：弱引用比软引用更弱，弱引用对象会随着下一次垃圾收集被回收掉，一般用于临时缓存；
• 虚引用：也称为幽灵引用或幻影引用，是一种最弱的引用，为一个对象设置虚引用的目的就是能在这个对象被回收时收到一个系统通知。
举例说明Java中用到的垃圾定位方法
Tip：这里参照了《深入Java虚拟机》中的案例
public class CountingReferenceGC {
private byte[] data = new byte[2 * 1024 * 1024];
public static void main(String[] args) {
CountingReferenceGC objA = new CountingReferenceGC();
CountingReferenceGC objB = new CountingReferenceGC();
objA = objB;
objB = objA;
objA = null;
objB = null;
// 手动触发垃圾收集
System.gc();
}
}
gc日志如下
[Full GC (System.gc()) [PSYoungGen: 496K->0K(2560K)] [ParOldGen: 4164K->380K(7168K)] 4660K->380K(9728K), [Metaspace: 3045K->3045K(1056768K)], 0.0034581 secs] [Times: user=0.01 sys=0.01, real=0.01 secs]
Heap
PSYoungGen total 2560K, used 44K [0x00000007bfd00000, 0x00000007c0000000, 0x00000007c0000000)
eden space 2048K, 2% used [0x00000007bfd00000,0x00000007bfd0b150,0x00000007bff00000)
from space 512K, 0% used [0x00000007bff00000,0x00000007bff00000,0x00000007bff80000)
to space 512K, 0% used [0x00000007bff80000,0x00000007bff80000,0x00000007c0000000)
ParOldGen total 7168K, used 380K [0x00000007bf600000, 0x00000007bfd00000, 0x00000007bfd00000)
object space 7168K, 5% used [0x00000007bf600000,0x00000007bf65f088,0x00000007bfd00000)
Metaspace used 3057K, capacity 4496K, committed 4864K, reserved 1056768K
class space used 335K, capacity 388K, committed 512K, reserved 1048576K根据日志可以看出对象被正常回收，说明JVM采用的并不是引用计数法。
几种垃圾收集算法
标记清除算法
(图片来自《深入Java虚拟机》)
复制算法
(图片来自《深入Java虚拟机》)
标记整理算法
(图片来自《深入Java虚拟机》)
分代垃圾收集理论
安全点和安全区域
正式介绍垃圾收集之前，还需要介绍两个核心概念，即安全点和安全区域。我们都知道我们的Java程序一直在持续不断的运行，那如果想要做垃圾收集怎么办呢？那就是让我们的程序暂时停下来（这就是著名的Stop The World），然后垃圾收集程序开始进行垃圾收集。那另一问题就是如何让程序停下来呢？这就是安全点和安全区域的作用了。
安全点（Safe Point）
• 方法返回之前；
• 调用某个方法之后；
• 抛出异常的位置；
• 循环的末尾；
安全区域（Safe Region）
垃圾收集器介绍
说明：由于篇幅原因，本文不会很详细介绍垃圾收集器细节，后面会以单独篇幅的方式介绍。
垃圾收集算法是垃圾收集方法论，而垃圾收集器是JVM中实实在在存在的实现。垃圾收集器是是一个需要长期持续发展的过程，没有一个完美的，适合任何场景的垃圾收集器，以后也不太可能出现这样的垃圾收集器。都是需要根据自己的业务场景和实际情况选择合适的，合适的才是最好的。垃圾收集器示意图如下：
上图中的连线说明垃圾收集器在分代收集的情况下搭配使用的，配置其中一个会选择另一个作为默认搭配。
Serial收集器
(图片来自《深入Java虚拟机》)
使用方法：在JVM启动参数中设置-XX:+UseSerialGC或-XX:+UseSerialOldGC，前面说过配置一个就会自动搭配另一个，后面GC日志分析相关的文章会重点介绍。
ParNew收集器
(图片来自《深入Java虚拟机》)
Parallel Scavenge收集器
• XX:ParallelGCThreads ：此参数作用调节垃圾收集收集线程数，默认是与CPU核心数相同
• -XX:+UseAdaptiveSizePolicy：这是一个开关参数，这个参数打开的话，用户无需设置新生代大小（-Xmn）、From和to区比率、晋升老年代年龄等参数。它会自动根据运行情况动态调节，但是所有的调节都是为了提升吞吐量和CPU利用率。
CMS收集器
• 初始标记（CMS initial mark）：会产生STW，但是时间较短，主要标记GCRoots直接引用的对象。
• 并发标记（CMS concurrent mark）：耗时较久，但是会与用户线程同时运行，主要根据GCRoots枚举所有对象引用关系的过程。
• 重新标记（CMS remark）：上面的并发标记阶段很明显很可能会出现错标或漏标，因为用户线程和垃圾收集线程同时工作，有可能已经被标记的对象引用会发生变化。因此需要进行二次重新标记，检查一遍并发阶段正在运行的用户线程相关的引用，以做修正。这个阶段也需要STW，由于大多数标记在并发标记阶段已经完成，因此这个阶段也会很快，与初始标记阶段耗时差不多。
• 并发清除（CMS concurrent sweep）：到了此阶段，是完成上述标记完成后确定为垃圾对象的回收工作。
• 并发重置：主要是重置本次的标记数据。
CMS垃圾收集器工作示意图如下：
(图片来自《深入Java虚拟机》)
• 无法解决浮动垃圾的问题：指在并发标记和并发清理产生的新的垃圾，这类垃圾在本次垃圾收集过程中无法被收集，只能等待下一次GC；
• 对CPU资源要求高：由于使用了并发标记，并发清理，因此会竞争CPU资源；
• 会出现不确定性问题：因为CMS为并发收集，因此在并发标记、和并发清理阶段，可能在上一次GC进行过程中触发第二次垃圾收集（FullGC），这种不确定性问题就是并发模式失败（concurrent mode failure），此时会进行STW，老年代退化为使用Serial Old垃圾收集器；
• 内存碎片问题：由于使用了标记清除算法，根据前文中介绍的标记清除算法内容，则会产生大量内存碎片，这可能会导致很多由于大对象分配而不得不出发的FullGC，因此CMS提供了-XX:+UseCMSCompactAtFullCollection和-XX:CMSFullGCsBeforeCompaction两个参数由于解决这种情况，相关重点参数后面会接着介绍；
CMS重点参数如下：
• -XX:+UseConcMarkSweepGC：启用CMS垃圾收集器；
• -XX:ConcGCThreads：并发的GC线程数；
• -XX:+UseCMSCompactAtFullCollection：FullGC之后做压缩整理（减少碎片）；
• -XX:CMSFullGCsBeforeCompaction：多少次FullGC之后压缩一次，默认是0，代表每次FullGC后都会压缩一次；
• -XX:CMSInitiatingOccupancyFraction: 当老年代使用达到该比例时会触发FullGC（默认是92，这是百分比）；
• -XX:+UseCMSInitiatingOccupancyOnly：只使用设定的回收阈值(-XX:CMSInitiatingOccupancyFraction设定的值)，如果不指定，JVM仅在第一次使用设定值，后续则会自动调整；
• -XX:+CMSScavengeBeforeRemark：在CMS GC前启动一次minor gc，降低CMS GC标记阶段**(也会对年轻代一起做标记，如果在minor gc就干掉了很多对垃圾对象，标记阶段就会减少一些标记时间)**时的开销，一般CMS的GC耗时 80%都在标记阶段；
• -XX:+CMSParallellnitialMarkEnabled：表示在初始标记的时候多线程执行，缩短STW；
• -XX:+CMSParallelRemarkEnabled：在重新标记的时候多线程执行，缩短STW;
Serial Old收集器
(图片来自《深入Java虚拟机》)
Parallel Old收集器
(图片来自《深入Java虚拟机》)
G1收集器
（图片来自网络）
(图片来自《深入Java虚拟机》)
• 初始标记（initial mark，STW）：暂停所有的其他线程，并记录下gc roots直接能引用的对象，速度很快 ；
• 并发标记（Concurrent Marking）：同CMS的并发标记；
• 最终标记（Remark，STW）：同CMS的重新标记；
• 筛选回收（Cleanup，STW）：筛选回收阶段首先对各个Region的回收价值和成本进行排序，根据用户所期望的GC停顿STW时间(可以用JVM参数 -XX:MaxGCPauseMillis指定)来制定回收计划；
G1垃圾收集器被视为jdk 5中出现的CMS垃圾收集器的替代品，因此它有些关键的特点如下：
• 并行与并发：G1能充分利用CPU、多核环境下的硬件优势，使用多个CPU（CPU或者CPU核心）来缩短Stop-The-World停顿时间。部分其他收集器原本需要停顿Java线程来执行GC动作，G1收集器仍然可以通过并发的方式让java程序继续执行；
• 分代收集：虽然G1可以不需要其他收集器配合就能独立管理整个GC堆，但是还是保留了分代的概念；
• 空间整合：与CMS的“标记--清理”算法不同，G1从整体来看是基于标记整理算法实现的收集器；从局部上来看是基于“复制”算法实现的；
• 可预测的停顿：这是G1相对于CMS的另一个大优势，降低停顿时间是G1 和 CMS 共同的关注点，但G1 除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段(通过参数-XX:MaxGCPauseMillis指定)内完成垃圾收集；
下面介绍一下G1来收集的几种模式：
• YoungGC：YoungGC不会是在所有的Eden快满的时候触发GC，前文我们提到一个重要的特性就是可预测的停顿，G1会判断执行YoungGC的耗时是否比用户设置的期望耗时要多，如果要多，则不会执行YoungGC，而是增加Eden区域的Region数，直到下一次Eden区域重新快满的时候，再次判断需要耗费的时间是否满足用户的期望或接近才会真正执行YoungGC。
• MixedGC：不是FullGC，老年代的堆占有率达到参数(-XX:InitiatingHeapOccupancyPercent)设定的值则触发，回收所有的Young和部分Old(根据期望的GC停顿时间确定old区垃圾收集的优先顺序)以及大对象区，正常情况G1的垃圾收集是先做MixedGC，主要使用复制算法，需要把各个region中存活的对象拷贝到别的region里去，拷贝过程中如果发现没有足够的空region能够承载拷贝对象就会触发一次Full GC
• FullGC：停止系统程序，然后采用单线程进行标记、清理和压缩整理，好空闲出来一批Region来供下一次MixedGC使用，这个过程是非常耗时的。(Shenandoah优化成多线程收集了)
G1垃圾收集器的关键参数：
• -XX:+UseG1GC:使用G1收集器；
• -XX:ParallelGCThreads:指定GC工作的线程数量；
• -XX:G1HeapRegionSize:指定分区大小(1MB~32MB，且必须是2的N次幂)，默认将整堆划分为2048个分区；
• -XX:MaxGCPauseMillis:目标暂停时间(默认200ms)；
• -XX:G1NewSizePercent:新生代内存初始空间(默认整堆5%，值配置整数，默认就是百分比)；
• -XX:G1MaxNewSizePercent:新生代内存最大空间；
• -XX:TargetSurvivorRatio:Survivor区的填充容量(默认50%)，Survivor区域里的一批对象(年龄1+年龄2+年龄n的多个年龄对象)总和超过了Survivor区域的50%，此时就会把年龄n(含)以上的对象都放入老年代；
• -XX:MaxTenuringThreshold:最大年龄阈值(默认15)；
• -XX:InitiatingHeapOccupancyPercent:老年代占用空间达到整堆内存阈值(默认45%)，则执行新生代和老年代的混合收集(MixedGC)，比如我们之前说的堆默认有2048个region，如果有接近1000个region都是老年代的region，则可能就要触发MixedGC了；
• -XX:G1MixedGCLiveThresholdPercent(默认85%) region中的存活对象低于这个值时才会回收该region，如果超过这个值，存活对象过多，回收的的意义不大；
• -XX:G1MixedGCCountTarget:在一次回收过程中指定做几次筛选回收(默认8次)，在最后一个筛选回收阶段可以回收一会，然后暂停回收，恢复系统运行，一会再开始回收，这样可以让系统不至于单次停顿时间过长；
• -XX:G1HeapWastePercent(默认5%): gc过程中空出来的region是否充足阈值，在混合回收的时候，对Region回收都是基于复制算法进行的，都是把要回收的Region里的存活对象放入其他Region，然后这个Region中的垃圾对象全部清理掉，这样的话在回收过程就会不断空出来新的Region，一旦空闲出来的Region数量达到了堆内存的5%，此时就会立即停止混合回收，意味着本次混合回收就结束了；
总结
01
--------------底线--------------