【JVM】垃圾收集器

最新推荐文章于 2024-08-21 16:01:36 发布

fan__lee

最新推荐文章于 2024-08-21 16:01:36 发布

阅读量113

点赞数

分类专栏： JVM虚拟机文章标签： jvm 内存分配

本文链接：https://blog.csdn.net/fan__lee/article/details/110114266

版权

JVM虚拟机专栏收录该内容

2 篇文章 0 订阅

订阅专栏

垃圾收集器

背景
判断一个对象是否可被回收
引用类型
- 生存还是死亡？
垃圾收集算法
垃圾收集器
内存分配与回收策略
#Minor GC 和 Full GC
- 内存分配策略

背景

垃圾收集(Garbage Collection,简称GC)。
今天的内存动态分配与内存回收技术已经相当成熟，一切看起来已经进入“自动化”时代，那为什么还要去了解垃圾收集和内存分配？

答案很简单：当需要排查各种内存溢出、内存泄漏问题时，当垃圾收集成为达到更高并发量的瓶颈时，我们就需要对这些"自动化"的技术实施必要的监控和调节。

在Java内存运行时区域的各个部分：

其中程序计数器、虚拟栈、本地方法栈3个区域随线程而生，随线程而灭，栈中的栈帧随着方法的进入和退出有条不紊地执行着出栈和入栈操作。每一个栈帧中分配多少内存基本上是在类结构确定下来时就已知的（尽管在运行期会由即时编辑器进行一些优化，但是在基于概念模型的讨论里，大体上可以认为编译期可知的)，由此这几个区域的内存分配和回收都具备确定性，在这几个区域内就不需要过多考虑如何回收的问题，当方法结束或者进程结束时，内存自然就跟随着回收了
而Java堆和方法区这两个区域则有着很显著的不确定性，一个接口的多个实现类的内存可能会不一样，一个方法所执行的不同条件分支所需要的内存也可能不一样，只有处于运行期间，我们才会知道程序究竟会创建那些对象，创建多少个对象，这部分内存的分配和回收是动态的。垃圾收集器受关注的正是这部分内存该如何管理。

判断一个对象是否可被回收

对象已死？

堆里面存着Java世界中几乎所有的对象实例，垃圾收集器在对堆进行回收前的一件事情就是要确定这些对象之中哪些还“存活”着，哪些已经“死去（即不可能再被任何途径使用的对象）”了。

1、引用计数器算法

很多判断对象是否存活的算法是这样的：

在对象中添加一个引用计数器，每当有一个地方引用它时，计数器值就加一；当引用失效时，计数器值就减一。引用计数为0的对象可被回收。
但是，Java中，如果两个对象出现循环引用的情况，而这两个对象再无任何引用，实际上这两个对象已经不可能再被访问，但是此时引用计数器永远不为0，导致无法对他们进行回收。因此Java虚拟机不使用引用计数算法（从以下代码中可以看出，java虚拟机并没有因为他们互相引用而放弃回收他们，也从侧面说明java虚拟机并不是通过引用计数器算法来判断对象是否存活的）。

public class Test {

    public Object instance = null;

    public static void main(String[] args) {
        Test a = new Test();
        Test b = new Test();
        a.instance = b;
        b.instance = a;
        a = null;
        b = null;
        //假设在这发生GC,a,b是否被回收
        System.gc();
    }
}

2、可达性分析算法

当前主流的商用程序语言（Java,C#）的内存管理子系统，都是通过可达性分析算法来判定对象是否存活的。

可达性分析算法：

基本思路是通过一系列称为“GC Roots”的根对象作为其实节点集，从这些节点开始，根据引用关系向下搜索，搜索过程所走过的路径称为“引用链”，如果某个对象到GC Roots间没有任何引用链相连，或者用图论的话来说就是从GC Roots到这个对象不可达，则证明此对象不能再被利用。

如图所示，虽然object 5、object 6、object 7三个对象互相关联，但是他们是不可达的，因此他们会被判定为可回收对象。
在这里插入图片描述

在Java技术体系中，固定可作为GC Roots的对象包括以下几种：

在虚拟栈（栈帧中的本地变量表）中引用的对象，譬如各个线程被调用的方法堆栈中使用到的参数，局部变量、临时变量。
方法区中类静态属性引用的对象，譬如Java类的引用类型静态变量。
方法区中的常量引用的对象，譬如字符串常量池里的引用。
在本地方法栈中JNI（即通常说的Naive方法）引用的对象
Java虚拟机内部的引用，如基本数据类型对象的class对象。
所有被同步锁（synchronized关键字）持有的对象
反映Java虚拟机内部情况的JMXBean，JVMT1中注册的回调，本地代码缓存等

3、方法区的回收

因为方法区主要存放永久代对象，而永久代对象的回收率比新生代低很多，所以在方法区上进行回收性价比不高。

主要是对常量池的回收和对类的卸载。

为了避免内存溢出，在大量使用反射和动态代理的场景都需要虚拟机具备类卸载功能。

类的卸载条件很多，需要满足以下三个条件，并且满足了条件也不一定会被卸载：

该类所有的实例都已经被回收，此时堆中不存在该类的任何实例。
加载该类的 ClassLoader 已经被回收。
该类对应的 Class 对象没有在任何地方被引用，也就无法在任何地方通过反射访问该类方法。

引用类型

无论是通过引用计数算法判断对象的引用数量，还是通过可达性分析算法判断对象是否可达，判定对象是否可被回收都与引用有关。

Java 提供了四种强度不同的引用类型

1、强引用
强引用是最传统的“引用”的定义，是指在程序代码之中普遍存在的引用赋值，即类似Object obj = new Object();这种引用关系
被强引用关联的对象不会被回收。
使用 new 一个新对象的方式来创建强引用。

Object obj = new Object();

2、软引用

软引用是用来描述一些还有用，但非必须的对象。
被软引用关联的对象只有在内存不够（系统将要发生内存溢出前）的情况下才会被回收。
使用 SoftReference 类来创建软引用。

Object obj = new Object();

3、弱引用

弱引用也是用来描述非必须对象，但他的强度比软引用更弱一些
被弱引用关联的对象一定会被回收，也就是说它只能存活到下一次垃圾回收发生之前。

使用 WeakReference 类来创建弱引用。

Object obj = new Object();
WeakReference<Object> wf = new WeakReference<Object>(obj);
obj = null;

4、虚引用

又称为幽灵引用或者幻影引用，一个对象是否有虚引用的存在，不会对其生存时间造成影响，也无法通过虚引用得到一个对象。

为一个对象设置虚引用的唯一目的是能在这个对象被回收时收到一个系统通知。

使用 PhantomReference 来创建虚引用。

Object obj = new Object();
PhantomReference<Object> pf = new PhantomReference<Object>(obj, null);
obj = null;

生存还是死亡？

即使在可达性分析算法中判定为不可达的对象，也不是“非死不可”的，这时候它们暂时还处于“缓刑”阶段，要真正宣告个对象死亡，最多会经历两次标记过程:如果时象在进行可达性分析后发现没有与GC Rools相连接的引用链，那它将会破第一欢标记，随后进行一次筛选，筛选的条件是此对象是否有必要执行finalize()方法。假如对象没有覆盖fnalize()方法，或者finalize()方法已经被虚拟机调用过，那么虚拟机将这两种情况都视为“没有必要执行”。

当一个对象可被回收时，如果需要执行该对象的 finalize() 方法，那么就有可能在该方法中让对象重新被引用，从而实现自救。自救只能进行一次，如果回收的对象之前调用了 finalize() 方法自救，后面回收时不会再调用该方法

垃圾收集算法

1、标记 - 清除
概念：

是最早出现也是最基础的垃圾收集算法。算法分为标记和清除两个阶段
过程：首先标记出所有需要回收的对象，在标记完成后，统一回收所有未被标记的对象。标记过程就是对象是否属于垃圾的判定过程。

缺点：

1、标记和清除过程效率都不高；
2、会产生大量不连续的内存碎片，导致无法给大对象分配内存
它的主要缺点有两个:
第一个是执行效率不稳定，如果Java堆中包含大量对象，而且其中大部分是需要被回收的，这时必须进行大量标记和清除的动作，导致标记和清除两个过程的执行效率都随对象数量增长而降低;
第二个是内存空间的碎片化问题，标记、清除之后会产生大量不连续的内存碎片，空间碎片太多可能会导致当以后在程序运行过程中需要分配较大对象时无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。

在这里插入图片描述
2、标记 - 复制

在这里插入图片描述

标记-复制算法常常被简称为复制算法。为了解决标记 - 清除面对大量可回收对象时执行效率低的问题。

1969年Fenichel提出了一种称为"半区复制"的垃圾回收算法。

概念是：

将可用的内存按容量划分为大小相等的两块，每次只使用其中的一块，当这一块内存用完了就将还存活的对象复制到另一块上面，然后再把使用过的内存空间进行一次清理。

算法讲解
如果内存中多数对象都是存活的，这种算法将会产生大量的内存间复制的开销，但对于多数对象都是可回收的情况，算法需要复制的就是占少数的存活对象，而且每次都是针对整个半区进行内存回收，分配内存时也就不用考虑有空间碎片的复杂情况，只要移动堆顶指针，按顺序分配即可。这样实现简单，运行高效，
不过其缺陷也显而易见，这种复制回收算法的代价是将可用内存缩小为了原来的一-半，空间浪费未免太多了一点

现在的商业虚拟机都采用这种收集算法回收新生代，但是并不是划分为大小相等的两块，而是一块较大的 Eden 空间和两块较小的 Survivor 空间，每次使用 Eden 和其中一块 Survivor。在回收时，将 Eden 和 Survivor 中还存活着的对象全部复制到另一块 Survivor 上，最后清理 Eden 和使用过的那一块 Survivor。

HotSpot 虚拟机的 Eden 和 Survivor 大小比例默认为 8:1，保证了内存的利用率达到 90%。如果每次回收有多于 10% 的对象存活，那么一块 Survivor 就不够用了，此时需要依赖于老年代进行空间分配担保，也就是借用老年代的空间存储放不下的对象。

3、标记-整理算法

在这里插入图片描述
标记-复制算法在对象存活率较高时就要进行较多的复制，效率较低。更关键的是，如果不想浪费50%的空间，就需要有额外的空间进行分配担保，以应对使用的内存中所有对象都100%存错的极端情况，所以在老年代中一般不直接选用这种算法。

针对老年代对象的存亡特征，1974年Edward Lueders提出了有针对性的“标记-整理算法”。

过程：
其中标记过程仍然与标记-清除算法一样，但后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向内存空间一端移动，然后清理掉边界意外的内存。（与标记-清除算法本质区别是，前者是移动式的回收算法，后者是非移动式的）

如果移动存活对象，尤其是在老年代这种每次回收都有大量对象存活区域，移动存活对象并更新所有引用这些对象的地方将会是一种极为负重的操作，而且这种对象移动操作必须全程暂停用户应用程序才能进行，这就更加让使用者不得不小心翼翼地权衡其弊端了，像这样的停顿被最初的虚拟机设计者形象地描述为“Stop The World"
但如果跟标记-清除算法那样完全不考虑移动和整理存活对象的话，弥散于堆中的存活对象导致的空间碎片化问题就只能依赖更为复杂的内存分配器和内存访问器来解决。譬如通过“分区空闲分配链表”来解决内存分配问题(计算机硬盘存储大文件就不要求物理连续的磁盘空间，能够在碎片化的硬盘上存储和访问就是通过硬盘分区表实现的)。内存的访问是用户程序最频繁的操作，甚至都没有之一，假如在这个环节上增加了额外的负担，势必会直接影响应用程序的吞吐量。

4、分代收集

现在的商业虚拟机采用分代收集算法，它根据对象存活周期将内存划分为几块，不同块采用适当的收集算法。

一般将堆分为新生代和老年代。

新生代使用：标记 - 复制算法
老年代使用：标记 - 清除或者标记 - 整理算法

垃圾收集器

1、Serial 收集器

Serial 翻译为串行，也就是说它以串行的方式执行。
它是单线程的收集器，只会使用一个线程进行垃圾收集工作。
它的优点是简单高效，在单个 CPU 环境下，由于没有线程交互的开销，因此拥有最高的单线程收集效率。
它是 Client 场景下的默认新生代收集器，因为在该场景下内存一般来说不会很大。它收集一两百兆垃圾的停顿时间可以控制在一百多毫秒以内，只要不是太频繁，这点停顿时间是可以接受的。

2、ParNew 收集器

它是 Serial 收集器的多线程版本。
它是 Server 场景下默认的新生代收集器，除了性能原因外，主要是因为除了 Serial 收集器，只有它能与 CMS 收集器配合使用

3、Parallel Scavenge 收集器

与 ParNew 一样是多线程收集器。

其它收集器目标是尽可能缩短垃圾收集时用户线程的停顿时间，而它的目标是达到一个可控制的吞吐量，因此它被称为“吞吐量优先”收集器。这里的吞吐量指 CPU 用于运行用户程序的时间占总时间的比值。
停顿时间越短就越适合需要与用户交互的程序，良好的响应速度能提升用户体验。而高吞吐量则可以高效率地利用 CPU 时间，尽快完成程序的运算任务，适合在后台运算而不需要太多交互的任务。

4、Serial Old 收集器

是 Serial 收集器的老年代版本，也是给 Client 场景下的虚拟机使用。如果用在 Server 场景下，它有两大用途：

在 JDK 1.5 以及之前版本（Parallel Old 诞生以前）中与 Parallel Scavenge 收集器搭配使用。
作为 CMS 收集器的后备预案，在并发收集发生 Concurrent Mode Failure 时使用

5、Parallel Old 收集器
是 Parallel Scavenge 收集器的老年代版本。

在注重吞吐量以及 CPU 资源敏感的场合，都可以优先考虑 Parallel Scavenge 加 Parallel Old 收集器

6、CMS 收集器

CMS（Concurrent Mark Sweep），Mark Sweep 指的是标记 - 清除算法。

7、G1 收集器

G1（Garbage-First），它是一款面向服务端应用的垃圾收集器，在多 CPU 和大内存的场景下有很好的性能。HotSpot 开发团队赋予它的使命是未来可以替换掉 CMS 收集器。

内存分配与回收策略

#Minor GC 和 Full GC

Minor GC：回收新生代，因为新生代对象存活时间很短，因此 Minor GC 会频繁执行，执行的速度一般也会比较快。

Full GC：回收老年代和新生代，老年代对象其存活时间长，因此 Full GC 很少执行，执行速度会比 Minor GC 慢很多。

内存分配策略

对象优先在 Eden 分配
大多数情况下，对象在新生代 Eden 上分配，当 Eden 空间不够时，发起 Minor GC。
大对象直接进入老年代
大对象是指需要连续内存空间的对象，最典型的大对象是那种很长的字符串以及数组。
经常出现大对象会提前触发垃圾收集以获取足够的连续空间分配给大对象。
长期存活的对象进入老年代
为对象定义年龄计数器，对象在 Eden 出生并经过 Minor GC 依然存活，将移动到 Survivor 中，年龄就增加 1 岁，增加到一定年龄则移动到老年代中。
动态对象年龄判定
虚拟机并不是永远要求对象的年龄必须达到 MaxTenuringThreshold 才能晋升老年代，如果在 Survivor 中相同年龄所有对象大小的总和大于 Survivor 空间的一半，则年龄大于或等于该年龄的对象可以直接进入老年代，无需等到 MaxTenuringThreshold 中要求的年龄。
空间分配担保
在发生 Minor GC 之前，虚拟机先检查老年代最大可用的连续空间是否大于新生代所有对象总空间，如果条件成立的话，那么 Minor GC 可以确认是安全的。

fan__lee

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
【JVM】垃圾收集器

垃圾收集器背景对象已死？引用计数器算法背景垃圾收集(Garbage Collection,简称GC)。今天的内存动态分配与内存回收技术已经相当成熟，一切看起来已经进入“自动化”时代，那为什么还要去了解垃圾收集和内存分配？答案很简单：当需要排查各种内存溢出、内存泄漏问题时，当垃圾收集成为达到更高并发量的瓶颈时，我们就需要对这些"自动化"的技术实施必要的监控和调节。在Java内存运行时区域的各个部分：其中程序计数器、虚拟栈、本地方法栈3个区域随线程而生，随线程而灭，栈中的栈帧随着方法的进入和退
复制链接

扫一扫