JVM 垃圾回收器

最新推荐文章于 2024-10-18 23:14:35 发布

HanJuly9569

最新推荐文章于 2024-10-18 23:14:35 发布

阅读量118

点赞数

分类专栏： JVM 文章标签： jvm 垃圾回收

本文链接：https://blog.csdn.net/HanJuly9569/article/details/116572799

版权

3 篇文章 0 订阅

订阅专栏

个人总结以官网为准，如有错误欢迎指出

如果你（运行的程序）在房间(内存)里不断的产生垃圾（可清除的对象），并且你青春期脾气不好，妈妈不想跟你小屁孩计较（避免打扰用户程序，减少stop the word），那妈妈会怎么做才能到达快速，并且不影响你打游戏？
- 首先妈妈会进去看一眼，有哪些需要处理的垃圾，然后离开
- 然后妈妈拿到工具，进入房间，把你骂出房间，快速处理再让你回来

以上妈妈的行为在垃圾回收的过程中，映射为首先标记对象，然后stop the world 清理垃圾，然后恢复程序。

所以出现了多线程并行清理的垃圾回收器。

Parallel类型的速度解决了，清理速度和吞吐量的问题，工程师就如万恶的资本家一样总觉得还能压榨出来一点。哪里还能压榨呢？
- 标记整理的算法，整理是很耗时的，如果我们不整理直接清除
- 清理的时候，如果我们不stop the world，并发清理

于是出现了CMS垃圾回收器

在这里插入图片描述

CMS 具有的优点
- 由于并发标记，并发清理，速度快延迟低，适合实时程序与秒杀程序
CMS 牺牲了什么换来了低延迟
- 它使用标记清除的算法，跳过整理，达成了低延迟。但是牺牲了长期的内存利用效率。如果前期的对象多数是小对象，后期的对象多数是大对象，那么标记清除的算法会导致后期的大对象找不到空间放置。总体上看是有足够的空间，但是找到连续合适的空间放置大对象
- 无法处理浮动的垃圾，由于是并发清理，清理的过程中又会产生新的垃圾
截至CMS垃圾回收器，我们解决了什么问题，有带来那些问题，还有那些问题没有解决。
- 解决了：减少了stop world的时间，实现了低延迟（CMS）
- 解决了：单线程到多线程，提高了吞吐量（Parallel 类型）
- 未能解决的问题： stop the world的时间不可控，我们唯一能做的是等待
- 出现的新问题：即参考CMS的缺点
  G1 垃圾回收器解决了上面一些问题。

G1 解决的问题

流程

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

在这里插入图片描述