4、jvm-垃圾收集算法与垃圾收集器

垃圾收集算法

分代收集理论

        当前虚拟机的垃圾收集都采用分代收集算法，这种算法没有什么新的思想，只是根据对象存活周期的不同将内存分为几块。一般将java堆分为新生代和老年代，这样我们就可以根据各个年代的特点选择合适的垃圾收集算法。

        比如在新生代中，每次收集都会有大量对象(近99%)死去，所以可以选择复制算法，只需要付出少量对象的复制成本就可以完成每次垃圾收集。而老年代的对象存活几率是比较高的，而且没有额外的空间对它进行分配担保，所以我们必须选择“标记-清除”或“标记-整理”算法进行垃圾收集。注意，“标记-清除”或“标记-整理”算法会比复制算法慢10倍以上。

标记-复制算法

        为了解决效率问题，“复制”收集算法出现了。它可以将内存分为大小相同的两块，每次使用其中的一块。当这一块的内存使用完后，就将还存活的对象复制到另一块去，然后再把使用的空间一次清理掉。这样就使每次的内存回收都是对内存区间的一半进行回收。

标记-清除算法

        算法分为“标记”和“清除”阶段：标记存活的对象， 统一回收所有未被标记的对象(一般选择这种)；也可以反过来，标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象 。它是最基础的收集算法，比较简单，但是会带来两个明显的问题：        

  1. 效率问题 (如果需要标记的对象太多，效率不高)
  2. 空间问题（标记清除后会产生大量不连续的碎片）

标记-整理算法

        根据老年代的特点特出的一种标记算法，标记过程仍然与“标记-清除”算法一样，但后续步骤不是直接对可回收对象回收，而是让所有存活的对象向一端移动，然后直接清理掉端边界以外的内存。

垃圾收集器

        如果说收集算法是内存回收的方法论，那么垃圾收集器就是内存回收的具体实现。

        虽然我们对各个收集器进行比较，但并非为了挑选出一个最好的收集器。因为直到现在为止还没有最好的垃圾收集器出现，更加没有万能的垃圾收集器，我们能做的就是根据具体应用场景选择适合自己的垃圾收集器。试想一下：如果有一种四海之内、任何场景下都适用的完美收集器存在，那么我们的Java虚拟机就不会实现那么多不同的垃圾收集器了。

1.1 Serial收集器

(-XX:+UseSerialGC -XX:+UseSerialOldGC)

        Serial（串行）收集器是最基本、历史最悠久的垃圾收集器了。大家看名字就知道这个收集器是一个单线程收集器了。它的 “单线程” 的意义不仅仅意味着它只会使用一条垃圾收集线程去完成垃圾收集工作，更重要的是它在进行垃圾收集工作的时候必须暂停其他所有的工作线程（ "Stop The World" ），直到它收集结束。

        新生代采用复制算法，老年代采用标记-整理算法。

虚拟机的设计者们当然知道Stop The World带来的不良用户体验，所以在后续的垃圾收集器设计中停顿时间在不断缩短（仍然还有停顿，寻找最优秀的垃圾收集器的过程仍然在继续）。

        但是Serial收集器有没有优于其他垃圾收集器的地方呢？当然有，它简单而高效（与其他收集器的单线程相比）。Serial收集器由于没有线程交互的开销，自然可以获得很高的单线程收集效率。

        Serial Old收集器是Serial收集器的老年代版本，它同样是一个单线程收集器。它主要有两大用途：一种用途是在JDK1.5以及以前的版本中与Parallel Scavenge收集器搭配使用，另一种用途是作为CMS收集器的后备方案。

1.2 Parallel Scavenge收集器

(-XX:+UseParallelGC(年轻代),-XX:+UseParallelOldGC(老年代))

        Parallel收集器其实就是Serial收集器的多线程版本，除了使用多线程进行垃圾收集外，其余行为（控制参数、收集算法、回收策略等等）和Serial收集器类似。默认的收集线程数跟cpu核数相同，当然也可以用参数(-XX:ParallelGCThreads)指定收集线程数，但是一般不推荐修改。

        Parallel Scavenge收集器关注点是吞吐量（高效率的利用CPU）。CMS等垃圾收集器的关注点更多的是用户线程的停顿时间（提高用户体验）。所谓吞吐量就是CPU中用于运行用户代码的时间与CPU总消耗时间的比值。 Parallel Scavenge收集器提供了很多参数供用户找到最合适的停顿时间或最大吞吐量，如果对于收集器运作不太了解的话，可以选择把内存管理优化交给虚拟机去完成也是一个不错的选择。

        新生代采用复制算法，老年代采用标记-整理算法。

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

1.3 ParNew收集器

(-XX:+UseParNewGC)

ParNew收集器其实跟Parallel收集器很类似，区别主要在于它可以和CMS收集器配合使用。

新生代采用复制算法

它是许多运行在Server模式下的虚拟机的首要选择，除了Serial收集器外，只有它能与CMS收集器（真正意义上的并发收集器，后面会介绍到）配合工作。

1.4 CMS收集器

(-XX:+UseConcMarkSweepGC(old))

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

        从名字中的Mark Sweep这两个词可以看出，CMS收集器是一种 “标记-清除”算法实现的，它的运作过程相比于前面几种垃圾收集器来说更加复杂一些。整个过程分为四个步骤：

  • 初始标记： 暂停所有的其他线程(STW)，并记录下gc roots直接能引用的对象，速度很快。
  • 并发标记： 并发标记阶段就是从GC Roots的直接关联对象开始遍历整个对象图的过程， 这个过程耗时较长但是不需要停顿用户线程， 可以与垃圾收集线程一起并发运行。因为用户程序继续运行，可能会有导致已经标记过的对象状态发生改变。
  • 重新标记： 重新标记阶段就是为了修正并发标记期间因为用户程序继续运行而导致标记产生变动的那一部分对象的标记记录(主要是处理漏标问题)，这个阶段的停顿时间一般会比初始标记阶段的时间稍长，远远比并发标记阶段时间短。主要用到三色标记里的增量更新算法(见下面详解)做重新标记。
  • 并发清理： 开启用户线程，同时GC线程开始对未标记的区域做清扫。这个阶段如果有新增对象会被标记为黑色不做任何处理(见下面三色标记算法详解)。
  • 并发重置：重置本次GC过程中的标记数据。

从它的名字就可以看出它是一款优秀的垃圾收集器，主要优点：并发收集、低停顿。但是它有下面几个明显的缺点：

  • 对CPU资源敏感（会和服务抢资源）；
  • 无法处理浮动垃圾(在并发标记和并发清理阶段又产生垃圾，这种浮动垃圾只能等到下一次gc再清理了)；
  • 它使用的回收算法-“标记-清除”算法会导致收集结束时会有大量空间碎片产生，当然通过参数-XX:+UseCMSCompactAtFullCollection可以让jvm在执行完标记清除后再做整理
  • 执行过程中的不确定性，会存在上一次垃圾回收还没执行完，然后垃圾回收又被触发的情况，特别是在并发标记和并发清理阶段会出现，一边回收，系统一边运行，也许没回收完就再次触发full gc，也就是"concurrent mode failure"，此时会进入stop the world，用serial old垃圾收集器来回收

CMS的相关核心参数

  1. -XX:+UseConcMarkSweepGC：启用cms 
  2. -XX:ConcGCThreads：并发的GC线程数
  3. -XX:+UseCMSCompactAtFullCollection：FullGC之后做压缩整理（减少碎片）
  4. -XX:CMSFullGCsBeforeCompaction：多少次FullGC之后压缩一次，默认是0，代表每次FullGC后都会压缩一次
  5. -XX:CMSInitiatingOccupancyFraction: 当老年代使用达到该比例时会触发FullGC（默认是92，这是百分比）
  6. -XX:+UseCMSInitiatingOccupancyOnly：只使用设定的回收阈值(-XX:CMSInitiatingOccupancyFraction设定的值)，如果不指定，JVM仅在第一次使用设定值，后续则会自动调整
  7. -XX:+CMSScavengeBeforeRemark：在CMS GC前启动一次minor gc，降低CMS GC标记阶段(也会对年轻代一起做标记，如果在minor gc就干掉了很多对垃圾对象，标记阶段就会减少一些标记时间)时的开销，一般CMS的GC耗时 80%都在标记阶段
  8. -XX:+CMSParallellnitialMarkEnabled：表示在初始标记的时候多线程执行，缩短STW
  9. -XX:+CMSParallelRemarkEnabled：在重新标记的时候多线程执行，缩短STW;

对于8G内存，我们一般是分配4G内存给JVM，正常的JVM参数配置如下：

-Xms3072M -Xmx3072M -Xss1M -XX:MetaspaceSize=256M -XX:MaxMetaspaceSize=256M  -XX:SurvivorRatio=8

上节课说过，这样设置可能会由于动态对象年龄判断原则导致频繁full gc。

于是我们可以更新下JVM参数设置：

-Xms3072M -Xmx3072M -Xmn2048M -Xss1M -XX:MetaspaceSize=256M -XX:MaxMetaspaceSize=256M  -XX:SurvivorRatio=8

0

        这样就降低了因为对象动态年龄判断原则导致的对象频繁进入老年代的问题，其实很多优化无非就是让短期存活的对象尽量都留在survivor里，不要进入老年代，这样在minor gc的时候这些对象都会被回收，不会进到老年代从而导致full gc。

        对于对象年龄应该为多少才移动到老年代比较合适，本例中一次minor gc要间隔二三十秒，大多数对象一般在几秒内就会变为垃圾，完全可以将默认的15岁改小一点，比如改为5，那么意味着对象要经过5次minor gc才会进入老年代，整个时间也有一两分钟了，如果对象这么长时间都没被回收，完全可以认为这些对象是会存活的比较长的对象，可以移动到老年代，而不是继续一直占用survivor区空间。

        对于多大的对象直接进入老年代(参数-XX:PretenureSizeThreshold)，这个一般可以结合你自己系统看下有没有什么大对象生成，预估下大对象的大小，一般来说设置为1M就差不多了，很少有超过1M的大对象，这些对象一般就是你系统初始化分配的缓存对象，比如大的缓存List，Map之类的对象。

可以适当调整JVM参数如下：

-Xms3072M -Xmx3072M -Xmn2048M -Xss1M  -XX:MetaspaceSize=256M -XX:MaxMetaspaceSize=256M  -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=5 -XX:PretenureSizeThreshold=1M

        对于JDK8默认的垃圾回收器是-XX:+UseParallelGC(年轻代)和-XX:+UseParallelOldGC(老年代)，如果内存较大(超过4个G，只是经验值)，系统对停顿时间比较敏感，我们可以使用ParNew+CMS(-XX:+UseParNewGC -XX:+UseConcMarkSweepGC)

        对于老年代CMS的参数如何设置我们可以思考下，首先我们想下当前这个系统有哪些对象可能会长期存活躲过5次以上minor gc最终进入老年代。

        无非就是那些Spring容器里的Bean，线程池对象，一些初始化缓存数据对象等，这些加起来充其量也就几十MB。

        还有就是某次minor gc完了之后还有超过一两百M的对象存活，那么就会直接进入老年代，比如突然某一秒瞬间要处理五六百单，那么每秒生成的对象可能有一百多M，再加上整个系统可能压力剧增，一个订单要好几秒才能处理完，下一秒可能又有很多订单过来。

        我们可以估算下大概每隔五六分钟出现一次这样的情况，那么大概半小时到一小时之间就可能因为老年代满了触发一次Full GC，Full GC的触发条件还有我们之前说过的老年代空间分配担保机制，历次的minor gc挪动到老年代的对象大小肯定是非常小的，所以几乎不会在minor gc触发之前由于老年代空间分配担保失败而产生full gc，其实在半小时后发生full gc，这时候已经过了抢购的最高峰期，后续可能几小时才做一次FullGC。

        对于碎片整理，因为都是1小时或几小时才做一次FullGC，是可以每做完一次就开始碎片整理，或者两到三次之后再做一次也行。

        综上，只要年轻代参数设置合理，老年代CMS的参数设置基本都可以用默认值，如下所示：

-Xms3072M -Xmx3072M -Xmn2048M -Xss1M  -XX:MetaspaceSize=256M -XX:MaxMetaspaceSize=256M  -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=5 -XX:PretenureSizeThreshold=1M -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=92 -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=3

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.rhkb.cn/news/307994.html

如若内容造成侵权/违法违规/事实不符，请联系长河编程网进行投诉反馈email:809451989@qq.com，一经查实，立即删除！

相关文章

最新Zibll子比主题V7.1版本源码 全新推出开心版

最新Zibll子比主题V7.1版本源码 全新推出开心版

源码下载地址：Zibll子比主题V7.1.zip
阅读更多...
JavaEE实验三：3.5学生信息查询系统（动态Sql）

JavaEE实验三：3.5学生信息查询系统（动态Sql）

题目要求: 使用动态SQL进行条件查询、更新以及复杂查询操作。本实验要求利用本章所学知识完成一个学生信息系统，该系统要求实现3个以下功能: 1、多条件查询： 当用户输入的学生姓名不为空，则根据学生姓名进行学生信息的查询； 当用户…
阅读更多...
搭建基于Hexo的个人博客，以及git相关命令

搭建基于Hexo的个人博客，以及git相关命令

全文写完之后的总结 测试命令 hexo clean hexo g hexo s 上传到服务器命令 hexo clean hexo g hexo d 上传到服务器（如果上一个命令用不了），也要先hexo clean,hexo g git init git add . git commit -m "first commit" git p…
阅读更多...
jenkins下载安装（mac）

jenkins下载安装（mac）

下载官网 具体 直接命令安装 Sample commands: Install the latest LTS version: brew install jenkins-ltsStart the Jenkins service: brew services start jenkins-ltsRestart the Jenkins service: brew services restart jenkins-ltsUpdate the Jenkins version: brew u…
阅读更多...
在Linux上利用mingw-w64生成exe文件

在Linux上利用mingw-w64生成exe文件

一、概要 1、elf与exe 在Linux上用gcc直接编译出来的可执行文件是elf格式的，在Windows上是不能运行的 Windows上可执行文件的格式是exe 利用mingw-w64可以在Linux上生成exe格式的可执行文件，将该exe文件拷贝到Windows上就可以运行 2、程序要留给用户…
阅读更多...
数据结构——单链表（C语言版）

数据结构——单链表（C语言版）

文章目录 一、链表的概念及结构二、单链表的实现SList.h链表的打印申请新的结点链表的尾插链表的头插链表的尾删链表的头删链表的查找在指定位置之前插入数据在指定位置之后插入数据删除pos结点删除pos之后的结点销毁链表 三、完整源代码SList.hSList.ctest.c 一、链表的概念及…
阅读更多...
PVE下安装配置openwrt和ikuai

PVE下安装配置openwrt和ikuai

开端 openwrt 和 ikuai 是比较出名的软路由系统。我最早接触软路由还是因为我的一个学长要改自己家里的网络，使用软路由去控制网络。我听说后便来了兴致，也在我家搞了一套软路由系统。现在我已经做完了，就想着写个文章记录一下。 软路由简介…
阅读更多...
Flutter中间镂空的二维码扫描控件

Flutter中间镂空的二维码扫描控件

1、UI效果图&#xff1a; 2、中间镂空UI&#xff1a; class CenterTransparentMask extends CustomClipper<Path> {final double? width;CenterTransparentMask({this.width});overridePath getClip(Size size) {final path Path()..addRect(Rect.fromLTWH(0, 0, size…
阅读更多...
Navicat Premium 16 for Mac/Win：数据库管理的全能之选

Navicat Premium 16 for Mac/Win：数据库管理的全能之选

在数字化时代&#xff0c;数据库管理已成为各行各业不可或缺的一环。而Navicat Premium 16作为一款功能强大的数据库管理软件&#xff0c;无疑为数据库管理员和开发者提供了高效、便捷的解决方案。 Navicat Premium 16支持多种主流数据库系统&#xff0c;无论是MySQL、Postgre…
阅读更多...
MyBatis批量插入的五种方式

MyBatis批量插入的五种方式

MyBatis批量插入的五种方式: 一、准备工作 1、导入pom.xml依赖 <dependencies><dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-web</artifactId></dependency><!-- MySQL驱动依赖 --…
阅读更多...
R：普通分组柱状图

R：普通分组柱状图

输入文件实例&#xff08;存为csv格式&#xff09; library(ggplot2) library(ggbreak)# 从CSV文件中读取数据 setwd("C:/Users/fordata/Desktop/研究生/第二个想法(16s肠型&#xff0b;宏基因组功能)/第二篇病毒组/result/otherDB") data <- read.csv("feta…
阅读更多...
UI自动化测试案例

UI自动化测试案例

备注：本文为博主原创文章，未经博主允许禁止转载。如有问题，欢迎指正。 个人笔记（整理不易，有帮助，收藏+点赞+评论，爱你们！！！你的支持是我写作的动力） 笔记目录：笔记本~笔记目录_airtest和selenium那个好用-CSDN博客 个人随笔：工作总结随笔_8、以前工作中都接触过哪…
阅读更多...
工厂方法模式：解锁灵活的对象创建策略

工厂方法模式：解锁灵活的对象创建策略

在软件设计中&#xff0c;工厂方法模式是一种非常实用的创建型设计模式&#xff0c;它不仅提升了系统的灵活性&#xff0c;还简化了对象的创建过程。本文将详细探讨工厂方法模式的核心概念、实现方式、应用场景以及与其他设计模式的对比&#xff0c;旨在提供一份全面且实用的指…
阅读更多...
K8s 命令行工具

K8s 命令行工具

文章目录 K8s 命令行工具kubectl 工具在任意节点使用kubectl方式创建对象命令显示和查找资源更新资源修补资源编辑资源Scale 资源删除资源查看pod信息节点相关操作 K8s 命令行工具 在搭建集群的时候&#xff0c;我们通过yum 下载了kubeadm kubelet kubectl 三个命令行工具&…
阅读更多...
通过本机调试远端路由器非直连路由

通过本机调试远端路由器非直连路由

实验目的&#xff1a;如图拓扑&#xff0c;通过本机电脑发&#xff0c;telnet调试远程AR4设备。 重点1&#xff1a;通过ospf路由协议配置拓扑网络&#xff0c;知识点&#xff1a;ospf配置路由器协议语法格式&#xff0c;area区域的定义&#xff0c;区域内网络的配置&#xff0…
阅读更多...
量子信息产业生态研究（一）：关于《量子技术公司营销指南（2023）》的讨论

量子信息产业生态研究（一）：关于《量子技术公司营销指南（2023）》的讨论

写在前面。量子行业媒体量子内参&#xff08;Quantum Insider&#xff09;编制的《量子技术公司营销指南》是一本实用的英文手册&#xff0c;它旨在帮助量子科技公司建立有效的营销策略&#xff0c;同时了解如何将自己定位成各自的行业专家。本文对这篇指南的主要内容进行了翻译…
阅读更多...
4. Django 探究FBV视图

4. Django 探究FBV视图

4. 探究FBV视图 视图(Views)是Django的MTV架构模式的V部分, 主要负责处理用户请求和生成相应的响应内容, 然后在页面或其他类型文档中显示. 也可以理解为视图是MVC架构里面的C部分(控制器), 主要处理功能和业务上的逻辑. 我们习惯使用视图函数处理HTTP请求, 即在视图里定义def…
阅读更多...
react17+antd4 动态渲染导航菜单中的icon

react17+antd4 动态渲染导航菜单中的icon

在路由信息对照表中的icon可以有两种形式&#xff1a;一种是组件形式&#xff0c;一种是字符串形式的。 在antd4的Menu.Item和SubMenu中的icon属性的格式为&#xff1a; 1.组件形式 这种方法在渲染时很方便&#xff0c;与antd中的Menu.Item中的icon属性的形式是一致的&#…
阅读更多...
微信小程序全屏开屏广告

微信小程序全屏开屏广告

效果图 代码 <template><view><!-- 自定义头部 --><u-navbar title" " :bgColor"bgColor"><view class"u-nav-slot" slot"left"><view class"leftCon"><view class"countDown…
阅读更多...
MySQL-进阶篇-一条sql更新语句是如何执行的（redo log和binlog）

MySQL-进阶篇-一条sql更新语句是如何执行的（redo log和binlog）

上一篇&#xff1a;一条sql查询语句是如何执行的 http://t.csdnimg.cn/nV3EY 摘自&#xff1a;林晓斌MySQL实战45讲——第二篇 更新语句的执行过程与上一篇查询流程相同&#xff0c;本篇简写。 但多了两个重要的日志模块&#xff1a;redo log&#xff08;重做日志&#xff0…
阅读更多...
最新文章
推荐文章

Copyright @ 2022~2023