java垃圾回收机制（二）

最新推荐文章于 2024-10-09 14:22:14 发布

原创最新推荐文章于 2024-10-09 14:22:14 发布 · 441 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#java #算法 #线程

java 同时被 3 个专栏收录

28 篇文章

订阅专栏

java基础

21 篇文章

订阅专栏

深入理解Java虚拟机

3 篇文章

订阅专栏

本文详细介绍了多种Java垃圾收集器，包括Serial、ParNew、Parallel Scavenge、Serial Old、Parallel Old、CMS以及G1收集器的特点、应用场景及优缺点。帮助读者理解不同收集器之间的区别，以便于在实际开发过程中做出合理的选择。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

收集算法是内存回收的方法论，那么垃圾收集器就是内存回收的具体实现，前面主要介绍了垃圾回收算法，接下来主要介绍几种垃圾收集器：

1.Serial收集器

       Serial收集器是最基本，发展历史最为悠久的收集器，曾经（JDK1.3之前）是新生代收集的唯一选择。由名字就知道它是一个单线程的收集器，但不仅仅说明它只会使用一个CPU或一条收集线程去完成垃圾收集工作，更重要的是在垃圾收集时，必须暂停其它所有的工作线程，直到它收集结束。“Stop the World”，这项工作是由虚拟机在后台自动发起和自动完成的，在用户不可见的情况下把用户正常工作的线程全部停掉。而这也正是带给用户不良体验的源头。 
       Serial收集器优于其它收集器的地方在于简单高效，对于限定单个CPU环境来说，Serial收集器由于没有线程交互的开销，专心做垃圾收集自然获得最高的单线程收集效率。所以对于运行在Client模式下的虚拟机来说，Serial收集器是一个很好的选择。

2.ParNew收集器

    ParNew收集器就是Serial收集器的多线程版本，除了使用多条线程进行垃圾收集之外，其余行为都与Serial收集器完全一样。该收集器运行在Server模式下的虚拟机中首选的新生代收集器。与性能无关的原因外，除了Serial收集器，目前只有它能与CMS收集器配合工作。

3.Paraller Scavenge收集器

    Paraller Scavenge收集器是一个新生代收集器，也是使用复制算法和并行的多线程收集器。这些与ParNew收集器类似。但它的目标则是达到一个可控制的吞吐量。吞吐量就是CPU用户运行用户代码的时间与CPU总消耗时间的比值，即吞吐量=运行用户代码时间/（运行用户代码时间+垃圾收集时间），虚拟机总共运行了100分钟，其中垃圾收集花掉了1分钟，那吞吐量就是99%。
    停顿时间越短就越适合需要与用户交互的程序，良好的相应速度能提高用户体验，而高吞吐量则可以高效率的利用CPU时间，尽快完成程序的运算任务，主要适合在后台运算而不需要太多交互任务。
    Paraller Scavenge收集器提供了两个参数用于精确控制吞吐量，分别是控制最大垃圾收集停顿时间的-XX：MaxGCPauseMillis参数以及直接设置吞吐量大小的-XX：GCTimeRatio参数。
    然而并不是按照我们所想的额，把GC收集停顿时间设置的越小越好，因为GC停顿时间缩短是以牺牲吞吐量和新生代空间来换取的。Paraller Scavenge收集器也常被称为“吞吐量优先”收集器，虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整这些参数以提供最适合的的停顿时间或者最大的吞吐量，这种调节方式被称为“ＧＣ自适应的调节策略”。自适应调节策略也是Paraller Scavenge收集器与ParＮｅｗ收集器的一个重要区别。

４.Serial Old收集器

   Serial Old收集器是serial收集器的老年代版本，同样是一个单线程收集器，使用标记-整理算法，主要意义在于给Client模式下的虚拟机使用。如果运行在Server模式下：一是在JDK1.5以及之前的版本中与Parallel Scavenge收集器搭配使用，而是作为CMS收集器的后备方案，在并发收集发生Concurrent Mode Failure时使用。

5.Paraller Old收集器

    Paraller Old收集器是Paraller Scavenge收集器的老年代版本，使用多线程和标记-整理算法。在注重吞吐量以及CPU资源敏感的场合，都可以优先考虑Paraller Scavenge收集器加Paraller Old收集器

6.ＣＭＳ收集器

CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。基于标记-清除算法实现，重视哦服务的响应速度，停顿时间最短，目前应用在java应用集中的互联网站或者B/S系统的服务端上。
整个过程分为四个阶段：
初始标记--并发标记--重新标记--并发清除
    其中，初始标记和重新标记仍然需要“Stop the World”，初始标记仅仅只是标记一个GC roots 能直接关联到的对象，速度很快，并发标记阶段就是进行GC Roots 寻迹的过程，而重新标记阶段则是为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段稍长一点，但远比并发标记时间短。
整个过程耗时最长的并发标记和并发清除过程收集器线程都可以与用户线程一起工作。所以，总体上，ＣＭＳ收集器的内存回收过程与用户线程一起并发执行的。
三个明显的缺点：
   一.　ＣＭＳ收集器对ＣＰＵ资源非常敏感。面向并发设计的程序都对ＣＰＵ资源比较敏感。
   二.ＣＭＳ收集器无法处理浮动垃圾。由于CMS并发清理阶段用户线程还在运行伴随程序运行自然有新的垃圾，这一部分垃圾出现在标记过程之后，ＣＭＳ无法在当次收集中处理掉他们，只好留待下一次GC时再清理掉。这一部分垃圾被称为“浮动垃圾”。
   三.ＣＭＳ收集器是基于垃圾清理算法实现的，意味着垃圾收集结束后会有大量的空间碎片产生。

７.Ｇ１（Garbage-First）收集器

    Ｇ１（Garbage-First）收集器是当今收集器技术发展的最前沿的成果之一。是一款面向服务端应用的垃圾收集器。具备以下特点：
并行与并发：G1能充分利用多CPU、多核环境下的硬件优势，使用多个CPU（CPU或者CPU核心）来缩短Stop-The-World停顿的时间，部分其他收集器原本需要停顿Java线程执行的GC动作，G1收集器仍然可以通过并发的方式让Java程序继续执行。
分代收集：与其他收集器一样，分代概念在G1中依然得以保留。虽然G1可以不需其他收集器配合就能独立管理整个GC堆，但它能够采用不同的方式去处理新创建的对象和已经存活了一段时间、熬过多次GC的旧对象以获取更好的收集效果。
空间整合：与CMS的“标记-清理”算法不同，G1从整体看来是基于“标记-整理”算法实现的收集器，从局部（两个Region之间）上看是基于“复制”算法实现，无论如何，这两种算法都意味着G1运作期间不会产生内存空间碎片，收集后能提供规整的可用内存。这种特性有利于程序长时间运行，分配大对象时不会因为无法找到连续内存空间而提前触发下一次GC。
可预测的停顿：这是G1相对于CMS的另外一大优势，降低停顿时间是G1和CMS共同的关注点，但G1除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒，这几乎已经是实时Java（RTSJ）的垃圾收集器特征了

运作过程

    如果不计算维护Remembered Set的操作，G1收集器的运作大致可划分为以下几个步骤：
    初始标记（Initial Marking）
    并发标记（Concurrent Marking）
    最终标记（Final Marking）
    筛选回收（Live Data Counting and Evacuation）
    初始标记阶段仅仅只是标记一下GC Roots能直接关联到的对象，并且修改TAMS（Next Top at Mark Start）的值，让下一阶段用户程序并发运行时，能在正确可用的Region中创建新对象，这阶段需要停顿线程，但耗时很短。并发标记阶段是从GC Root开始对堆中对象进行可达性分析，找出存活的对象，这阶段耗时较长，但可与用户程序并发执行。而最终标记阶段则是为了修正并发标记期间，因用户程序继续运作而导致标记产生变动的那一部分标记记录，虚拟机将这段时间对象变化记录在线程Remembered Set Logs里面，最终标记阶段需要把Remembered Set Logs的数据合并到Remembered Set中，这阶段需要停顿线程，但是可并行执行。最后筛选回收阶段首先对各个Region的回收价值和成本进行排序，根据用户所期望的GC停顿时间来制定回收计划，从Sun透露出来的信息来看，这个阶段其实也可以做到与用户程序一起并发执行，但是因为只回收一部分Region，时间是用户可控制的，而且停顿用户线程将大幅提高收集效率。

Java垃圾回收机制（一）
参考：http://blog.youkuaiyun.com/zsuguangh/article/details/6429592