Java虚拟机|JVM知识点汇总及简述-＞垃圾回收（一）：垃圾回收算法
文章目录
- 垃圾回收（一）
-
- 一、垃圾回收概述
-
- 1.什么是垃圾
- 2.早期的垃圾回收
- 3.Java的垃圾回收机制
- 4.垃圾回收线程
- 二、垃圾回收的相关算法
-
- 1.垃圾标记阶段∶对象存活判断
-
- 1.1 引用计数算法（Java不用）
- 1.2 可达性分析算法（根搜索算法、追踪性垃圾收集）
- 2.对象的finalization机制
-
- 2.1 概述
- 2.2 注意事项
- 2.3 虚拟机对象的三种状态
- 2.4 执行过程
- 2.4 总结
- 3.垃圾清除阶段
-
- 3.1 标记-清除算法（Mark-Sweep）
- 3.2 复制算法
- 3.3 标记-压缩（或标记-整理、Mark - Compact）算法
- 4.三种垃圾回收算法的总结
- 5.增量收集算法、分区算法
-
- 5.1 增量收集算法
- 5.2 分区算法
- 三、垃圾回收相关概念概述
-
- 1.System.gc()的理解
- 2.内存溢出与内存泄漏
-
- 2.1 内存溢出（Out Of Memory）
- 2.2 内存泄漏（Memory Leak）
- 3.Stop The World事件
- 4.并行与并发
-
- 4.1 并行（Parallel）
- 4.2 并发（Concurrent）
- 4.3 垃圾回收下的并行、串行与并发
- 5.安全点与安全区域
-
- 5.1 安全点
- 5.1 安全区域
垃圾回收（一）
一、垃圾回收概述
1.什么是垃圾
垃圾是指在运行程序中没有任何指针指向的对象，这个对象就是需要被回收的垃圾。
2.早期的垃圾回收
- 在早期的C/C++时代，垃圾回收基本上是手工进行的。开发人员可以使用new关键字进行内存申请，并使用delete关键字进行内存释放。但此时需要频繁的申请和释放内存的负担，而且如果忘记释放还有可能出现内存泄漏的问题，且垃圾一直在持续增加，会导致内存溢出程序崩溃
- 所以现在很多语言都有了自动垃圾回收机制，以及自动化的内存分配机制
3.Java的垃圾回收机制
- 自动内存管理机制
降低了内存泄漏和内存溢出问题，让开发者更加注重业务开发
4.垃圾回收线程
垃圾回收线程是守护线程，当进程中没有任何非守护线程时，守护线程自动结束
二、垃圾回收的相关算法
1.垃圾标记阶段∶对象存活判断
判断对象存活一般有两种方式：引用计数算法和可达性分析算法。
在堆里存放着几乎所有的Java对象实例，在GC执行垃圾回收之前，首先需要区分出内存中哪些是存活对象，哪些是已经死亡的对象(即不再被引用的对象)。只有被标记为己经死亡的对象，GC才会在执行垃圾回收时，释放掉其所占用的内存空间，因此这个过程我们可以称为垃圾标记阶段。
1.1 引用计数算法（Java不用）
- 概述
引用计数算法(Reference Counting)，对每个对象保存一个整型的引用计数器属性。用于记录对象被引用的情况。
- 原理机制
对于一个对象A，只要有任何一个对象引用了A，则A的引用计数器就加1;当引用失效时，引用计数器就减1。只要对象A的引用计数器的值为0，即表示对象A不可能再被使用，可进行回收。
- 优点
实现简单，垃圾对象便于辨识；判定效率高，回收没有延迟性。
- 缺点
- 它需要单独的字段存储计数器，这样的做法增加了存储空间的开销。
- 每次赋值都需要更新计数器，伴随着加法和减法操作，这增加了时间开销。
- 引用计数器有一个严重的问题，即无法处理循环引用的情况。这是一条致命缺陷，导致在Java的垃圾回收器中没有使用这类算法。
- 总结
虽然有很多缺点，但还是有语言去使用这个算法的，例如python，而python是通过两种方式来解决无法处理循环引用的问题：
- 手动解除:很好理解，就是在合适的时机，解除引用关系。
- 使用弱引用weakref，weakref是Python提供的标准库，旨在解决循环引用。
1.2 可达性分析算法（根搜索算法、追踪性垃圾收集）
- 概述
可达性分析算法不仅同样具备实现简单和执行高效等特点，更重要的是该算法可以有效地解决在引用计数算法中循环引用的问题，防止内存泄漏的发生。
- 实现原理
- 可达性分析算法是以根对象集合(GC Roots)为起始点，按照从上至下的方式搜索被根对象集合所连接的目标对象是否可达。
（所谓"GC Roots"根集合就是一组必须活跃的引用。）- 使用可达性分析算法后，内存中的存活对象都会被根对象集合直接或间接连接着，搜索所走过的路径称为引用链(Reference Chain)
- 如果目标对象没有任何引用链相连，则是不可达的，就意味着该对象己经死亡，可以标记为垃圾对象。
- 在可达性分析算法中，只有能够被根对象集合直接或者间接连接的对象才是存活对象。
- Java中那些元素可以被判断为GC Roots
- ·虚拟机栈中引用的对象。比如:各个线程被调用的方法中使用到的参数、局部变量等。
- 本地方法栈内JN工(通常说的本地方法)引用的对象
- 方法区中类静态属性引用的对象。比如: Java类的引用类型静态变量
- 方法区中常量引用的对象。比如:字符串常量池（String Table）里的引用
- 所有被同步锁synchronized持有的对象
- Java虚拟机内部的引用。基本数据类型对应的class对象，一些常驻的异常对象（如:NullPointerException、outOfMemoryError），系统类加载器。
- 当然还会有些“临时”加入的对象，例如分代收集和局部回收（Partial GC）
小技巧：由于Root采用栈方式存放变量和指针，所以如果一个指针，它保存了堆内存里面的对象，但是自己又不存放在堆内存里面，那它就是一个Root 。
- 注意事项
- 如果要使用可达性分析算法来判断内存是否可回收，那么分析工作必须在一个能保障一致性的快照中进行。这点不满足的话分析结果的准确性就无法保证。
- 这点也是导致GC进行时必须
"stop The World"的一个重要原因。即使是号称（几乎）不会发生停顿的CMS收集器中，枚举根节点时也是必须要停顿的。
- 优化根节点的遍历速度
在HotSpot 的解决方案里，通过称之为 OopMap 的数据结构来记录 GC Roots 的位置，这个机制的引入就为后面的安全点做铺垫
2.对象的finalization机制
2.1 概述
- Java语言提供了对象终止(finalization）机制来允许开发人员提供对象被销毁（GC）之前的自定义处理逻辑。
- 当垃圾回收器发现没有引用指向一个对象，即:垃圾回收此对象之前，总会先调用这个对象的finalize()方法。
- finalize()方法允许在子类中被重写，用于在对象被回收时进行资源释放。通常在这个方法中进行一些资源释放和清理的工作，比如关闭文件、套接字和数据库连接等。
@Override
protected void finalize() throws Throwable {
super.finalize();
xxx=this;//xxx就是需要被复活的对象
}
2.2 注意事项
永远不要主动调用某个对象的finalize()方法，应该交给垃圾回收机制调用。理由包括下面三点:
- 在finalize()时可能会导致对象复活。
- finalize()方法的执行时间是没有保障的，它完全由GC线程决定，极端情况下，
- 若不发生GC，则finalize()方法将没有执行机会。一个糟糕的finalize()会严重影响GC的性能。
2.3 虚拟机对象的三种状态
- 可触及的：从根节点开始，可以到达这个对象。
- 可复活的：对象的所有引用都被释放，但是对象有可能在finalize()中复活。
- 不可触及的：对象的finalize()被调用，并且没有复活，那么就会进入不可触及状态。不可触及的对象不可能被复活，因为finalize()只会被调用一次。
2.4 执行过程
- 如果对象objA到GC Roots没有引用链，则进行第一次标记。
- 进行筛选，判断此对象是否有必要执行finalize ()方法
- 如果对象objA没有重写finalize()方法，或者finalize()方法已经被虚拟机调用过，则虚拟机视为“没有必要执行”，objA被判定为不可触及的。
- 如果对象objA重写了finalize()方法，且还未执行过，那么objA会被插入到F-Queue队列中，由一个虚拟机自动创建的、低优先级的Finalizer线程触发其finalize()方法执行。
- finalize()方法是对象逃脱死亡的最后机会，稍后GC会对F-Queue队列中的对象进行第二次标记。如果objA在finalize()方法中与引用链上的任何一个对象建立了联系，那么在第二次标记时，objA会被移出“即将回收”集合。之后，对象会再次出现没有引用存在的情况。在这个情况下，finalize方法不会被再次调用，对象会直接变成不可触及的状态，也就是说，一个对象的finalize方法只会被调用一次。
2.4 总结
- 一个对象的finalize()方法只会被调用一次。
- finalize()方法是对象逃脱死亡的最后机会，
3.垃圾清除阶段
3.1 标记-清除算法（Mark-Sweep）
- 执行过程
当堆中的有效内存空间（available memory）被耗尽的时候，就会停止整个程序（也被称为stop the world)，然后进行两项工作：第一项则是标记，第二项则是清除。
- 标记:Collector从引用根节点开始遍历，标记所有被引用的对象。一般是在对象的Header中记录为可达对象。
- 清除:Collector对堆内存从头到尾进行线性的遍历，如果发现某个对象在其Header中没有标记为可达对象，则将其回收。
- 缺点
- 效率不算高工
- 在进行GC的时候，需要停止整个应用程序，导致用户体验差
- 这种方式清理出来的空闲内存是不连续的，产生内存碎片。需要维护一个空闲列表
- 注意
清除并不是真正意义上的清除，而是将数据指向的地址指针全部回收过来，实际数据还在等待下一次存储数据的时候被占用
3.2 复制算法
- 概述
为了解决标记清除算法的弊端，复制算法诞生。其主要思想是：将活着的内存空间分为两块，每次只使用其中一块，在垃圾回收时将正在使用的内存中的存活对象复制到未被使用的内存块中，之后清除正在使用的内存块中的所有对象，交换两个内存的角色，最后完成垃圾回收。新分配的对象地址都是连续的，即指针碰撞
- 优点
- 没有标记和清除过程，实现简单，运行高效
- 复制过去以后保证空间的连续性，不会出现“碎片”问题。
- 缺点
- 此算法的缺点也是很明显的，就是需要两倍的内存空间。
- 对于Gl这种分拆成为大量region的GC，复制而不是移动，意味着GC需要维护region之间对象引用关系，不管是内存占用或者时间开销也不小。
- 注意
当需要复制的对象很多的时候，这个算法并不是很理想，因为复制完半天发现垃圾对象没几个甚至没有，就很浪费资源。所以当垃圾对象很多时，用此算法很适合在新生代中去使用，因为此区域很多对象都符合“朝生夕死”的特点，拥有大量的待回收对象即垃圾对象
3.3 标记-压缩（或标记-整理、Mark - Compact）算法
- 概述
对于前两个算法都有很适合的应用场景，而老年代却没有一个合适的算法去回收垃圾对象，虽然回收频率不高但仍然需要垃圾回收，所以标记-压缩算法应运而生，其算法整理后的连续位置也是使用指针碰撞的例子
特别的在Java中的老年代使用的是标记整理（整理碎片）和标记清除（回收对象）并存的算法配合方案，即体现了分代收集算法的特性
- 执行过程
第一阶段：和标记清除算法一样，从根节点开始标记所有被引用对象；
第二阶段：将所有的存活对象压缩到内存的一端，按顺序排放。之后，清理边界外所有的空间。
- 优点
- 消除了标记-清除算法当中，内存区域分散的缺点，我们需要给新对象分配内存时，JVM只需要持有一个内存的起始地址即可。
- 消除了复制算法当中，内存减半的高额代价。
- 缺点
- 从效率上来说，标记-整理算法要低于复制算法。
- 移动对象的同时，如果对象被其他对象引用，则还需要调整引用的地址。
- 移动过程中，需要全程暂停用户应用程序。即:STW
4.三种垃圾回收算法的总结
效率上来说，复制算法是当之无愧的老大，但是却浪费了太多内存。而为了尽量兼顾上面提到的三个指标，标记-整理算法相对来说更平滑一些，但是效率上不尽如人意，它比复制算法多了一个标记的阶段，比标记-清除多了一个整理内存的阶段。
对于不同场景下的不同算法使用，有一个集合的思想：分代收集算法
5.增量收集算法、分区算法
5.1 增量收集算法
- 概述
为了解决STW（Stop The World）占用用户线程的时间过长，此算法采用用户线程和STW线程相互并发的执行，缩短用户感知时间
- 缺点
因为线程切换和上下文转换的消耗，会使得垃圾回收的总体成本上升，造成系统吞吐量的下降。
5.2 分区算法
- 概述
一般来说，在相同条件下，堆空间越大，一次GC时所需要的时间就越长，有关GC产生的停顿也越长。为了更好地控制GC产生的停顿时间，将一块大的内存区域分割成多个小块，根据目标的停顿时间，每次合理地回收若干个小区间，而不是整个堆空间，从而减少一次GC所产生的停顿。
也是为了降低用户线程暂停的时间
三、垃圾回收相关概念概述
1.System.gc()的理解
- 概述
在默认情况下，通过System.ge()或者Runtime.getRuntime ().gc()的调用，会显式触发Full GC，同时对老年代和新生代进行回收，尝试释放被丢弃对象占用的内存。
- 注意
- 在调用System.ge()后不一定能立马触发GC
- 垃圾回收一般都是自己自动触发，不需要手动触发，但有一些特殊情况需要我们手动的去GC，System.ge()就能应对这种情况
- System.ge()的底层调用就是Runtime.getRuntime ().gc()
- System.runFinalization( )强制调用使用引用的对象的finalize()方法
- 相关代码演示
- 对于test01来说GC是没有把10M的字节数组回收掉的（但我自己在idea中实验是进行回收了的，不是很懂，可能在后续优化中垃圾回收器直接就会将作用域出界后的局部变量直接回收也不等下一个局部变量来进行Slot复用了）
- 对于test02来说GC是回收了10M的数组，因为此时又有新的局部变量声明，而代码块中的数组的作用域已经过期，直接进行Slot复用，数组被回收
public class SystemGCByHand {
public static void main(String[] args) {
SystemGCByHand systemGCByHand = new SystemGCByHand();
systemGCByHand.test01();
//systemGCByHand.test02();
}
public void test01(){
{
byte[] b1 = new byte[10*1024*1024];
}
System.gc();
}
public void test02(){
{
byte[] b1 = new byte[10*1024*1024];
}
int value = 10;
System.gc();
}
}
2.内存溢出与内存泄漏
2.1 内存溢出（Out Of Memory）
- 概述
javadoc中对OutOfMemoryError的解释是，没有空闲内存，并且垃圾收集器也无法提供更多内存。
- 在没有空闲内存的前提下，报OutOfMemoryError的原因
- Java虚拟机的维内存设置不够。
- 代码中创建了大量大对象，并且长时间不能被垃圾收集器收集（存在被引用)，但在JDK8以后永久代变为本地内存后OOM的情况就变少很多
- 注意
再报oom之前肯定会执行一次GC。唯一的例外就是直接就放了一个超大对象占用内存比堆本身都大，这种情况直接报错
2.2 内存泄漏（Memory Leak）
- 概述
也称作“存储渗漏”。严格来说，只有对象不会再被程序用到了，但是GC又不能回收他们的情况（还有指针连着），才叫内存泄漏。
但实际情况很多时候一些不太好的实践（或疏忽）会导致对象的生命周期变得很长甚至导致OOM，也可以叫做宽泛意义上的“内存泄漏”。例如创建大量的静态变量或web应用将对象的会话级别提高使之对象周期过长等等
- 举例
- 单例模式
单例的生命周期和应用程序是一样长的，所以单例程序中，如果持有对外部对象的引用的话，那么这个外部对象是不能被回收的，则会导致内存泄漏的产生。- 一些提供close的资源未关闭导致内存泄漏
数据库连接（dataSourse.getConnection()），网络连接(socket)和io连接必须手动close，否则是不能被回收的。
3.Stop The World事件
- 概述
Stop-The-World ，简称STW，指的是GC事件发生过程中，会产生应用程序的停顿。停顿产生时整个应用程序线程都会被暂停，没有任何响应，有点像卡死的感觉，这个停顿称为STW。
- 场景示例
可达性分析算法中枚举根节点(GC Roots）会导致所有Java执行线程停顿。对于根节点下的引用链已经能够做到与用户线程并行的去处理
- 分析工作必须在一个能确保一致性的快照中进行
- 一致性指整个分析期间整个执行系统看起来像被冻结在某个时间点上
- 如果出现分析过程中对象引用关系还在不断变化，则分析结果的准确性无法保证
- 注意
- STW事件和采用哪款GC无关，所有的GC都有这个事件。
- 哪怕是G1（Java的垃圾回收器）也不能完全避免stop-the-world 情况发生，只能说垃圾回收器越来越优秀，回收效率越来越高，尽可能地缩短了暂停时间。
- STW是JVM在后台自动发起和自动完成的。在用户不可见的情况下，把用户正常的工作线程全部停掉。
- 开发中不要用System.gc();会导致Stop-the-world的发生。
4.并行与并发
4.1 并行（Parallel）
- 概述
当系统有一个以上CPU时，当一个CPU执行一个进程时，另一个CPU可以执行另一个进程两个进程互不抢占CPU资源，可以同时进行，我们称之为并行(Parallel)。其实决定并行的因素不是CPU的数量，而是CPU的核心数量，比如一个CPU多个核也可以并行。
4.2 并发（Concurrent）
- 概述
在操作系统中，是指一个时间段中有几个程序都处于已启动运行到运行完毕之间，且这几个程序都是在同一个处理器正运行。即多个任务相互争抢资源
4.3 垃圾回收下的并行、串行与并发
- 并行（Parallel）
指多条垃圾收集线程并行工作，但此时用户线程仍处于等待状态。如ParNew、Parallel scavenge、Parallel old;
- 串行（Serial）
相较于并行的概念，单线程执行。如果内存不够，则程序暂停，启动JVM垃圾回收器进行垃圾回收。回收完，再启动程序的线程。
- 并发（Concurrent）
指用户线程与垃圾收集线程同时执行（但不一定是并行的，可能会交替执行），垃圾回收线程在执行时不会停顿用户程序的运行。用户程序在继续运行，而垃圾收集程序线程运行于另一个CPU上；如：CMS、G1
5.安全点与安全区域
5.1 安全点
- 概述
程序执行时并非在所有地方都能停顿下来开始GC，只有在特定的位置才能停顿下来开始GC，这些位置称为“安全点（Safepoint）”。
- 为什么会出现安全点
前面提到在OopMap的协助下，HotSpot可以快速准确地完成GC Roots枚举，但一个很现实的问题随之而来：可能导致引用关系变化，或者说导致OopMap内容变化的指令非常多，如果为每一条指令都生成 对应的OopMap，那将会需要大量的额外存储空间，这样垃圾收集伴随而来的空间成本就会变得无法忍受的高昂。实际上HotSpot也的确没有为每条指令都生成OopMap
即为了解决引用关系的变化，只是在
“特定的位置”记录了这些信息，这些位置被称为安全点（Safepoint）。程序运行期间，很多指令都是有可能修改引用关系的，即要修改OopMap。如果碰到就修改，那代价是十分大的，故而引入了 SafePoint，只在 SafePoint 才会对 OopMap 做一个统一的跟新。这也使得，只有 SafePoint 处 OopMap 是一定准确的，因此只能在 SafePoint 处进行 GC 行为。
- 安全点的选择
Safe Point的选择很重要，如果太少可能导致GC等待的时间太长，如果太频繁可能导致运行时的性能问题。大部分指令的执行时间都非常短暂，通常会根据“是否具有让程序长时间执行的特征”为标准。
比如:选择一些执行时间较长的指令（“长时间执行”的最明显特征就是指令序列的复用）作为Safe Point，如方法调用、循环跳转和异常跳转等。
- 选择的标准方法——如何在GC发生时，检查所有线程都跑到最近的安全点停顿下来呢?
抢先式中断:（目前没有虚拟机采用了)
首先中断所有线程。如果还有线程不在安全点，就恢复线程，让线程跑到安全点。主动式中断:
设置一个中断标志，各个线程运行到safe Point的时候主动轮询这个标志，如果中断标志为真，则将自己进行中断挂起。
- 可能会出现的问题
由于不能设置过多的安全点会提高性能，而我们使用的又是主动式中断那么有时就会出现很多线程等一个线程的情况，注意优化安全点前面的那些代码的执行，例如for循环会单次循环末尾不会被加入安全点，整个for循环期执行结束之前，都不会进入安全点，可以将int转换成long等的措施主动加入安全点
原因
JVM认为循环次数较少的话，执行时间应该也不会太长，所以使用int类型或范围更小的数据类型作为索引值的循环默认是不会被放置安全点的。这种循环被称为可数循环（Counted Loop），相对应地，使用long或者范围更大的数据类型作为索引值的循环就被称为不可数循环（Uncounted Loop），将会被放置安全点。
5.1 安全区域
- 概述
安全区域是指在一段代码片段中，对象的引用关系不会发生变化
（典型的 场景便是用户线程处于Sleep状态或者Blocked状态，这时候线程无法响应虚拟机的中断请求，不能再走到安全的地方去中断挂起自己，虚拟机也显然不可能持续等待线程重新被激活分配处理器时间），在这个区域中的任何位置开始GC都是安全的。我们也可以把Safe Region看做是被扩展了的safepoint。
- 执行过程
- 当线程运行到safe Region的代码时，首先标识已经进入了Safe Region如果这段时间内发生GC，JVM会忽略标识为Safe Region状态的线程;
- 当线程即将离开Safe Region时，会检查VM是否已经完成Gc，如果完成了，则继续运行，否则线程必须等待直到收到可以安全离开safe Region的信号为止;