谈谈 JVM 垃圾回收机制

jvm · 浏览次数 : 0

小编点评

**垃圾回收需要思考的三件事:** 1. **哪些内存需要回收JVM 的内存区域中?** - 程序计数器 - 虚拟机栈 -本地方法栈 2. **什么时候回收?** - 当方法或线程结束时,内存自然就跟着回收了。 3. **如何回收?** - 跟踪式垃圾回收:将内存分成多个区域,分别进行垃圾回收。 - 标记-整理算法:将所有存活对象向内存空间的一端移动,然后在清理掉边界以外的内存。

正文

前言


垃圾回收需要思考三件事情,哪些内存需要回收?什么时候回收?如何回收?


一、哪些内存需要回收


JVM 的内存区域中,程序计数器、虚拟机栈和本地方法栈的生命周期是随线程而生,随线程而灭的。这几个区域的内存分配和回收都具有确定性不需要过多考虑回收问题,当方法或线程结束时,内存自然就跟着回收了。


Java 堆和方法区是具有不确定性的,比如一个方法根据不同的条件执行可能需要的内存是不同的。只有处于运行期才能知道需要创建哪些对象,创建多少对象,这部分的内存分配和回收是动态的,垃圾回收所关注的就是这部分内存


二、对象何时会“死亡”


Java 堆中存放了几乎所有的对象实例,垃圾回收器在进行回收前,需要判断哪些对象“存活”,哪些对象“死亡”,“死亡”的对象才会被回收。


1. 引用计数法

给对象中添加一个引用计数器

  • 每当有一个地方引用它,计数器就加 1;
  • 当引用失效,计数器就减 1;
  • 任何时候计数器为 0 的对象就是不可能再被使用的。

这个方法实现简单,效率高,但是目前主流的虚拟机中并没有选择这个算法来管理内存,其最主要的原因是它很难解决对象之间相互循环引用的问题。

2. 可达性分析算法


通过一系列被称为GC Roots的根对象作为起始节点集,从这些节点开始,通过引用关系向下搜寻,搜寻走过的路径称为“引用链”,如果某个对象到GC Roots没有任何“引用链”相连,就说明该对象不可达,即可以被回收。


如下图,Object 5、Object 6、Object 7 虽有关联,但是到GC Roots是不可达的,因此会被判定“死亡”。

image.png


Java 中固定可作为GC Root对象的有:

  • 虚拟机栈的栈帧中的本地变量表中引用的对象,如,参数、局部变量、临时变量等。
  • 方法区中类静态属性引用的对象,如,类中的静态变量。
  • 方法区中常量引用的对象。
  • 本地方法栈中 JNI(也就是native方法)引用的对象。
  • Java 虚拟机内部的引用,如基本数据类型对应的 Class 对象、常驻异常、系统类加载器等。
  • 被同步锁持有的对象。

除了这些固定的还有一些临时性加入的,有兴趣的可以看下《深入理解 Java 虚拟机》。

上述两种方法都需要了解引用,详细介绍见Java引用

3. 方法区的回收

不要求虚拟机在方法区进行垃圾回收,在 Java 堆中,尤其是在新生代中,常规进行一次垃圾收集通常可以回收70%至99%的内存空间,相比之下,在方法区进行回收的“性价比”较低。该区域的垃圾回收主要是两个部分,废弃的常量和不再使用的类

3.1 废弃常量

假如在字符串常量池中曾存在字符串 "java",如果当前没有任何字符串对象引用该字符串常量的话,就说明常量 "java" 就是废弃常量,如果这时发生内存回收的话而且有必要的话,"java" 就会被系统清理出常量池了。

3.2 不再被使用的类

类需要同时满足下面 3 个条件才能算是 “不在被使用的类” :

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

三、垃圾回收算法

这里整理的均为“追踪式垃圾回收“,也成为”间接垃圾回收“。

1. 分代回收

Java 堆的区域划分如下图,被分为新生代、老年代、永久代或元空间,具体划分为五大块区域,不同的 GC 会针对不同的区域进行垃圾回收。

image.png

GC类型一般有以下几大类:

分类 说明
Minor GC 也称“Young GC”,只针对新生代进行的垃圾回收。
Major GC 也称“Old GC”,只针对老年代进行的垃圾回收
Mixed GC 针对新生代和部分老年代进行垃圾回收,部分垃圾收集器才支持。
Full GC 针对整个Java堆和方法区进行的垃圾回收,耗时最久的GC

2. 标记-清除算法

最早出现的垃圾回收算法,分为“标记”、“清除”两个阶段。可以标记存活的对象,也可以标记要回收的对象。
该算法有两个缺点:

  1. 是执行效率不稳定,随着对象的增多,标记效率会越来越低;
  2. 内存空间产生很多碎拼,浪费空间,分配大对象时可能需要重新触发垃圾回收。

标记-清除算法执行过程如下图:

image.png

3. 标记-复制算法

简称复制算法,为了解决标记-清除算法面对大量可回收对象执行效率低的问题,就是将内存分成两个区域,每次只使用其中一个区域,当该区域内存满了之后,会将还存活的对象复制到另一个区域,然后将原区域直接清理掉
该算法有两个缺点:

  1. 对象存活率过多时,会影响复制的效率;
  2. 一半内存不使用,浪费了大量空间。

标记-复制算法执行过程如下图:

image.png

由于 Java 的新生代对象存活率不高,所以一般针对新生代的垃圾回收使用标记-复制算法


如下图,将新生代分为内存较大的Eden,和两块内存较小的Survivor。每次分配内存只使用Eden和其中一个Survivor,我们假设第一次分配内存是EdenSurvivor 0

  1. 发生 GC 时,将使用的EdenSurvivor 0中存活的对象一次性复制到Survivor 1中,然后清理掉EdenSurvivor 0内存。
  2. 这时分配的内存就变成了EdenSurvivor 1,周而复始。

注意:Survivor不足以容纳轻 GC 之后的对象时,就需要依赖老年代来进行内存分配了

image.png

4. 标记-整理算法

标记完存活对象以后,让所有存活对象都向内存空间的一端移动,然后在清理掉边界以外的内存。

标记-整理算法执行过程如下图:

image.png

这种涉及到了对象的移动,如果移动存活对象,尤其是老年代这种每次回收都有大量对象存活的区域,会耗时很多,并且对象移动操作会全部暂停用户应用程序才能进行,这样会产生停顿时间。

这种停顿被称为Stop The World

5. 标记-清除-整理算法

先使用标记-清除算法进行垃圾回收,暂时容忍内存碎片的存在,直到碎片过多影响对象分配时,在进行标记-整理算法进行回收,获得规整空间。

四、经典垃圾收集器


下图展示了 7 种经典垃圾收集器,若两两出现互连情况,则表明两者它们可以搭配使用

  • 单线程收集器 Serial、Serial old
  • 并行收集器 Par New、Parallel Scavenge、Parallel old
  • 并发收集器 CMS、G1

image.png

1. Serial 收集器

最基本、历史最早的垃圾收集器了。单线程的收集器,收集垃圾时,必须暂停其他所有工作线程,也就是必有停顿,使用复制算法

2. Par New 收集器

多线程并行版本的 Serial 收集器,收集垃圾时,必须暂停其他所有工作线程,也就是必有停顿,使用复制算法

3. Parallel Scavenge 收集器

类似 Par New 收集器,但关注点是达到一个可控的吞叶量,使用复制算法


吞吐量公式:



吞吐量示例:

代码运行 95 秒 , 垃圾收集器运行 5 秒 , 那么吞吐量就是 $\frac{95}{95 + 5} = 0.95$

4. Serial old 收集器

Serial 收集器的老年代版本,单线程收集器,使用标记-整理算法。它主要有两大用途:

  1. 在JDK1.5及以前的版本中与 Parallel Scavenge 收集器搭配使用;
  2. 作为CMS收集器的后备方案。

5. Parallel old 收集器

Parallel Scavenge收集器的老年代版本。使用多线程和标记-整理算法。在注重吞吐量以及CPU资源的场合,都可以优先考虑 Parallel Scavenge收集器和Parallel Old收集器(JDK8默认的新生代和老年代收集器)。

6. CMS 收集器

是一种以获取最短回收停顿时间为目标的收集器。它非常符合在注重用户体验的应用上使用,它是HotSpot虚拟机第一款真正意义上的并发收集器,它第一次实现了让垃圾收集线程与用户线程(基本上)同时工作。


整个过程分为5个步骤:初始标记→并发标记→重新标记→并发清理→并发重置。

7. G1 收集器

基于标记整理算法实现,运作流程主要包括以下:初始标→并发标记→最终标记→筛选回收,不会产生空间碎片,可以精确地控制停顿,可以支持用户设置期望停顿时间。


不追求一次性将 Java 堆清理干净,只要垃圾收集的速度赶得上对象分配的速度即可。



参考:

[1] 周志明. 深入理解 Java 虚拟机(第3版).

与谈谈 JVM 垃圾回收机制相似的内容:

谈谈 JVM 垃圾回收机制

前言 垃圾回收需要思考三件事情,哪些内存需要回收?什么时候回收?如何回收? 一、哪些内存需要回收 JVM 的内存区域中,程序计数器、虚拟机栈和本地方法栈的生命周期是随线程而生,随线程而灭的。这几个区域的内存分配和回收都具有确定性,不需要过多考虑回收问题,当方法或线程结束时,内存自然就跟着回收了。 J

谈JVM参数GC线程数ParallelGCThreads合理性设置

作者:京东零售 刘乐 导读:本篇文章聚焦JVM参数GC线程数的合理配置,从ParallelGCThreads参数含义、参数设置,到参数实验以及修改意见进行解析。 1. ParallelGCThreads参数含义 在讲这个参数之前,先谈谈JVM垃圾回收(GC)算法的两个优化标的:吞吐量和停顿时长。JV

[转帖]谈 JVM 参数 GC 线程数 ParallelGCThreads 合理性设置

https://my.oschina.net/u/4090830/blog/7926038 1. ParallelGCThreads 参数含义 在讲这个参数之前,先谈谈 JVM 垃圾回收 (GC) 算法的两个优化标的:吞吐量和停顿时长。JVM 会使用特定的 GC 收集线程,当 GC 开始的时候,GC

[转帖]谈谈Service与Ingress

https://zhuanlan.zhihu.com/p/596889677 你好,我是张磊。今天我和你分享的主题是:谈谈Service与Ingress。 在上一篇文章中,我为你详细讲解了将Service暴露给外界的三种方法。其中有一个叫作LoadBalancer类型的Service,它会为你在Cl

[转帖]谈谈对K8S CNI、CRI和CSI插件的理解

K8S的设计初衷就是支持可插拔架构,解决PaaS平台不好用、不能用、需要定制化等问题,K8S集成了插件、附加组件、服务和接口来扩展平台的核心功能。附加组件被定义为与环境的其他部分无缝集成的组件,提供类似本机的特性,并扩展集群管理员可用的组件,扩展还可以用于添加自定义软硬件的支持;服务和接口提供了看似

[转帖]谈谈ClickHouse性能情况以及相关优化

https://zhuanlan.zhihu.com/p/349105024 ClickHouse性能情况 主要分为4个方面 1、单个查询吞吐量 场景一: 如果数据被放置在page cache中,则一个不太复杂的查询在单个服务器上大约能够以2-10GB/s(未压缩)的速度进行处理(对于简单的查询,速

谈谈Selenium中的三种切换之alert

谈谈Selenium中的三种切换之alert 一、如何识别 识别方法:alert中的确定、取消、输入框无法用inspector定位到,当然还有一些特例。 alert分为三种 alert confirm prompt 分别对应3个js的命令(可在chrome的console面板中调试) alert('

谈谈Selenium中浏览器驱动的日志

谈谈Selenium中浏览器驱动的日志 来源于一位同学,“老师为啥firefox执行后会有日志文件,chrome没有呢?” 比对 你打开chrome浏览器 from selenium import webdriver driver = webdriver.Chrome() 这样是没有日志的 同样的代

谈谈JSF业务线程池的大小配置

本文旨在通过一个简化场景(“单服务应用”)下的负载测试,为“JSF业务线程池大小配置”提供基准测试结果,并形成一些普遍适用的结论。

谈谈分布式事务原理

分布式系统中,不同服务之间的交互可能会出现各种问题,如网络、异常等,可能会导致服务间的数据产生不一致的情况,如何避免?本文将详细讲述分布式事务的原理和解决方案。