概述及垃圾回收相关算法
1、概述
-
什么是垃圾（Garbage）？
垃圾是指运行程序中没有任何指针指向的对象，这个对象就是需要被回收的垃圾。
外文：An objext is considered garbage when it can no longer be reached from any pointer in the running program. -
垃圾收集
垃圾收集器可以对年轻代回收，也可以对老年代回收，甚至是全堆和方法区的回收。
☞ 其中，java堆是垃圾收集器的工作重点。
从次数上讲：
☞ 频繁收集Young区
☞ 较少收集Old区
☞ 基本不动Perm区 -
算法概述
垃圾标记阶段：判断对象是否存活（当一个对象已经不再被任何的存活对象继续引用时，就可以宣判为已经死亡）
标记算法：引用计数法、可达性分析（java）
清除算法：标记清除算法、复制算法、标记整理(压缩)算法、分代收集、增量收集算法、分区算法
2、标记阶段：引用计数法
- 简介：对每个对象保存一个整型的引用计数器属性，用于记录对象被引用的情况。
对于一个对象A，只要有任何一个对象引用了A，则A的引用计数器+加1；当引用失效时，A的引用计数器就-1。只要对象A的计数器的值为0，即表示对象A不可能再被使用，可进行回收 - 优点：实现简单，垃圾对象便于辨识；判定效率高，回收没有延迟性。
- 缺点：
☞ 需要单独的字段存储计数器，增加了存储空间的开销
☞ 每次复制都要更新计数器，伴随着加法和减法操作，增加了时间开销。
☞ 严重问题：无法处理循环引用，因此Java没有使用引用计数法
/**
* -XX:+PrintGCDetails
* 证明:java使用的不是引用计数算法
*/
public class RefCountGC {
//这个成员属性唯一的作用就是占用一点内存
private byte[] bigSize = new byte[5 * 1024 * 1024];//5MB
Object reference = null;
public static void main(String[] args) {
RefCountGC obj1 = new RefCountGC();
RefCountGC obj2 = new RefCountGC();
obj1.reference = obj2;
obj2.reference = obj1;
obj1 = null;
obj2 = null;
//显式的执行垃圾回收行为，注释和不注释下面的代码，查看GCDetails的区别
//这里发生GC,obj1和obj2能否被回收？
System.gc();
}
}
-
Python如何解决循环引用( 扩展了解 )
手动解决:很好理解,就是在合适的时机,解除引用关系
使用弱引用weakref，weakref是Python提供的标准库，旨在解决循环引用（只要发生了回收，弱引用都会被回收）
3、标记阶段：可达性分析算法
-
可达性分析，又叫根搜索算法、追踪性垃圾收集(Tracing Garbage Collection)。Java、C# 采用
-
通过一系列称为“GC Roots”的对象（集合）作为起始点，从这些节点开始向下搜索，搜索走过的路径称为“引用链”，当一个对象到 GC Roots 没有任何的引用链相连(从 GC Roots 到这个对象不可达)时，证明此对象不可用（是垃圾，被回收）。
-
为什么用可达性分析，解决了什么问题？（优缺点）
相对于引用计数法而言，可达性分析算法不仅同样具备实现简单和执行高效等特点，更重要的是该算法可以有效解决在引用计数算法中循环引用的问题，防止内存泄漏的发生。
-
GC Roots包括哪些内容。
☞ 虚拟机栈（栈帧中的局部变量表）中的引用对象（比如各个线程被调用的方法中使用到的参数、局部变量等）
☞ 本地方法栈中JNI（即一般来说native方法）中引用的对象（ 线程中的start方法 ）
☞ 方法区中类静态属性引用的对象（比如:Java类的引用类型静态变量）
☞ 方法区中常量引用的对象（比如:字符串常量池(String Table)里的引用）☞ 所有被synchronized持有的对象
☞ JVM内部的引用（基本数据类型对应的Class对象,一些常驻的异常对象[如NullPointerException、OutofMemoryError],系统类加载器）
☞ 反映java虚拟机内部情况的JMXBean、JVMTI中注册的回调、本地代码缓存等 -
针对某个区域进行垃圾回收，GC Roots的变化。
注意:除了这些固定的GC Roots集合之外,根据用户所选用的垃圾收集器以及当前回收的内存区域不同，还可以有其他对象临时加入,共同构成完成整GC Roots集合。比如：分代收集和局部回收（partical GC）解释：如果只针对java堆中的某一区域进行垃圾回收（比如: 典型的只针对新生代），必须考虑到内存区域是虚拟机自己的实现细节，更不是孤立封闭的，这个区域的对象完全有可能被其他区域的对象所引用，这时候就需要一并将关联的区域对象也加入到GC Roots 集合中考虑，才能保证可达性分析的准确性。
-
小技巧：由于 Root 采用栈方式存放变量和指针，所以如果一个指针，它保存了堆内存里面的对象，但是自己又不存放在堆内存里面，那么它就是一个Root
-
STW问题：如果要使用可达性分析算法来判断内存是否可回收,那么分析工作必须在 一个能保障一致性的快照中进行。这点不满足的话分析结果的准确性就无法保证。这点也是导致GC进行时必须“StopTheWorld"的一个重要原因。 (即使是号称(几乎)不会发生停顿的CMS收集器中,枚举根节点时也是必须要停顿的)
4、finalization机制
4.1、finalization机制说明
- Java语言提提供了对象终止（finalization）机制来允许开发人员提供对象被销毁之前的自定义逻辑。
- 当垃圾回收器发现没有引用指向一个对象,即:垃圾收集此对象之前,总会先调用这个对象的 finalize() 方法
- finalize() 方法允许在子类中被重写，用于对象被回收时进行资源释放。通常在这个方法中进行一些资源释放和清理的工作，比如关闭文件、套接字和数据库连接等。
4.2、不主动调用 finalize() 方法的三点原因
永远不要主动调用某个对象的finalize() 方法，应该交给垃圾回收机制调用。
- 在finalize() 时可能会导致对象复活。
- finalize() 方法执行时间是没有保障的,它完全由GC线程决定,极端情况下,若不发生GC，则finalize() 方法将没有执行机会
- 一个糟糕的finalize() 会严重影响GC的性能
4.3、虚拟机中对象可能的三种状态
由于finalize()方法的存在，虚拟机中的对象一般处于三种可能的状态。
如果从所有的根节点都无法访问到某个对象,说明对象已经不再使用了。一般来说,此对象需要被回收,但事实上,也并非是"非死不可"的，这时候它们暂时处于"缓刑"阶段。一个无法触及的对象有可能在某一个条件下“复活”自己，如果这样，那么对它的回收就是不合理的。为此,定义虚拟机中的对象可能有三种状态。如下:(掌握)
- 可触及的：从根节点开始,可以到达这个对象
- 可复活的：对象的所有引用都被释放,但是对象有可能在finalize() 中复活
- 不可触及的：对象的finalize( )被调用,并且没有复活,那么就会进入不可触及状态。不可触及的对象不可能被复活,因为 finalize() 只会被调用一次
以上3种状态中，是由于finalize()方法的存在，进行的区分。只有对象不可触及才可以被回收。
4.4、判定对象是否可回收的两次标记过程（理解）
判定一个对象objA是否可回收，至少要经历两次标记过程：
- 如果对象objA到 GC Roots 没有引用链，则进行第一次标记
- 进行筛选，判断此对象是否有必要执行finalize() 方法
- 如果对象objA 没有重写 finalize() 方法，或者 finalize() 方法已经被虚拟机调用过，则虚拟机视为“没有必要执行”，objA被判定为不可触及的。
- 如果对象objA 重写了 finalize() 方法，且还未执行过，那么objA 会被插入到F-Queue队列中，由一个虚拟机自动创建、低优先级的 Finalizer 线程触发其 finalize() 方法执行。
- finalize() 方法是对象逃脱死亡的最后机会，稍后GC会对F-Queue队列中的对象进行第二次标记。如果objA在 finalize() 方法中与引用链上的任何一个对象建立了联系，那么在第二次标记时，objA会被移除“即将回收” 集合。之后对象会再次出现没有引用的情况，在这个情况下，finalize方法不会被再次调用，对象会直接变成不可触及的状态，也就是说，一个对象的 finalize 方法只会被调用一次。
4.5、代码演示
/**
* 测试Object类中finalize()方法,即对象的finalization机制。
*
*/
public class CanReliveObj {
public static CanReliveObj obj;//类变量,属于 GC Root
//此方法只能被调用一次
@Override
protected void finalize() throws Throwable {
super.finalize();
System.out.println("调用当前类重写的finalize()方法");
obj = this;//当前待回收的对象在finalize()方法中与引用链上的一个对象obj建立了联系
}
public static void main(String[] args) {
try {
obj = new CanReliveObj();
// 对象第一次成功拯救自己
obj = null;
System.gc();//调用垃圾回收器
System.out.println("第1次 gc");
// 因为Finalizer线程优先级很低,暂停2秒,以等待它
Thread.sleep(2000);
if (obj == null) {
System.out.println("obj is dead");
} else {
System.out.println("obj is still alive");
}
System.out.println("第2次 gc");
// 下面这段代码与上面的完全相同,但是这次自救却失败了
obj = null;
System.gc();
// 因为Finalizer线程优先级很低,暂停2秒,以等待它
Thread.sleep(2000);
if (obj == null) {
System.out.println("obj is dead");
} else {
System.out.println("obj is still alive");
}
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
5、MAT与JProfiler的GC Roots溯源
5.1、MAT简介及下载
MAT(Memory Analyzer Tool)，一个基于Eclipse的JAVA heap分析工具，可以帮助查找内存泄漏和减少内存消耗。
下载地址：http://www.eclipse.org/mat/
5.2、JProfiler进行GC Roots溯源
- 溯源程序
public class GCRootsTest {
public static void main(String[] args) {
List<Object> numList=new ArrayList<>();
Date birth=new Date();
for(int i=0;i<100;i++){
numList.add(String.valueOf(i));
try {
Thread.sleep(10);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
System.out.println("数据加载完毕，请操作");
new Scanner(System.in).next();
numList=null;
birth=null;
System.out.println("numList、birth已置空，请操作");
new Scanner(System.in).next();
System.out.println("结束");
}
}
2、启动JProfiler，连接相应的进程
5.3、JProfiler分析OOM
- 分析代码
import java.util.ArrayList;
/**
* -Xms8m -Xmx8m -XX:+HeapDumpOnOutOfMemoryError
*/
public class HeapOOM {
byte[] buffer =new byte[1*1024*1024]; //1MB
public static void main(String[] args) {
ArrayList<HeapOOM> list=new ArrayList<>();
int count=0;
try {
while(true){
list.add(new HeapOOM());
count++;
}
}catch (Throwable e){
System.out.println("count ="+count);
e.printStackTrace();
}
}
}
- -XX:+HeapDumpOnOutOfMemoryError 在OOM情况下生成的dump文件，使用JProfiler打开
查看是否存在超大对象：
定位问题：
5.4、生成dump文件的方式
- Java VisualVM 右键相应的程序——堆Dump——再次右键相应的Dump——另存为即可
- jps查看相应的进程
jmap -dump:format=b,live,file=test1.bin 8508
注：8508是进程号
6、清除阶段：标记-清除算法（Mark-Sweep）
-
标记一清除算法(Mark-Sweep)是一种非常基础和常见的垃圾收集算法,该算法被J . McCarthy等人在1960年提出并并应用于Lisp语言.
-
执行过程
当堆中的有效内存空间（available memory）被耗尽的时候，就会停止整个程序（也被称为stop the world），然后进项两项工作：标记和清除。
标记：Collector（垃圾回收器）从引用根节点开始遍历，标记所有被引用的对象。一般是在对象的Header中记录为可达对象
清除：Collector（垃圾回收器）对堆内存从头到尾进行线性的遍历，如果发现某个对象在其Header中没有标记为可达对象，则将其回收 -
图解
-
优缺点
- 优点：不需要额外的空间
- 缺点：
①.两次扫描，耗时严重
②.清理出来的空闲内存不连续，会产生内存碎片，需要维护一个空闲列表
③.效率比较低:标记阶段的遍历与清除阶段的全堆对象遍历两次(经历了两次遍历)
-
注意：这里所谓的清除并不是真的置空，而是把需要清除的对象地址保存在空闲的地址列表里。下次有新对象需要加载时，判断垃圾的位置空间是否够，如果够，就存放。
7、清除阶段：复制算法（Copying）
-
核心思想：将活着的内存空间分为两块，每次只使用其中一块，在垃圾回收时将正在使用的内存中的存活对象复制到未被使用的内存块中，之后清除正在使用的内存块中的所有对象，交换两个内存的角色，最后完成垃圾回收。
-
复制算法的应用。（描述——重点掌握）
Java堆从GC的角度可以细分为：新生代（Eden区、From Survivor区和To Survivor区）和老年代。
新生代和老年代比例是1:2，Eden和from和to比例是8:1:1Minor GC的过程（复制—>清空—>互换）
- Eden、SurvivorFrom复制到SurvivorTo，年龄+1
首先，当Eden区满的时候会触发第一次GC，把还活着的对象拷贝到Survivor From区，当Eden区再次触发GC的时候会扫描Eden区和From区，对这两个区域进行垃圾回收，经过这次回收后还存活的对象，则直接复制到To 区域（如果有对象的年龄已经达到老年的标准，则赋值到老年代），同时把这些对象的年龄+1 - 清空Eden、Survivor From
然后，清空Eden 和 Survivor From 中的对象，也即复制之后有交换，谁空谁是to - SurvivorTo 和 SurvivorFrom 互换
最后，SurvivorTo 和 SurvivorFrom 互换，原SurvivorTo成为下一次GC时的SurvivorFrom 区。部分对象会在 From 和 To 区域中复制来复制去，如此交换15次（由JVM参数 MaxTenuringThreshold决定，这个参数默认是15），最终还是存活的话，就存入老年代。
可查看：https://blog.csdn.net/root_zhb/article/details/118369845
- Eden、SurvivorFrom复制到SurvivorTo，年龄+1
-
图解
-
优缺点
- 优点：
①.没有标记和清除过程,实现简单,运行高效
②. 不会产生内存碎片,且对象完整不丢 - 缺点
①. 浪费了10%的空间
②. 对于G1这种分拆成为大量region的GC,复制而不是移动,意味着GC需要维护region之间对象引用关系,不管是内存占用或者时间开销也不小。
- 优点：
-
注意：复制算法适用于垃圾对象很多，存活对象很少的场景，例如Young区的Survivor From 和 Survivor To区
注意:是当伊甸园区满后,会触发minjor gc,进行垃圾的回收
8、清除阶段：标记-压缩(整理)算法（Mark-Compact）
-
背景
- 复制算法的高效性是建立在存活对象少、垃圾对象多的前提下的。这种情况在新生代经常发生，但是在老年代，更常见的情况是大部分对象都是存活对象。如果依然使用复制算法，由于存活对象较多，复制的成本也将很高。因此，基于老年代垃圾回收的特性，需要使用其他的算法。
- 标记-清除算法的确可以应用在老年代中，但是该算法不仅执行效率低下，而且在执行完内存回收后还会产生内存碎片，所以JVM的设计者需要在此基础之上进行改进。标记-压缩(Mark-Compact) 算法由此诞生
- 1970年前后,G. L. Steele 、C. J. Chene和D.S. Wise 等研究者发布标记-压缩算法。在许多现代的垃圾收集器中，人们都使用了标记-压缩算法或其改进版本。
-
执行过程
- 第一阶段和标记-清除算法一样，从根节点开始标记所有被引用对象。
- 第二阶段将所有的存活对象压缩到内存的一端，按顺序排放。
- 最后，清理边界外所有的空间。
- 可以看到，标记的存活对象将会被整理，按照内存地址依次排列，而未被标记的内存会被清理掉。如此一来，当我们需要给新对象分配内存时，JVM只需要持有一个内存的起始地址即可，这比维护一个空闲列表显然少了许多开销。
-
图解
-
指针碰撞
内存空间以规整和有序的方式分布，即已用和未用的内存都各自一边，彼此之间维系着一个记录下一次分配起始点的标记指针，当为新对象分配内存时，只需要通过修改指针的偏移量将新对象分配在第一个空闲内存位置上，这种分配方式就叫做指针碰撞(Bump the Pointer) -
标记-清除算法和标记-压缩算法的本质差异在于标记-清除算法是一种非移动式的回收算法，标记压缩是移动式的。
是否移动决定是否产生碎片化空间、是否调整引用的地址（当对象被其他对象引用时）。 -
优缺点
-
优点
①. 消除了标记一清除算法当中,内存区域分散的缺点,我们需要给新对象分配内存时,JVM只需要持有一个内存的起始地址即可。
②. 消除了复制算法当中,内存减半的高额代价。 -
缺点
①. 从效率.上来说,标记一整理算法要低于复制算法。
②. 移动对象的同时,如果对象被其他对象引用,则还需要调整引用的地址。
③. 移动过程中,需要全程暂停用户应用程序。即: STW。
-
9、小结（三种清除算法对比）
| 标记-清除（Mark-Sweep） | 标记-压缩（Mark-Compact） | 复制（Copying） | |
|---|---|---|---|
| 速度 | 中等 | 最慢 | 最快 |
| 空间开销 | 少（但会堆积碎片） | 少（不堆积碎片） | 通常需要活对象的2倍大小（不堆积碎片） |
| 移动对象 | 否 | 是 | 是 |
10、分代收集算法
- 没有最好的算法，只有最合适的算法。
- 不同生命周期的对象可以采取不同的收集方式，以便提高回收效率。分代算法是对前面三种算法的实际应用，在新生代使用复制算法eden占8分空间，survivor占两个1分，只浪费10%的空闲空间。老年代使用标记-清除或者标记-清除和标记-压缩混合实现。
- 新生代（Young Gen）
- 新生代特点：区域相对老年代较小，对象生命周期短、存活率低，回收频繁。
- 复制算法的效率只和当前存活对象大小有关，因此很适用于年轻代的回收。而复制算法内存利用率不高的问题，通过hotspot中的两个survivor的设计得到缓解。
- 老年代（Tenured Gen）
- 老年代特点：区域较大，对象生命周期长、存活率高，回收不及年轻代频繁。
- 存在大量存活率高的对象，一般是由标记-清除或者是标记-清除与标记-整理的混合实现。
☞ Mark阶段的开销与存活对象的数量成正比
☞ Sweep阶段的开销与所管理区域的大小成正相关
☞ Compact阶段的开销与存活对象的数据成正比
11、增量收集算法
- 上述现有的算法，在垃圾回收过程中，应用软件将处于一种Stop the World的状态。在Stop the World状态下，应用程序所有的线程都会挂起，暂停一切正常的工作，等待垃圾回收的完成。 如果垃圾回收时间过长,应用程序会被挂起很久，将严重影响用户体验或者系统的稳定性。为了解决这个问题，即对实时垃圾收集算法的研究直接导致了增量收集(Incremental Collecting) 算法的诞生。
- 基本思想
- 如果一次性将所有的垃圾进行处理，需要造成系统长时间的停顿，那么就可以让垃圾收集线程和应用程序线程交替执行。每次，垃圾收集线程只收集一小片区域的内存空间，接着切换到应用程序线程。依次反复，直到垃圾收集完成。
- 总的来说，增量收集算法的基础仍是传统的标记一清除和复制算法。增量收集算法通过对线程间冲突的妥善处理，允许垃圾收集线程以分阶段的方式完成标记、清理或复制工作。
- 缺点：使用这种方式，由于在垃圾回收过程中，间断性地还执行了应用程序代码，所以能减少系统的停顿时间。但是，因为线程切换和上下文转换的消耗，会使得垃圾回收的总体成本上升，造成系统吞吐量的下降。
12、分区算法
- 一般来说，在相同条件下，堆空间越大，一次GC时所需要的时间就越长，有关GC产生的停顿也越长。为了更好的控制GC产生的停顿时间，将一块大的内存区域分割成多个小块，根据目标的停顿时间，每次合理地回收若干小区间，而不是整个堆空间，从而减少一次GC所产生的停顿。
- 分代算法将按照对象的生命周期长短划分成两个部分，分区算法将整个堆空间划分成连续的不同小区间。
- 每一个小区间都独立使用，独立回收。这种算法的好处是可以控制一次回收多个小区间。
2194
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
