您的位置: 首页  >  文章  >  GC垃圾回收

GC垃圾回收

分类: 文章 • 2024-08-28 11:15:58

GC垃圾回收

简介：

Garbage Collection（GC），Java进程在启动后会创建垃圾回收线程，来对内存中无用的对象进行回 收。

垃圾回收的时机

System.gc()

显示的调用System.gc()：此方法的调用是建议JVM进行 FGC（Full GC），虽然只是建议而非一定，但 很多情况下它会触发 FGC，从而增加FGC的频率。一般不使用此方法，让虚拟机自己去管理它的内存。

JVM垃圾回收机制决定

  • 创建对象时需要分配内存空间，如果空间不足，触发GC
  • 其他回收机制，这部分在后续具体讲解。

java.lang.Object中有一个fifinalize() 方法，当JVM 确定不再有指向该对象的引用时，垃圾收集器在对象 上调用该方法。fifinalize() 方法有点类似对象生命周期的临终方法，JVM 调用该方法，表示该对象即 将“死亡”，之后就可以回收该对象了。注意回收还是在JVM 中处理的，所以手动调用某个对象的 fifinalize() 方法，不会造成对象的“死亡”。

Object类finilize()作用:对象进行垃圾回收之前，标记对象的可回收状态

垃圾回收策略————如何判断对象已死？

需要垃圾回收某一个对象时，需要判断这个对象是否可以回收，怎么判断一般有两种算法：

引用计数算法

  1. 给对象中添加一个引用计数器，每当有一个地方引用它时，计数器值就加1；当引用失效时，计数器值 就减1；任何时刻计数器为0的对象就是不可能再被使用的。 引用计数算法的实现简单，判定效率也很 高，在大部分情况下它都是一个不错的算法。但是它很难解决对象之间相互循环引用的问题。
  2. Python、ActionScript等语言都是基于引用计数法。

可达性分析算法

  1. 通过一系列的称为“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为 GC Roots引用链（Reference Chain），当一个对象到GC Roots没有任何引用链相连（用图论的话来 说，就是从GC Roots到这个对象不可达）时，则证明此对象是不可用的。如下图，object5和object6虽 然相互引用，但是由于他们到GC Roots都不可达，因此会被判定为可回收的对象。
  2. Java、C#等语言都 是使用可达性分析算法进行垃圾回收。

GC垃圾回收

编程语言类型

GC垃圾回收

Java的语言类型

  • Java属于混合型语言（Mixed Mode），即有编译期编译的过程，也存在运行期解释和编译的过程。
  • 在编译期通过javac编译器编译java文件
  • 运行期通过解释器（Interpreter）和即时编译器（Just In Time Compiler，JIT编译器）配合完成解释、编译工作

Java的引用类型

无论是通过引用计数算法判断对象的引用数量，还是通过可达性分析算法判断对象的引用链是否可达， 判定对象是否存活都与“引用”有关。

强引用：

指在程序代码之中普遍存在的，类似“Object obj=new Object（）”这类的引用，只要强引用还存在，垃圾收集器永远不会回收掉被引用的对象。

软引用：

用来描述一些还有用但并非必需的对象。对于软引用关联着的对象，在系统将要发生内存溢出异常之 前，将会把这些对象列进回收范围之中进行第二次回收。如果这次回收还没有足够的内存，才会抛出内 存溢出异常。在JDK 1.2之后，提供了SoftReference类来实现软引用。

弱引用：

用来描述非必需对象的，但是它的强度比软引用更弱一些，被弱引用关联的对象只能生存到下一次垃圾收集发生之前。当垃圾收集器工作时，无论当前内存是否足够，都会回收掉只被弱引用关联的对象。在 JDK 1.2之后，提供了WeakReference类来实现弱引用。

虚引用：

也称为幽灵引用或者幻影引用，它是最弱的一种引用关系。一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象实例。为一个对象设置虚引用

（PhantomReference）关联的唯一目的就是能在这个对象被收集器回收时收到一个系统通知。

方法区（jdk1.7）/元空间（jdk1.8）

  • JDK1.7的方法区在GC中一般称永久代（Permanent Generation）。
  • JDK1.8的元空间存在于本地内存，GC也是即对元空间垃圾回收。
  • 永久代或元空间的垃圾收集主要回收两部分内容：废弃常量和无用的类。此区域进行垃圾收集 的“性价比”一般比较低

堆

  • Java堆是垃圾收集器管理的主要区域，因此很多时候也被称做“GC堆”（Garbage Collected Heap）。

  • 从内存回收的角度来看，由于现在收集器基本都采用分代收集算法，所以Java堆中还可以细分为：

    1. 新生代（Young Generation）：又可以分为Eden空间、From Survivor空间、To Survivor 空间。

      • 新生代的垃圾回收又称为Young GC（YGC）、Minor GC。

      • 指发生在新生代的垃圾收集动作，因为Java对象大多都具备朝生夕灭的特性，所以

        Minor GC非常频繁，一般回收速度也比较快。

    2. 老年代（Old Generation、Tenured Generation）

      • 老年代垃圾回收又称为Major GC
      • 指发生在老年代的GC，出现了Major GC，经常会伴随至少一次的Minor GC（但非绝对 的，在Parallel Scavenge收集器的收集策略里就有直接进行Major GC的策略选择过 程）。
      • Major GC的速度一般会比Minor GC慢10倍以上

    3. Full GC：在不同的语义条件下，对Full GC的定义也不同，有时候指老年代的垃圾回收，有时 候指全堆（新生代+老年代）的垃圾回收，还可能指有用户线程暂停（Stop-The-World）的 垃圾回收（如GC日志中）。

GC垃圾回收

垃圾回收算法

标记-清除算法（Mark-Sweep算法）

  • 最基础的收集算法，老年代收集算法。
  • 如同它的名字一样，算法分为“标记”和“清除”两个阶段：首先标记出所有需要回收的对象，在标记 完成后统一回收所有被标记的对象。
  • 之所以说它是最基础的收集算法，是因为后续的收集算法都是基于这种思路并对其不足进行改进而 得到的。

它的主要不足有两个：

  1. 效率问题，标记和清除两个过程的效率都不高。
  2. 空间问题，标记清除之后会产生大量不连续的内存碎片，空间碎片太多可能会导致以后在程 序运行过程中需要分配较大对象时，无法找到足够的连续内存而不得不提前触发另一次垃圾 收集动作。
    GC垃圾回收

复制算法（Copying算法）

  • 新生代的收集算法
  • 将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将 还存活着的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。这样使得每次都 是对整个半区进行内存回收，内存分配时也就不用考虑内存碎片等复杂情况，只要移动堆顶指针， 按顺序分配内存即可，实现简单，运行高效。
  • 只是这种算法的代价是将内存缩小为了原来的一半，未免太高了一点

GC垃圾回收

标记-整理算法（Mark-Compact算法）

  • 老年代收集算法
  • 标记过程仍与"标记-清除"过程一致，但后续步骤不是直接对可回收对象进行清理，而是让所有存 活对象都向一端移动，然后直接清理掉端边界以外的内存

分代收集算法

  • 当前JVM垃圾收集都采用的是"分代收集(Generational Collection)"算法，这个算法并没有新思 想，只是根据对象存活周期的不同将内存划分为几块。
  • 一般是把Java堆分为新生代和老年代。
  • 新生代中98%的对象都是"朝生夕死"的，所以并不需要按照复制算法所要求1 : 1的比例来划分内存 空间，而是将内存（新生代内存）分为一块较大的Eden（伊甸园）空间和两块较小的 Survivor（幸存者）空间，每次使用Eden和其中一块Survivor（两个Survivor区域一个称为From 区，另一个称为To区域）。HotSpot默认Eden与Survivor的大小比例是8 : 1，也就是说**Eden : Survivor From : Survivor To = 8 : 1 : 1。**所以每次新生代可用内存空间为整个新生代容量的90%， 只有10%的内存会被”浪费“。
  • 在新生代中，每次垃圾回收都有大批对象死去，只有少量存活，因此我们采用复制算法；而老年代 中对象存活率高、没有额外空间对它进行分配担保，就必须采用"标记-清理"或者"标记-整理"算 法。

垃圾回收的过程

内存分配：

  1. 对象优先在Eden分配：大多数情况下，对象在新生代Eden区中分配。当Eden区没有足够的空间进行分配时，虚拟机将发生一 次Minor GC。
  2. 大对象直接进入老年代：
    • 所谓的大对象是指，需要大量连续空间的Java对象，最典型的大对象就是那种很长的字符串以及数 组。
    • 大对象对虚拟机的内存分配是一个坏消息，经常出现大对象容易导致内存还有不少空间时就提前触 发GC以获取足够的连续空间来放置大对象。
  3. 长期存活的对象将进入老年代：如果对象在Eden出生并经过 一次Minor GC后仍然存活，并且能被Survivor容纳的话，将被移动到Survivor空间中，并且把对 象年龄设为1。对象在Survivor空间中每"熬过"一次Minor GC，年龄就增加1岁，当它的年龄增加 到一定程度(默认为15岁)，就将晋 升到老年代中。
  4. 动态对象年龄判定：
    • 为了能更好的适应不同程序的内存状况，JVM并不是永远要求对象的年龄必须达到 MaxTenuringThreshold才能晋升老年代。
    • 如果在Survivor空间中相同年龄所有对象大小的总和大于Survivor空间的一半，年龄大于或等于该年龄的对象就可以直接进入老年代，无须等到MaxTenuringThreshold中要求的年龄。
  5. 空间分配担保:如果留空的S区空间不足存放GC后存活对象时，所有存活对象，通过分配担保机制，进入老年代

回收时机

Minor GC触发条件：
  • Eden空间不足，触发Minor GC：用户线程创建的对象优先分配在Eden区，当Eden区空间不够时，会触发Minor GC：将Eden和Survivor中还存活的对象一次性复制到另一块Survivor空间上，最后清理掉Eden和刚才用过的Survivor空间。

GC垃圾回收

  • 垃圾回收结束后，用户线程又开始新创建对象并分配在Eden区，当Eden区空间不足时，重复上次 的步骤进行Minor GC
Majar GC触发的条件：

在对象需要存放在老年代，而老年代空间不足，都会触发，包括：

  • 新生代年老对象晋升
  • Survivor空间不足，存活对象通过分配担保机制进入老年代
  • 老年代空间不足，触发Major GC
  • 还有一些特殊情况会触发垃圾回收，在垃圾收集器中进一步讨论。

垃圾收集的影响

  1. 用户线程的暂停：Stop-The-World（STW）：，在很多情况下，执行垃圾回收工作，或是执行垃圾回收其中 某一步骤时，需要暂停用户线程
  2. 评价垃圾回收器的指标：吞吐量和停顿时间
    • 吞吐量：CPU用于运行用户代码的时间与CPU总消耗时间的比值，即吞吐量=运行用户代码时间/ （运行用户代码时间+垃圾收集时间），虚拟机总共运行了100分钟，其中垃圾收集花掉1分钟，那吞吐量就是99%。
    • 用户体验优先：用户线程单次停顿时间短，即使总的停顿时间长一点也可以接受。
    • 吞吐量优先：用户线程总的停顿时间短，即使单次停顿时间长一点也可以接受。

垃圾收集器

Serial收集器（新生代收集器,串行GC）

特性：

  • 单线程
  • 复制算法
  • Stop The World（STW）

应用场景（了解）：

  • Client模式下的默认新生代收集器。

ParNew收集器（新生代收集器,并行GC）

Serial收集器的多线程版本，除了使用多条线程进行垃圾收集之外，其余行为包括Serial收集器可用的所 有控制参数、收集算法、Stop The World、对象分配规则、回收策略等都与Serial收集器完全一样，在实现上，这两种收集器也共用了相当多的代码。

特性：

  • 多线程
  • 复制算法
  • Stop The World（STW）

应用场景：

搭配CMS收集器，在用户体验优先的程序中使用：ParNew是运行在Server模式下的虚拟机中首选 的新生代收集器，其中有一个与性能无关但很重要的原因是，除了Serial收集器外，目前只有它能 与CMS收集器配合工作。

Parallel Scavenge收集器（新生代收集器,并行GC）

特性：

  1. 多线程
  2. 复制算法
  3. 可控制的吞吐量（Throughput）。Parallel Scavenge收集器提供了两个参数用于精确控制吞吐 量，分别是控制最大垃圾收集停顿时间的-XX：MaxGCPauseMillis参数以及直接设置吞吐量大小 的-XX：GCTimeRatio参数。
  4. 自适应的调节策略：Parallel Scavenge收集器有一个参数- XX:+UseAdaptiveSizePolicy 。当这个 参数打开之后，就不需要手工指定新生代的大小、Eden与Survivor区的比例、晋升老年代对象年 龄等细节参数了，虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整这些参数以提供 最合适的停顿时间或者最大的吞吐量，这种调节方式称为GC自适应的调节策略（GC Ergonomics）。

应用场景：

  • 吞吐量优先收集器，适用吞吐量需求高的任务型程序。

Serial Old收集器（老年代收集器，串行GC）

Serial Old是Serial收集器的老年代版本

特性：

  • 单线程
  • "标记-整理"算法

应用场景：

  • 给Client模式下的虚拟机使用。
  • 在Server模式下，那么它主要还有两大用途：
    1. 与Parallel Scavenge收集器搭配使用
    2. 作为CMS收集器的后备预案，在并发收集发生Concurrent Mode Failure时使用。

Parallel Old收集器（老年代收集器，并行GC）

Parallel Scavenge收集器的老年代版本。

特性：

  • 多线程
  • 标记-整理算法

应用场景

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

CMS收集器（老年代收集器，并发GC）

CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。

特性：

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

应用场景：

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

缺陷：

  1. CMS会抢占CPU资源。并发阶段虽然不会导致用户线程暂停，但却需要CPU分出精力去执行多条 垃圾收集线程，从而使得用户线程的执行速度下降。

  2. CMS无法处理浮动垃圾（Floating Garbage），可能会出现“Concurrent Mode Failure”而导致另一次Full GC：

    • 产生原因: CMS第四个阶段，用户线程并发执行又可能导致有对象进入老年代，而老年代也可能剩余空间不足，触发Major GC一Concurrent Mode Failure
    • 解决方案:使用Serial Old来进行垃圾回收

  3. 标记-清除算法会导致老年代空间碎片，如果进入的对象没有连续的可用空间，触发Full GC

总结

GC垃圾回收

相关推荐