深入理解java虚拟机——垃圾收集器

最新推荐文章于 2023-05-08 10:00:00 发布

简牧

最新推荐文章于 2023-05-08 10:00:00 发布

阅读量414

点赞数

分类专栏： java 文章标签： jvm java

本文链接：https://blog.csdn.net/qq_35799003/article/details/52183554

版权

java 专栏收录该内容

6 篇文章 0 订阅

订阅专栏

概述

垃圾收集（Garbage Collection，GC），大部分人都把这项技术当成是java语言的伴生产物。GC就是让jvm自己完成三件事：
1. 哪些内存需要回收？
2. 什么时候回收？
3. 如何回收？
既然内存的动态分配和内存回收技术已经相当成熟了，那为什么我们还要去了解GC呢？很简单：当我们需要排查各种内存溢出、内存泄露时，当垃圾回收成为系统达到更高并发的瓶颈时，我们就有必要来了解这些隐藏在内部的东西了。

哪些内存需要回收

我们一个直观的感受就是当一个对象不再被需要的时候（对象已死）就需要被回收。

什么是引用？

我们知道，一个对象是被分配在内存（堆）中的，在java中也是被一个“引用”来找到这个对象。
java1.2之前对引用的定义就是：如果reference类型的数据中存储的数值代表的是另外一块内存的起始地址，就称这块内存代表着一个引用。（是不是很像C++里的指针）。
java1.2之后对引用的概念进行了扩充，将引用分为强引用，软引用，弱引用和虚引用，这里就不再展开来说。

如何判断对象已死？

引用计数算法

这是一个很传统的算法，就是给对象添加一个引用计数器，每当有一个地方引用它，就给引用计数器加1，当引用失效，就减1。
其实，引用计数算法实现很简单，而且判定效率也很高，在大部分情况下都是一个很不错的算法，但是主流的java虚拟机都没有使用这个来管理内存，主要原因是无法解决对象之间的相互引用问题。
比如：

    public class ReferenceObj {
        public Object instance = null;
    }
    public static void testGC() {
        ReferenceObj objA = new ReferenceObj();
        ReferenceObj objB = new ReferenceObj();
        objA.instance = objB;
        objB.instance = objA;
        objA = null;
        objB = null;
        System.gc();
    }

上面这个testGC执行的话，虚拟机还是会回收它们，并没有因为它们相互引用就不回收，也从侧面说明了虚拟机不是通过引用计数算法来判断对象是否存活的。

可达性分析算法

当前主流的程序语言的主流实现都是通过可达性分析（Reachability Analysis）来判定对象是否存活的。这个算法的基本思想就是通过一系列成为“GC Roots”的对象作为起始点，从这些节点向下搜索，所走过的路径成为引用链（Reference Chain），当一个对象到GC Roots没有任何引用链（不可达）时，则证明该对象不可用（已死）。
可以作为GC Roots的对象包括：
1. 虚拟机栈（栈帧中的本地变量表）中引用的对象。
2. 方法区中类静态属性引用的对象。
3. 方法区中常量引用的对象。
4. 本地方法栈中JNI引用的对象。

垃圾回收

算法思想

标记-清除算法

最基础的算法就是标记-清除算法（Mark-Sweep）算法，同名字一样，算法分为“标记”和“清除”两个阶段：首先，标记处所有需要回收的对象，在标记完成后统一回收所有被标记的对象。执行过程如图：
这里写图片描述
这种算法主要有两个不足：一是效率问题，标记和清除两个过程效率都不高；另一个是空间问题，标记清除后会产生大量的不连续的内存空间。这会导致在后面程序运行过程中需要分配较大对象时，无法找到足够的连续内存而不得不触发另一次垃圾回收。

复制算法

为了解决效率问题，一种称为“复制”（coping）的收集算法出现了，它将内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块内存用完了，就将还活着的对象复制到另一块上面，再把已经使用过的内存空间全部清理掉。
这样，每次都只在半区进行内存回收，每次分配也不用考虑内存碎片的情况，只需要按顺序分配即可，实现简单，运行高效。代价是将内存缩小为原来的一半，算法执行过程如图：
这里写图片描述
IBM的专门研究表明，新生代中的对象98%是朝生夕死的，所以并不需要按照1∶1的比例来划分内存空间，而是将内存分为一块较大的Eden空间和两块较小的Survivor空间，每次使用Eden和其中的一块Survivor。当回收时，将Eden和Survivor中还存活着的对象一次性地拷贝到另外一块Survivor空间上，最后清理掉Eden和刚才用过的Survivor的空间。HotSpot虚拟机默认Eden和Survivor的大小比例是8∶1，也就是每次新生代中可用内存空间为整个新生代容量的90%（80%+10%），只有10%的内存是会被“浪费”的。

标记-整理算法

复制收集算法在对象存活率较高时就要执行较多的复制操作，效率将会变低。更关键的是，如果不想浪费50%的空间，就需要有额外的空间进行分配担保，以应对被使用的内存中所有对象都100%存活的极端情况，所以在老年代一般不能直接选用这种算法。
根据老年代的特点，有人提出了另外一种“标记-整理”（Mark-Compact）算法，标记过程仍然与“标记-清除”算法一样，但后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存，“标记-整理”算法的示意图如图：
这里写图片描述

分代收集算法

当前商业虚拟机的垃圾收集都采用“分代收集”（Generational Collection）算法，这种算法并没有什么新的思想，只是根据对象的存活周期的不同将内存划分为几块。一般是把Java堆分为新生代和老年代，这样就可以根据各个年代的特点采用最适当的收集算法。在新生代中，每次垃圾收集时都发现有大批对象死去，只有少量存活，那就选用复制算法，只需要付出少量存活对象的复制成本就可以完成收集。而老年代中因为对象存活率高、没有额外空间对它进行分配担保，就必须使用“标记-清理”或“标记-整理”算法来进行回收。

垃圾收集器

垃圾回收算法是内存回收的方法论，那么垃圾收集器就是具体的实现。
以HotSpot的jvm1.6为例
这里写图片描述
但我们要记住一点：虽然我们是在对各个收集器进行比较，但并非为了挑选一个最好的收集器出来。因为直到现在为止还没有最好的收集器出现，更加没有万能的收集器，所以我们选择的只是对具体应用最合适的收集器。

Serial收集器

Serial收集器是最基本、历史最悠久的收集器，曾经（在JDK 1.3.1之前）是虚拟机新生代收集的唯一选择。大家看名字就知道，这个收集器是一个单线程的收集器，但它的“单线程”的意义并不仅仅是说明它只会使用一个CPU或一条收集线程去完成垃圾收集工作，更重要的是在它进行垃圾收集时，必须暂停其他所有的工作线程（Sun将这件事情称之为“Stop The World”），直到它收集结束。
实际上到现在为止，它依然是虚拟机运行在Client模式下的默认新生代收集器。它也有着优于其他收集器的地方：简单而高效（与其他收集器的单线程比），对于限定单个CPU的环境来说，Serial收集器由于没有线程交互的开销，专心做垃圾收集自然可以获得最高的单线程收集效率。

ParNew收集器

ParNew收集器其实就是Serial收集器的多线程版本，除了使用多条线程进行垃圾收集之外，其余行为包括Serial收集器可用的所有控制参数（例如：-XX:SurvivorRatio、 -XX:PretenureSizeThreshold、-XX:HandlePromotionFailure等）、收集算法、Stop The World、对象分配规则、回收策略等都与Serial收集器完全一样。

Parallel Scavenge收集器

Parallel Scavenge收集器也是一个新生代收集器，它也是使用复制算法的收集器，又是并行的多线程收集器……看上去和ParNew都一样，那它有什么特别之处呢？

Parallel Scavenge收集器的特点是它的关注点与其他收集器不同，CMS等收集器的关注点尽可能地缩短垃圾收集时用户线程的停顿时间，而Parallel Scavenge收集器的目标则是达到一个可控制的吞吐量（Throughput）。所谓吞吐量就是CPU用于运行用户代码的时间与CPU总消耗时间的比值，即吞吐量 = 运行用户代码时间 /（运行用户代码时间 + 垃圾收集时间），虚拟机总共运行了100分钟，其中垃圾收集花掉1分钟，那吞吐量就是99%。

停顿时间越短就越适合需要与用户交互的程序，良好的响应速度能提升用户的体验；而高吞吐量则可以最高效率地利用CPU时间，尽快地完成程序的运算任务，主要适合在后台运算而不需要太多交互的任务。

Parallel Scavenge收集器提供了两个参数用于精确控制吞吐量，分别是控制最大垃圾收集停顿时间的-XX:MaxGCPauseMillis参数及直接设置吞吐量大小的 -XX:GCTimeRatio参数。

Serial Old收集器

Serial Old是Serial收集器的老年代版本，它同样是一个单线程收集器，使用“标记-整理”算法。这个收集器的主要意义也是被Client模式下的虚拟机使用。如果在Server模式下，它主要还有两大用途：一个是在JDK 1.5及之前的版本中与Parallel Scavenge收集器搭配使用，另外一个就是作为CMS收集器的后备预案，在并发收集发生Concurrent Mode Failure的时候使用。

Parallel Old收集器

Parallel Old是Parallel Scavenge收集器的老年代版本，使用多线程和“标记－整理”算法。这个收集器是在JDK 1.6中才开始提供的，在此之前，新生代的Parallel Scavenge收集器一直处于比较尴尬的状态。原因是，如果新生代选择了Parallel Scavenge收集器，老年代除了Serial Old（PS MarkSweep）收集器外别无选择（还记得上面说过Parallel Scavenge收集器无法与CMS收集器配合工作吗？）。由于单线程的老年代Serial Old收集器在服务端应用性能上的“拖累”，即便使用了Parallel Scavenge收集器也未必能在整体应用上获得吞吐量最大化的效果，又因为老年代收集中无法充分利用服务器多CPU的处理能力，在老年代很大而且硬件比较高级的环境中，这种组合的吞吐量甚至还不一定有ParNew加CMS的组合“给力”。
直到Parallel Old收集器出现后，“吞吐量优先”收集器终于有了比较名副其实的应用组合，在注重吞吐量及CPU资源敏感的场合，都可以优先考虑Parallel Scavenge加Parallel Old收集器。

CMS收集器

CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。目前很大一部分的Java应用都集中在互联网站或B/S系统的服务端上，这类应用尤其重视服务的响应速度，希望系统停顿时间最短，以给用户带来较好的体验。CMS收集器就非常符合这类应用的需求。

从名字（包含“Mark Sweep”）上就可以看出CMS收集器是基于“标记-清除”算法实现的，它的运作过程相对于前面几种收集器来说要更复杂一些，整个过程分为4个步骤，包括：

初始标记（CMS initial mark）

并发标记（CMS concurrent mark）

重新标记（CMS remark）

并发清除（CMS concurrent sweep）

其中初始标记、重新标记这两个步骤仍然需要“Stop The World”。初始标记仅仅只是标记一下GC Roots能直接关联到的对象，速度很快，并发标记阶段就是进行GC Roots Tracing的过程，而重新标记阶段则是为了修正并发标记期间，因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段稍长一些，但远比并发标记的时间短。
由于整个过程中耗时最长的并发标记和并发清除过程中，收集器线程都可以与用户线程一起工作，所以总体上来说，CMS收集器的内存回收过程是与用户线程一起并发地执行的。

G1收集器

G1（Garbage First）收集器是当前收集器技术发展的最前沿成果，在JDK 1.6_Update14中提供了Early Access版本的G1收集器以供试用。在将来JDK 1.7正式发布的时候，G1收集器很可能会有一个成熟的商用版本随之发布。这里只对G1收集器进行简单介绍。
G1收集器是垃圾收集器理论进一步发展的产物，它与前面的CMS收集器相比有两个显著的改进：一是G1收集器是基于“标记-整理”算法实现的收集器，也就是说它不会产生空间碎片，这对于长时间运行的应用系统来说非常重要。二是它可以非常精确地控制停顿，既能让使用者明确指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒，这几乎已经是实时Java（RTSJ）的垃圾收集器的特征了。
G1收集器可以实现在基本不牺牲吞吐量的前提下完成低停顿的内存回收，这是由于它能够极力地避免全区域的垃圾收集，之前的收集器进行收集的范围都是整个新生代或老年代，而G1将整个Java堆（包括新生代、老年代）划分为多个大小固定的独立区域（Region），并且跟踪这些区域里面的垃圾堆积程度，在后台维护一个优先列表，每次根据允许的收集时间，优先回收垃圾最多的区域（这就是Garbage First名称的来由）。区域划分及有优先级的区域回收，保证了G1收集器在有限的时间内可以获得最高的收集效率。