Java 入门指南：JVM（Java虚拟机）垃圾回收机制 —— 垃圾回收算法
文章目录
垃圾回收机制
垃圾回收（Garbage Collection，GC），顾名思义就是释放垃圾占用的空间，当需要排查各种内存溢出问题、当垃圾收集成为系统达到更高并发的瓶颈时，我们就需要对这些“自动化”的技术实施必要的监控和调节。有效的使用可以使用的内存，对内存堆中已经死亡的或者长时间没有使用的对象进行清除和回收。
垃圾判断算法
引用计数法
给对象中添加一个引用计数器：
- 每当有一个地方引用它，计数器就加 1；
- 当引用失效，计数器就减 1；
- 任何时候计数器为 0 的对象就是不可能再被使用的。
这个方法实现简单，效率高，但是目前主流的虚拟机中并没有选择这个算法来管理内存，其最主要的原因是它很难解决对象之间循环引用的问题。
![![[Pasted image 20231011222409.png]]](https://i-blog.csdnimg.cn/direct/2ae2be8cb7c34e08b6c4e1d805135ca3.png)
可达性分析算法
该算法通过一系列的称为 “GC Roots” 的对象作为起点，从这些节点开始向下搜索，节点所走过的路径称为引用链，当一个对象到 GC Roots 没有任何引用链相连的话，则证明此对象是不可用的，需要被回收。
![![[Pasted image 20231011222616.png]]](https://i-blog.csdnimg.cn/direct/044431ac269e4fc9ae7a82b892eadb84.png)
图片来源：JavaGuide
Object 6 ~ Object 10 之间虽有引用关系，但它们到 GC Roots 不可达，因此为需要被回收的对象
所谓对象之间的相互引用问题：除了对象 objA 和 objB 相互引用着对方之外，这两个对象之间再无任何引用。但是他们因为互相引用对方，导致它们的引用计数器都不为 0，于是引用计数算法无法通知 GC 回收器回收他们。
所谓的 GC Roots，就是一组必须活跃的引用，不是对象，它们是程序运行时的起点，是一切引用链的源头。在 Java 中，GC Roots 包括以下几种：
- 虚拟机栈中的引用（方法的参数、局部变量等）
- 本地方法栈中 JNI 的引用
- 类静态变量
- 运行时常量池中的常量（String 或 Class 类型）
虚拟机栈中的引用（方法的参数、局部变量等）
public class StackReference {
public void greet() {
Object localVar = new Object(); // 这里的 localVar 是一个局部变量，存在于虚拟机栈中
System.out.println(localVar.toString());
}
public static void main(String[] args) {
new StackReference().greet();
}
}
在 greet 方法中，localVar 是一个局部变量，存在于虚拟机栈中，可以被认为是 GC Roots。
在 greet 方法执行期间，localVar 引用的对象是活跃的，因为它是从 GC Roots 可达的。
当 greet 方法执行完毕后，localVar 的作用域结束，localVar 引用的 Object 对象不再由任何 GC Roots 引用（假设没有其他引用指向这个对象），因此它将有资格作为垃圾被回收掉。
本地方法栈中 JNI 的引用
Java 通过 JNI（Java Native Interface）提供了一种机制，允许 Java 代码调用本地代码（通常是 C 或 C++ 编写的代码）。
当调用 Java 方法时，虚拟机会创建一个栈帧并压入虚拟机栈，而当它调用本地方法时，虚拟机会通过动态链接直接调用指定的本地方法。
![![[Pasted image 20240917212049.png]]](https://i-blog.csdnimg.cn/direct/706a94cd14bb4fd28114ed2b4c7d861d.png)
JNI 引用是在 Java 本地接口（JNI）代码中创建的引用，这些引用可以指向 Java 堆中的对象。
// 假设的JNI方法
public native void nativeMethod();
// 假设在C/C++中实现的本地方法
/*
* Class: NativeExample
* Method: nativeMethod
* Signature: ()V
*/
JNIEXPORT void JNICALL Java_NativeExample_nativeMethod(JNIEnv *env, jobject thisObj) {
jobject localRef = (*env)->NewObject(env, ...); // 在本地方法栈中创建JNI引用
// localRef 引用的Java对象在本地方法执行期间是活跃的
}
在本地（C/C++）代码中，localRef 是对 Java 对象的一个 JNI 引用，它在本地方法执行期间保持 Java 对象活跃，可以被认为是 GC Roots。
一旦 JNI 方法执行完毕，除非这个引用是全局的（Global Reference），否则它指向的对象将会被作为垃圾回收掉（假设没有其他地方再引用这个对象）。
类静态变量
来看下面这段代码：
public class StaticFieldReference {
private static Object staticVar = new Object(); // 类静态变量
public static void main(String[] args) {
System.out.println(staticVar.toString());
}
}
StaticFieldReference 类中的 staticVar 引用了一个 Object 对象，这个引用存储在元空间，可以被认为是 GC Roots。
只要 StaticFieldReference 类未被卸载，staticVar 引用的对象都不会被垃圾回收。如果 StaticFieldReference 类被卸载（这通常发生在其类加载器被垃圾回收时），那么 staticVar 引用的对象也将有资格被垃圾回收（如果没有其他引用指向这个对象）。
运行时常量池中的常量
public class ConstantPoolReference {
public static final String CONSTANT_STRING = "Hello, World"; // 常量，存在于运行时常量池中
public static final Class<?> CONSTANT_CLASS = Object.class; // 类类型常量
public static void main(String[] args) {
System.out.println(CONSTANT_STRING);
System.out.println(CONSTANT_CLASS.getName());
}
}
在 ConstantPoolReference 中，CONSTANT_STRING 和 CONSTANT_CLASS 作为常量存储在运行时常量池。它们可以用来作为 GC Roots。
这些常量引用的对象（字符串"Hello, World"和 Object.class 类对象）在常量池中，只要包含这些常量的 ConstantPoolReference 类未被卸载，这些对象就不会被垃圾回收。
垃圾收集算法
垃圾收集算法（Garbage Collection Algorithm) 是一种自动内存管理机制，用于在程序运行时自动识别和回收不再使用的对象，以释放内存空间和提升系统性能
Mark-Sweep（标记-清除）算法
![![[Pasted image 20231011230810.png]]](https://i-blog.csdnimg.cn/direct/96b2de7317854a8c83046848290189ec.png)
图片来源：JavaGuide
标记-清除（Mark-and-Sweep）算法分为“标记（Mark）”和“清除（Sweep）”阶段：首先标记出所有不需要回收的对象，在标记完成后统一回收掉所有没有被标记的对象。
它是最基础的收集算法，后续的算法都是对其不足进行改进得到。这种垃圾收集算法会带来两个明显的问题：
- 效率问题：标记和清除两个过程效率都不高。
- 空间问题：标记清除后会产生大量不连续的内存碎片。
对于标记的对象是可回收还是不可回收对象，两种说法都有支持者，按照前者：
- 当一个对象被创建时，给一个标记位，假设为 0 (false)；
- 在标记阶段，从根对象出发，将所有可达对象（或用户可以引用的对象）的标记位设置为 1 (true)；
- 扫描阶段 清除标记位为 0 (false)的对象。
Copying（标记-复制）算法
![![[Pasted image 20231011231209.png]]](https://i-blog.csdnimg.cn/direct/118d8a5ee5384e239b25bb2031b56abe.png)
图片来源：JavaGuide
为了解决 标记-清除 算法的效率和内存碎片问题，复制（Copying）收集算法 将内存分为大小相同的两块，每次使用其中的一块。
当这一块的内存使用完后，就将还存活的对象复制到另一块去，然后再把使用的空间一次清理掉。这样就使每次的内存回收都是对内存区间的一半进行回收。
该算法存在的问题：
- 可用内存变小：可用内存缩小为原来的一半。
- 不适合老年代：如果存活对象数量比较大，复制性能会变得很差。
Mark-and-Compact（标记-整理）算法
![![[Pasted image 20231011231514.png]]](https://i-blog.csdnimg.cn/direct/f8b31b8188c84e50b80bf535e72105ec.png)
图片来源：JavaGuide
标记-整理（Mark-and-Compact）算法是根据老年代的特点提出的一种标记算法，标记过程仍然与“标记-清除”算法一样，但后续步骤是让所有存活的对象向一端移动，然后直接清理掉端边界以外的内存。
由于多了整理这一步，因此效率不高，适合老年代这种垃圾回收频率不是很高的场景。
Generation Collection (分代收集) 算法
当前虚拟机的垃圾收集都采用分代收集算法，这种算法没有什么新的思想，只是根据对象存活周期的不同将内存分为几块。一般将 Java 堆分为新生代和老年代，根据各个年代的特点选择合适的垃圾收集算法，通过优化垃圾收集的效率，提高了系统的性能。
比如在新生代中，每次 GC 都会有大量对象死去，可以选择 Copying 算法，只需要付出少量对象的复制成本就可以完成每次垃圾收集。
而老年代的对象存活几率是比较高的，而且没有额外的空间对它进行分配担保，必须选择“标记-清除”或“标记-整理”算法进行垃圾收集。
Java 虚拟机（JVM）中的垃圾收集器通常会根据堆内存的大小、对象的存活时间等因素动态选择合适的垃圾收集算法和策略，以最大程度地提高内存利用率和应用程序的性能。
原文地址：https://blog.csdn.net/Zachyy/article/details/142318854
免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！