回首掏-JVM垃圾收集器

最新推荐文章于 2022-06-01 20:45:39 发布
最新推荐文章于 2022-06-01 20:45:39 发布
阅读量997 收藏
点赞数 1
分类专栏： JVM java 文章标签： java jvm
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_41257365/article/details/106764834
版权
java 同时被 2 个专栏收录
26 篇文章 0 订阅
订阅专栏
JVM
4 篇文章 0 订阅
订阅专栏
本文详细解析了JVM中的多种垃圾回收器，包括Serial、SerialOld、ParNew、ParallelScavenge、ParallelOld、CMS及G1，探讨了它们的工作原理、优缺点以及适用场景，特别关注了STW问题和CMS收集器的特点。
摘要由CSDN通过智能技术生成

回首掏-JVM垃圾收集器

本文将对下面几种GC回收器进行讲解，前面几个会简单的讲一下，后面两个会重点说的。
要是哪里有错误的地方，一定要指出哦，嘻嘻

  • Serial
  • Serial Old
  • ParNew
  • Parallel Scavenge
  • Parallel Old
  • CMS
  • G1
  • …

首先，我们来了解一下这几种收集器的原理、优缺点和相应的解决方法
STW就是Stop The World
新生代为啥选择复制算法，而老年代不选：

因为在新生代绝大多数的内存都是会被回收的，所以留下来的不需要回收的就很少了，所以复制算法更合适，而老年代中对象基本是比较大的，比如数组啥的，它们复制的开销比较大，不适合选择复制算法，而选择标记-整理、标记-清除算法是比较好的选择。

1、Serial

Serial收集器是发展最久的垃圾回收器，Serial单词本身的意思是“串行”。

  • 是一个单线程的收集器
  • 作用于新生代
  • 采用复制算法
  • 在进行垃圾回收的时候会产生STW

主要适用于单CPU环境下的Client模式，目标是追求响应速度优先，可以避免多线程上下文切换带来的消耗

2、Serial Old

Serial的老年代版本。

  • 即与Serial一样，采用单线程垃圾回收
  • 不同的是采用的标记-整理算法
  • 进行垃圾回收时会产生STW
  • 作用于老年代

主要适用于单CPU环境下的Client模式、CMS的后备预案，目标是追求响应速度优先

3、ParNew

ParNew是Serial的多线程版本。

  • 即使用多线程并行进行垃圾回收
  • 作用于新生代
  • 采用复制算法
  • 进行垃圾回收时会产生STW

主要适用于多CPU环境时在Server模式下与CMS配合，目标是追求响应速度优先

4、Parallel Scavenge

Parallel Scavenge与ParNew类似，只是关注点不同。Parallel Scavenge主要关注

  • 吞吐量。吞吐量 = 运行用户代码时间 / (运行用户代码时间 + 垃圾收集时间)。提供了两个参数来控制吞吐量

-XX:MaxGCPauseMillis 控制最大垃圾收集停顿时间，大于0的毫秒数
-XX:GCTimeRatio 设置吞吐量大小，大于0且小于100的整数，即垃圾收集时间占总时间的比率

  • 使用多线程并行进行垃圾回收
  • 作用于新生代
  • 采用复制算法
  • 进行垃圾回收时会产生STW

Parallel Scavenge收集器的目标是达到一个可控制的吞吐量（Throughput）
我们知道，停顿时间越短就越适合需要与用户交互的程序，良好的响应速度能提升用户体验。
而高吞吐量则可以高效率地利用CPU时间，尽快完成程序的计算任务，主要适合在后台计算而不需要过多交互的任务。
主要适用于在后台运算而不需要太多交互的任务，目标是追求吞吐量优先

5、Parallel Old

Parallel Old是Parallel Scavenge的老年代版本

  • 多线程并行收集
  • 使用标记-整理算法
  • 作用于老年代
  • 进行垃圾回收时会产生STW

主要适用于在后台运算而不需要太多交互的任务，目标是追求吞吐量优先 ，JDK8中默认的选择是"-XX:+UseParallelGC"，是 Parallel Scavenge + Parallel Old组合。

6、CMS（Concurrent Mark Sweep）

  • 以获取最短回收停顿时间为目标
  • 作用于老年代
  • 使用标记-清除算法
  • 会产生空间碎片，但可以通过配置 -XX:+UseCmsCompactAtFullCollection （默认已开启）用于在CMS收集器要进行FullGC时开启内存碎片的整理

CMS特点： 并发收集，低停顿。

它的标记-清除算法过程：

  1. 初始标记，会导致STW；
  2. 并发标记，与用户线程同时运行；
  3. 预清理，与用户线程同时运行；
  4. 可被终止的预清理，与用户线程同时运行；
  5. 重新标记 ，会导致STW；
  6. 并发清除，与用户线程同时运行；

其实只要关注四个就差不多了，简单点就是：

  • 初始标记：只标记GC Roots直接关联到的对象，速度快，需要“Stop The World”。
  • 并发标记：根据GC Roots标记的对象进行追踪，标记出需要回收的对象。过程较长，但GC线程与用户线程并发执行，不产生 STW
  • 重新标记：修复并发标记过程中用户程序的运行导致标记的对象产生变动的的那部分对象，会产生STW
  • 并发清除：清除标记的对象，与用户线程并发执行，不产生STW

这里介绍一下一般可以作为GC Roots的对象是什么

虚拟机栈（栈帧中的局部变量表，Local Variable Table）中引用的对象
方法区中类静态属性引用的对象
方法区中常量引用的对象
本地方法栈中（native方法）引用的对象

上图从https://my.oschina.net/u/4349287/blog/3225344中来

CMS缺点：

  • 垃圾碎片的问题，我们都知道CMS是使用的是标记-清除算法的，所以不可避免的会出现垃圾碎片的问题
  • 一般CMS的GC耗时80%都在remark阶段，remark阶段停顿时间会很长，在CMS的这四个主要的阶段中，最费时间的就是重新标记阶段。
  • concurrent mode failure: 也就是CMS收集器无法处理浮动垃圾(Floating Garbage)产生的， 这个异常发生在CMS正在回收的时候。执行CMS GC的过程中，同时业务线程也在运行，当年轻带空间满了，执行Young GC时，需要将存活的对象放入到老年代，而此时老年代空间不足，这时CMS还没有机会回收老年带产生的，或者在做Minor GC的时候，新生代救助空间放不下，需要放入老年代，而老年代也放不下而产生的。这时虚拟机可能就会启动后备预案，临时启用Serial Old收集老年代，这样停顿时间很长。

由于CMS并发清理时，用户线程还在运行，伴随产生新的垃圾，而这一部分垃圾出现在标记之后，只能下次GC时再清理。这一部分垃圾就称为”浮动垃圾“。

  • promotion failed： 在进行Minor GC时，Survivor空间不足，对象只能放入老年代，而此时老年代也放不下造成的，多数是由于老年代有足够的空闲空间，但是由于碎片较多，新生代要转移到老年带的对象比较大,找不到一段连续区域存放这个对象导致的
    CMS收集器对CPU资源非常敏感： 默认启动的回收线程数是(CPU+3)/4. 当CPU 4个以上时，并发回收垃圾收集线程不少于25%的CPU资源。
    解决办法：

  • 垃圾碎片的问题： 针对这个问题，这时候我们需要用到这个参数： -XX:CMSFullGCsBeforeCompaction=n 意思是说在上一次CMS并发GC执行过后，到底还要再执行多少次 full GC才会做压缩。默认是0，也就是在默认配置下每次CMS GC顶不住了而要转入full GC的时候都会做压缩，开启内存碎片合并整理，内存整理过程是无法并发的，空间碎片问题没了，但停顿时间变长。

  • concurrent mode failure： 只需要设置两个参数即可

-XX:+UseCMSInitiatingOccupancyOnly
-XX:CMSInitiatingOccupancyFraction=60：是指设定CMS在对内存占用率达到60%的时候开始GC。G1中也有个类似的。
由于在垃圾收集阶段用户线程还需要运行，那也就还需要预留有足够的内存空间给用户线程使用，因此CMS收集器不能像其他收集器那样等到老年代几乎完全被填满了再进行收集。
当然也不能设置过高，比如90%，这时候虽然GC次数少，但是，却会导致用于用户线程空间小，效率不高，太低10%，你自己想想会怎么样，体会体会！

  • remark阶段停顿时间会很长的问题： 解决这个问题巨简单，加入 -XX:+CMSScavengeBeforeRemark。在执行remark操作之前先做一次 Young GC，目的在于减少年轻代对老年代的无效引用，降低remark时的开销

CMS什么时候FUll GC

  1. 旧生代空间不足

1.在新生代对象转入及创建为大对象、大数组时才会出现不足的现象
2.当执行Full GC后空间仍然不足，则抛出如下错误：java.lang.OutOfMemoryError: Java heap space
为避免以上两种状况引起的FullGC，调优时应尽量做到让对象在Minor GC阶段被回收、让对象在新生代多存活一段时间及不要创建过大的对象及数组。

  1. Permanet Generation空间满

PermanetGeneration中存放的为一些class的信息等，当系统中要加载的类、反射的类和调用的方法较多时，Permanet Generation可能会被占满，在未配置为采用CMS GC的情况下会执行Full GC。如果经过Full GC仍然回收不了，那么JVM会抛出如下错误信息：java.lang.OutOfMemoryError: PermGen space
为避免Perm Gen占满造成Full GC现象，可采用的方法为增大Perm Gen空间或转为使用CMS GC。

  1. CMS GC时出现promotion failed和concurrent mode failure
  2. 统计得到的Minor GC晋升到旧生代的平均大小大于旧生代的剩余空间

Hotspot为了避免由于新生代对象晋升到旧生代导致旧生代空间不足的现象，在进行Minor GC时，做了一个判断，如果之前统计所得到的Minor GC晋升到旧生代的平均大小大于旧生代的剩余空间，那么就直接触发Full GC。

G1这个另类下一篇再说，先看看上面这几种收集器的组合使用：

收集器组合

收集器大致可以按这张图进行组合使用：
在这里插入图片描述
接下来，直接来一张图，简单明了。
在这里插入图片描述

本文参考https://blog.ouyangsihai.cn/shen-ru-li-jie-java-xu-ni-ji-cms-la-ji-hui-shou-qi.html

1024-iot-SaltIce
关注
专栏目录
Java垃圾回收和JVM中的STW解析
PqCybersecurity的博客
09-20 288
垃圾回收是Java中一项重要的语言特性，它负责自动管理内存并释放不再使用的对象。垃圾回收是Java语言的一项重要特性，通过自动管理内存释放不再使用的对象。而STW则是垃圾回收机制中的一种策略，暂停应用程序的所有线程以执行垃圾回收操作。在这个过程中，垃圾回收器可以安全地执行垃圾回收操作，而不会受到应用程序线程的干扰。Java虚拟机中的垃圾回收器使用了不同的垃圾回收算法，例如标记-清除算法、复制算法、标记-整理算法等。方法建议垃圾回收器执行，但实际上具体的执行时机是由垃圾回收器自行决定的。
第 17 章 一 G1回收器(重点)、垃圾回收器总结(重要)、GC日志分析、垃圾回收器的新发展ZGC(重要)
Guizy
02-21 1308
由于篇幅, 无缝衔接上篇博客 ! 7、G1 回收器 (重重点)：区域化分代式 (并行回收器) JDK9的默认垃圾回收器 7.1、为什么还需要 G1 在延迟可控的情况下, 尽可能获取高的吞吐量 采用标记-压缩算法 既然我们已经有了前面几个强大的 GC ，为什么还要发布 Garbage First（G1）GC？ GC一直优化的原因就在于 应用程序所应对的业务越来越庞大、复杂，用户越来越多，没有GC就不能保证应用程序正常进行，而经常造成STW的GC又跟不上实际的需求，所以才会不断地尝试对GC进行.
JVM中的STW（Stop The World）
m0_67401417的博客
04-19 1444
1、Stop The World Stop一the一World，简称STW，指的是Gc事件发生过程中，会产生应用程序的停顿。停顿产生时整个应用程序线程都会被暂停，没有任何响应，有点像卡死的感觉，这个停顿称为STW。 举例： 可达性分析算法中枚举根节点（GC Roots）会导致所有Java执行线程停顿。 停顿的原因 分析工作必须在一个能确保一致性的快照中进行 一致性指整个分析期间整个执行系统看起来像被冻结在某个时间点上 如果出现分析过程中对象引用关系还在不断变化，则分析结果的准确性无法保证 示例代码： 被
JVM 垃圾回收
J 博客
06-01 603
JVM 垃圾回收
浅谈JVM的垃圾回收
qq_37376024的博客
02-18 383
JVM的垃圾回收算法和垃圾收集器前言JVM内存分布图如何确定垃圾JVM垃圾回收算法垃圾收集器 前言 算法是理论，垃圾收集器是理论的实现。 常用的垃圾回收算法有4个，分别是引用计数算法，复制算法，标记清除算法和标记整理算法。 垃圾收集器常用的有9个。分别是新生代(3)：Serial，PerNew，Parrel ，老生代(3):Serial Old，PerNew Old，CM以及G1。 在这之前，需要先了解下JVM的内存分布图 JVM内存分布图 以JDK1.8为例，JVM的内存分布主要是堆，栈和元空间。 栈主
(六)JVM成神路之GC基础篇：对象存活判定算法、GC算法、STW、GC种类详解
weixin_45101064的博客
03-18 1610
引言 经过前面五个章节的分析后，对于JVM的大部分子系统都已阐述完毕，在本文中则开始对JVM的GC子系统进行全面阐述，GC机制也是JVM的重中之重，调优、监控、面试都逃不开的JVM话题。 在前面分析JVM运行时内存区域时，其中程序计数器、虚拟机栈、本地方法栈三个区域随线程而生，伴线程而亡。而运行期间，栈的每个栈帧所需空间大小，其实在编译期就可大致确定，因此这几个区域的内存分配和回收都具备确定性，在这些区域内不需要过多考虑回收的问题，因为所分配的区域会随着线程或方法栈帧的销毁而随之回收。 而Java堆空间和元
JVM垃圾收集器
melody_161106的博客
10-31 397
什么是垃圾收集器 垃圾回收集Garbage Collection通常被称为GC，垃圾收集器就是内存回收的具体实现。在进行垃圾回收时，会暂停所有的工作线程，直到垃圾回收完成，垃圾回收器的不断迭代为优化减少了停顿时间。 使用垃圾回收器，通过设置垃圾回收器参数 -XX:+UserSerialGC,虚拟机运行在Client模式下的默认值，Serial+Serial Old； -XX:+UserParNewGC,ParNew+Serial Old,在JDK1.8被废弃，在JDK1.7还可以使用； -XX:+
jvm 垃圾收集器
qq_26140191的博客
01-04 98
    垃圾收集器就是收集算法的具体实现，不同的虚拟机会提供不同的收集器。两个收集器之间存在连线的话就说明它们可搭配使用。    serial收集器： 单线程收集器，使用复制收集算法，收集时会暂停所有工作线程(stop the world)，虚拟机运行在Client模式时的默认新生代收集器。 优点是：简单高效 。 在单个CPU的环境来说，没有线程交互的开销,在client情况下的默认+首...
JVM垃圾收集器和内存分配
Cherish__it的博客
04-16 403
一、串行回收器    1.新生代串行回收器 对于新生代串行回收器有两个重要的特点，第一个是，它仅仅使用单线程进行垃圾回收；第二个是它是独占式的拦击回收，也就是说在串行收集器进行垃圾回收时java相应的应用程序中的线程都需要暂停，等待回收器的工作的完成，这种情况被称作为STW，即stop the world，这个会对用户的体验造成很大的影响，如果对于实时性较强的系统，这种现象往往是不能够接受的，
深入JVM垃圾回收算法
热门推荐
Floating Cat
11-28 2万+
回收JVM堆中常用的算法： 1. 标记——清除算法 2. 标记——复制算法 3. 标记——整理算法 4. 分代收集算法 5. 增量收集算法
JAVA垃圾回收机制
10-03
Java垃圾回收机制（GC）是Java编程语言的...理解并选择合适的垃圾收集器对于优化Java应用程序的性能至关重要，尤其是处理大规模数据和并发环境时。开发者可以通过配置JVM参数来调整GC的行为，以满足应用的特定需求。
Java垃圾回收机制：引用计数与对象遍历
为了优化性能，现代JVM采用了各种垃圾收集器策略，例如标记-清除、复制、标记-整理和分代收集等。其中，G1（Garbage-First）垃圾回收器是Java 7引入的一种创新，它试图平衡吞吐量和延迟，通过分区堆和预测式停顿控制...
Java 堆和栈、垃圾回收
胃病的不良少彦
09-23 3568
Java运行程序包含： 栈Stack: 保存局部变量的值，包括： 1- 保存基本数据类型的值 2-保存类的实例，即堆区对象的引用 3-保存加载方法时的祯 堆Heap 用来存储动态产生的数据 1-比如new 出来的对象，注意创建出来的对象只包含各自的成员变量 不包括成员方法。因为同一个类的对象拥有各自的成员变量，存储在各自的堆中， 但是他们共享该类的方法，并不是每创建一个对象就把成员方法...
idea快速部署项目到Docker-详细版
qq_41257365的博客
07-22 7498
idea快速部署项目到Docker首先确保虚拟机上安装docker了1.修改docker的配置文件2.重新加载配置文件3.idea中的配置1.项目pom文件添加2.安装docker插件3.添加Dockerfile5.项目打包6.配置idea docker运行效果图4.中途容易出现的问题： 这里是在虚拟机中的部署。 首先确保虚拟机上安装docker了 1.修改docker的配置文件 找到docker.service文件并编辑：在ExecStart后面添加 -H tcp://0.0.0.0:2375
springboot 与 netty操作串口使用
qq_41257365的博客
11-14 3594
springboot 与 netty操作串口使用 1.pom添加依赖 <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> &...
idea快速复制一个模块
qq_41257365的博客
11-20 3019
idea快速复制一个模块 直接复制要复制的模块，粘贴到工程中模块所在地： 如图复制一份roses-example-account模块到里面，改名为roses-example-ms 并修改父pom.xml，在里面添加 <module>roses-example-ms</module> 这个时候可能会出现工程名称与模块名称不一致：如这种情况 这里去修改 为你自己的模块名...
Netty使用常见错误
qq_41257365的博客
03-21 2682
Netty使用常见错误 一、多个handler的执行顺序 通过***V字形看*** ：下面的是响应的接收过程，即OrderFrameDecoder()->OrderProtocolDecoder()->OrderServerProcessHandler() 响应的发送即：OrderServerProcessHandler()->OrderProtocolEncoder()-&g...
基于SpringBoot的注解式请求合并
qq_41257365的博客
05-20 1995
基于SpringBoot的注解式请求合并 某一天突然想到之前写过一个请求合并的代码，但是代码嵌入太强，就想自己写一个请求合并的注解，但是好像网上的相关代码较少，就去找到了Hystrix的请求合并相关资料，但是这代码可不是我所能看懂的。真是太难懂了，抓绕。 以下注解写的不是很全面，不是一个万能的，只能针对某一些类型的请求合并，并且是在spring boot和mybatis-plus基础上写的，要改为其它的也比较简单。 之后会慢慢学习完善的。如果各位看官有啥好滴思路，尽情到评论区发表看法啦，小弟再此谢谢啦。
SpringCloud中Hystrix选择线程池进行隔离时导致的ThreadLocal数据丢失的解决方法参考
qq_41257365的博客
09-24 1813
SpringCloud中Hystrix选择线程池进行隔离时导致的ThreadLocal数据丢失的解决方法 当我们在SpringCloud中选择Hystrix来实现断路器，Zuul中默认是用信号量，而Hystrix默认是线程池来进行隔离的。 当使用线程隔离时，会有一个很重要的问题需要注意： 那就是在一些业务场景下，可能需要ThreadLocal里在线程里传递数据，当然，如果你使用信号量的话是没问题的（信号量，请求进来的时候，以及后续的处理都是通过一个线程，这个是没问题的）。 当隔离模式选择了线程池时，H
深入解析JVM垃圾收集器的工作原理与挑战
本文将深入探讨JVM（Java Virtual Machine）中的垃圾收集器，这是Java编程中一项至关重要的机制。垃圾收集器起源于1960年的Lisp语言，尽管其与Java语言关系密切，但其实早在Java之前就已经存在。垃圾收集的主要目标...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值