JVM中的GC回收分析

最新推荐文章于 2024-04-27 14:47:24 发布

小飞鹤

最新推荐文章于 2024-04-27 14:47:24 发布

阅读量3.6k

点赞数

分类专栏：面试 Java高级 Java高级学习

本文链接：https://blog.csdn.net/he90227/article/details/52136038

版权

Java高级同时被 3 个专栏收录

56 篇文章 0 订阅

订阅专栏

Java高级学习

46 篇文章 40 订阅

订阅专栏

面试

15 篇文章 0 订阅

订阅专栏

1.GC垃圾回收算法

1、三种垃圾回收算法

标记-清除（年老代）
标记-整理（即标记-压缩）（年老代）
复制（年轻代）

1.1、标记-清除算法

原理：

从根集合节点进行扫描，标记出所有的存活对象，最后扫描整个内存空间并清除没有标记的对象（即死亡对象）

适用场合：

存活对象较多的情况下比较高效
适用于年老代（即旧生代）

缺点：

容易产生内存碎片，再来一个比较大的对象时（典型情况：该对象的大小大于空闲表中的每一块儿大小但是小于其中两块儿的和），会提前触发垃圾回收
扫描了整个空间两次（第一次：标记存活对象；第二次：清除没有标记的对象）

注意：

在该情况下，内存不规整，对象的内存分配采用"空闲列表法"，

1.2、标记整理算法

原理：

从根集合节点进行扫描，标记出所有的存活对象，最后扫描整个内存空间并清除没有标记的对象（即死亡对象）（可以发现前边这些就是标记-清除算法的原理），清除完之后，将所有的存活对象左移到一起。

适用场合：

用于年老代（即旧生代）

缺点：

需要移动对象，若对象非常多而且标记回收后的内存非常不完整，可能移动这个动作也会耗费一定时间
扫描了整个空间两次（第一次：标记存活对象；第二次：清除没有标记的对象）

优点：

不会产生内存碎片

注意：

在该情况下，内存规整，对象的内存分配采用"指针碰撞法"，

1.3、复制算法

原理：

从根集合节点进行扫描，标记出所有的存活对象，并将这些存活的对象复制到一块儿新的内存（图中下边的那一块儿内存）上去，之后将原来的那一块儿内存（图中上边的那一块儿内存）全部回收掉

适用场合：

存活对象较少的情况下比较高效
扫描了整个空间一次（标记存活对象并复制移动）
适用于年轻代（即新生代）：基本上98%的对象是"朝生夕死"的，存活下来的会很少

缺点：

需要一块儿空的内存空间
需要复制移动对象

注意：

在该情况下，内存规整，对象的内存分配采用"指针碰撞法"，
以空间换时间：通过一块儿空内存的使用，减少了一次扫描

2、垃圾回收机制

年轻代分为Eden区和survivor区（两块儿：from和to），且默认 Eden:from:to==8:1:1

1）新产生的对象优先分配在Eden区（除非配置了-XX:PretenureSizeThreshold，大于该值的对象会直接进入年老代）；

2）当Eden区满了或放不下了，这时候其中存活的对象会复制到from区（这里，需要注意的是，如果存活下来的对象from区都放不下，则这些存活下来的对象全部进入年老代），之后Eden区的内存全部回收掉；注意：如果是Eden区没有满，但是来了一个小对象Eden区放不下，这时候Eden区存活对象复制到from区后，清空Eden区，之后刚才的小对象再进入Eden区

3）之后产生的对象继续分配在Eden区，当Eden区又满了或放不下了，这时候将会把Eden区和from区存活下来的对象复制到to区（同理，如果存活下来的对象to区都放不下，则这些存活下来的对象全部进入年老代），之后回收掉Eden区和from区的所有内存；

4）如上这样，会有很多对象会被复制很多次（每复制一次，对象的年龄就+1），默认情况下，当对象被复制了15次（这个次数可以通过：-XX:MaxTenuringThreshold来配置），就会进入年老代了

5）当年老代满了或者存放不下将要进入年老代的存活对象的时候，就会发生一次Full GC（这个是我们最需要减少的，因为耗时很严重）

总结：

年轻代：复制算法
年老代：标记-清除或标记-整理（前者相较于后者会快一些但是会产生内存碎片，后者相较于前者不会产生内存碎片但是由于要移动存活对象所以会慢一些）
以上这种年轻代与年老代分别采用不同回收算法的方式称为"分代收集算法"，这也是当下企业使用的一种方式
每一种算法都会有很多不同的垃圾回收器去实现，在实际使用中，根据自己的业务特点做出选择就好

2.垃圾收集器

1、七种垃圾收集器

Serial（串行GC）-- 复制
ParNew（并行GC）-- 复制
Parallel Scavenge（并行回收GC）-- 复制
Serial Old（MSC）（串行GC）-- 标记-整理
CMS（并发GC）-- 标记-清除
Parallel Old（并行GC）--标记-整理
G1（JDK1.7update14才可以正式商用）

说明：

1~3用于年轻代垃圾回收：年轻代的垃圾回收称为minor GC
4~6用于年老代垃圾回收（当然也可以用于方法区的回收）：年老代的垃圾回收称为full GC
G1独立完成"分代垃圾回收"

注意：并行与并发

并行：多条垃圾回收线程同时操作
并发：垃圾回收线程与用户线程一起操作

2、常用五种组合

Serial/Serial Old
ParNew/Serial Old：与上边相比，只是比年轻代多了多线程垃圾回收而已
ParNew/CMS：当下比较高效的组合
Parallel Scavenge/Parallel Old：自动管理的组合
G1：最先进的收集器，但是需要JDK1.7update14以上

2.1、Serial/Serial Old：

特点：

年轻代Serial收集器采用单个GC线程实现"复制"算法（包括扫描、复制）
年老代Serial Old收集器采用单个GC线程实现"标记-整理"算法
Serial与Serial Old都会暂停所有用户线程（即STW）

说明：

STW（stop the world）：编译代码时为每一个方法注入safepoint（方法中循环结束的点、方法执行结束的点），在暂停应用时，需要等待所有的用户线程进入safepoint，之后暂停所有线程，然后进行垃圾回收。

适用场合：

CPU核数<2，物理内存<2G的机器（简单来讲，单CPU，新生代空间较小且对STW时间要求不高的情况下使用）
-XX:UseSerialGC：强制使用该GC组合
-XX:PrintGCApplicationStoppedTime：查看STW时间

2.2、ParNew/Serial Old：

说明：

ParNew除了采用多GC线程来实现复制算法以外，其他都与Serial一样，但是此组合中的Serial Old又是一个单GC线程，所以该组合是一个比较尴尬的组合，在单CPU情况下没有Serial/Serial Old速度快（因为ParNew多线程需要切换），在多CPU情况下又没有之后的三种组合快（因为Serial Old是单GC线程），所以使用其实不多。
-XX:ParallelGCThreads：指定ParNew GC线程的数量，默认与CPU核数相同，该参数在于CMS GC组合时，也可能会用到

2.3、Parallel Scavenge/Parallel Old：

特点：

年轻代Parallel Scavenge收集器采用多个GC线程实现"复制"算法（包括扫描、复制）
年老代Parallel Old收集器采用多个GC线程实现"标记-整理"算法
Parallel Scavenge与Parallel Old都会暂停所有用户线程（即STW）

说明：

吞吐量：CPU运行代码时间/(CPU运行代码时间+GC时间)
CMS主要注重STW的缩短（该时间越短，用户体验越好，所以主要用于处理很多的交互任务的情况）
Parallel Scavenge/Parallel Old主要注重吞吐量（吞吐量越大，说明CPU利用率越高，所以主要用于处理很多的CPU计算任务而用户交互任务较少的情况）

参数设置：

-XX:+UseParallelOldGC：使用该GC组合
-XX:GCTimeRatio：直接设置吞吐量大小，假设设为19，则允许的最大GC时间占总时间的1/(1+19)，默认值为99，即1/(1+99)
-XX:MaxGCPauseMillis：最大GC停顿时间，该参数并非越小越好
-XX:+UseAdaptiveSizePolicy：开启该参数，-Xmn/-XX:SurvivorRatio/-XX:PretenureSizeThreshold这些参数就不起作用了，虚拟机会自动收集监控信息，动态调整这些参数以提供最合适的的停顿时间或者最大的吞吐量（GC自适应调节策略），而我们需要设置的就是-Xmx，-XX:+UseParallelOldGC或-XX:GCTimeRatio两个参数就好（当然-Xms也指定上与-Xmx相同就好）

注意：

-XX:GCTimeRatio和-XX:MaxGCPauseMillis设置一个就好

不开启-XX:+UseAdaptiveSizePolicy，-Xmn/-XX:SurvivorRatio/-XX:PretenureSizeThreshold这些参数依旧可以配置，以resin服务器为例

<jvm-arg>-Xms2048m</jvm-arg>
            <jvm-arg>-Xmx2048m</jvm-arg>
            <jvm-arg>-Xmn512m</jvm-arg>
            <jvm-arg>-Xss1m</jvm-arg>
            <jvm-arg>-XX:PermSize=256M</jvm-arg>
            <jvm-arg>-XX:MaxPermSize=256M</jvm-arg>
            <jvm-arg>-XX:SurvivorRatio=8</jvm-arg>
            <jvm-arg>-XX:MaxTenuringThreshold=15</jvm-arg>

            <jvm-arg>-XX:+UseParallelOldGC</jvm-arg>
            <jvm-arg>-XX:GCTimeRatio=19</jvm-arg>

            <jvm-arg>-XX:+PrintGCDetails</jvm-arg>
            <jvm-arg>-XX:+PrintGCTimeStamps</jvm-arg>

适用场合：

很多的CPU计算任务而用户交互任务较少的情况
不想自己去过多的关注GC参数，想让虚拟机自己进行调优工作

2.4、ParNew/CMS

说明：

以上只是年老代CMS收集的过程，年轻代ParNew看"2.2、ParNew/Serial Old"就好
CMS是多回收线程的，不要被上图误导，默认的线程数：(CPU数量+3)/4
CMS主要注重STW的缩短（该时间越短，用户体验越好，所以主要用于处理很多的交互任务的情况）

特点：

年轻代ParNew收集器采用多个GC线程实现"复制"算法（包括扫描、复制）
年老代CMS收集器采用多线程实现"标记-清除"算法
- 初始标记：标记与根集合节点直接关联的节点。时间非常短，需要STW
- 并发标记：遍历之前标记到的关联节点，继续向下标记所有存活节点。时间较长。
- 重新标记：重新遍历trace并发期间修改过的引用关系对象。时间介于初始标记与并发标记之间，通常不会很长。需要STW
- 并发清理：直接清除非存活对象，清理之后，将该线程占用的CPU切换给用户线程
初始标记与重新标记都会暂停所有用户线程（即STW），但是时间较短；并发标记与并发清理时间较长，但是不需要STW

关于并发标记期间怎样记录发生变动的引用关系对象，在重新标记期间怎样扫描这些对象

缺点：

并发标记与并发清理：按照说明的第二点来讲，假设有2个CPU，那么其中有一个CPU会用于垃圾回收，而另一个用于用户线程，这样的话，之前是两CPU运行用户线程，现在是一个，那么效率就会急剧下降。也就是说，降低了吞吐量（即降低了CPU使用率）。
并发清理：在这一过程中，产生的垃圾无法被清理（因为发生在重新标记之后）
并发标记与并发清理：由于是与用户线程并发的，所以用户线程可能会分配对象，这样既可能对象直接进入年老代（例如，大对象），也可能进入年轻代后，年轻代发生minor GC，这样的话，实际上要求我们的年老代需要预留一定空间，也就是说要在年老代还有一定空间的情况下就要进行垃圾回收，留出一定内存空间来供其他线程使用，而不能等到年老代快爆满了才进行垃圾回收，通过-XX:CMSInitiatingOccupancyFraction来指定当年老代空间满了多少后进行垃圾回收
标记-清理算法：会产生内存碎片，由于是在老年代，可能会提前触发Full GC（这正是我们要尽量减少的）

参数设置：

-XX:+UseConcMarkSweepGC：使用该GC组合
-XX:CMSInitiatingOccupancyFraction：指定当年老代空间满了多少后进行垃圾回收
-XX:+UseCMSCompactAtFullCollection：（默认是开启的）在CMS收集器顶不住要进行FullGC时开启内存碎片整理过程，该过程需要STW
-XX:CMSFullGCsBeforeCompaction：指定多少次FullGC后才进行整理
-XX:ParallelCMSThreads：指定CMS回收线程的数量，默认为：(CPU数量+3)/4

适用场合：

用于处理很多的交互任务的情况
方法区的回收一般使用CMS，配置两个参数：-XX:+CMSPermGenSweepingEnabled与-XX:+CMSClassUnloadingEnabled

3、一些经验

由于当下大型企业用的比较多的还是jdk1.6版本，所以G1用的还是不多
用得最多的两种：ParNew/CMS和Parallel Scavenge/Parallel Old
Full GC的四种情况
- 旧生代空间不足
  - 不要创建过大的对象获数组
  - 尽量让对象在minor GC被回收
  - 让对象在年轻代多存活一段时间，可能这段时间内就会被minor GC回收
- 方法区满了
  - 增大方法区
  - 使用CMS GC回收方法区
- CMS GC中promotion failed（minor GC时，survivor区放不下，年老区也放不下）和concurrent mode failure
  - 增大survivor区
  - 增大年老区
  - 调低-XX:CMSInitiatingOccupancyFraction
  - 设置：-XX:CMSMaxAbortablePrecleanTime=5(单位:ms)，防止CMS在重新标记很久后才进行并发清理
- 空间担保机制（这一块儿见《深入理解Java虚拟机（第二版）》P98）

附：具体的配置参数查看《深入理解Java虚拟机（第二版）》P90

1、G1

说明：

从上图来看，G1与CMS相比，仅在最后的"筛选回收"部分不同（CMS是并发清除），实际上G1回收器的整个堆内存的划分都与其他收集器不同。
CMS需要配合ParNew，G1可单独回收整个空间

原理：

G1收集器将整个堆划分为多个大小相等的Region
G1跟踪各个region里面的垃圾堆积的价值（回收后所获得的空间大小以及回收所需时间长短的经验值），在后台维护一张优先列表，每次根据允许的收集时间，优先回收价值最大的region，这种思路：在指定的时间内，扫描部分最有价值的region（而不是扫描整个堆内存），并回收，做到尽可能的在有限的时间内获取尽可能高的收集效率。

运作流程：

初始标记：标记出所有与根节点直接关联引用对象。需要STW
并发标记：遍历之前标记到的关联节点，继续向下标记所有存活节点。
- 在此期间所有变化引用关系的对象，都会被记录在Remember Set Logs中
最终标记：标记在并发标记期间，新产生的垃圾。需要STW
筛选回收：根据用户指定的期望回收时间回收价值较大的对象（看"原理"第二条）。需要STW

优点：

停顿时间可以预测：我们指定时间，在指定时间内只回收部分价值最大的空间，而CMS需要扫描整个年老代，无法预测停顿时间
无内存碎片：垃圾回收后会整合空间，CMS采用"标记-清理"算法，存在内存碎片
筛选回收阶段：
- 由于只回收部分region，所以STW时间我们可控，所以不需要与用户线程并发争抢CPU资源，而CMS并发清理需要占据一部分的CPU，会降低吞吐量。
- 由于STW，所以不会产生"浮动垃圾"（即CMS在并发清理阶段产生的无法回收的垃圾）

适用范围：

追求STW短：若ParNew/CMS用的挺好，就用这个；若不符合，用G1
追求吞吐量：用Parallel Scavenge/Parallel Old，而G1在吞吐量方面没有优势

2、几点注意

问题1、G1以外的其他收集器在回收垃圾的时候：要不只是扫描年轻代，要不只是扫描年老代。在年轻代的回收过程中，如果旧生代中的对象引用了年轻代的对象，那么我们只扫描年轻代就不行了，但是由于年老代一般而言是年轻代的3倍大小，如果年轻代、年老代一起去扫描的话，效率会急剧下降，这个问题怎么处理？

答：JVM采用remember set来做的这个事儿，当发现一个引用对象被赋值时，JVM发出一个write barrier指令来暂时中断写操作，检查被赋值的引用对象是不是处于年老代，且其引用的对象是不是处于新生代（即是不是年老代对象引用了年轻代对象），如果是，将相关引用信息记录到remember set。之后的扫描，我们会从根集合+remember set向下进行扫描。（也就是说真正的根集合，是JVM定义的根集合+remember set）

问题2、G1收集器为了做到GC时间可预测，采用扫描部分价值最大的region来实现，那么如果这部分region中的对象被其他region中的对象所引用，那么仅扫描前者可能就不行了，但是如果扫描全部region的话，又无法做到GC时间可预测，效率会大大下降，怎么办？

答：G1同理，为每一个region分配一个remember set，当发现一个引用对象被赋值时，JVM发出一个write barrier指令来暂时中断写操作，检查被赋值的引用对象与其引用的对象是不是处于不同的region（eg.a=b;检查a与b是不是在不同的region），如果是，将相关引用信息记录到当前region的remember set。之后的扫描，我们会从根集合+remember set向下进行扫描。

问题3、CMS与G1在并发标记的时候若发部分引用对象的引用关系发生了变化，怎么处理才能让重新标记的时候仅仅扫描出这些变化？

答：在并发标记期间，对象的引用关系若发生了变化，这些相关的记录就会记录到remember set logs；在重新标记阶段，将该logs的信息加入到remember set中去，然后再从remember set去向下trace节点。

小飞鹤

关注

0
点赞
踩
2

收藏

觉得还不错? 一键收藏
1
评论
JVM中的GC回收分析

1.GC垃圾回收算法1、三种垃圾回收算法标记-清除（年老代）标记-整理（即标记-压缩）（年老代）复制（年轻代）1.1、标记-清除算法原理：从根集合节点进行扫描，标记出所有的存活对象，最后扫描整个内存空间并清除没有标记的对象（即死亡对象）适用场合：存活对象较多的情况下比较高效适用于年老代（即旧生代）缺点：容易产生内存
复制链接

扫一扫