性能文章>G1垃圾回收源码分析(一)>

G1垃圾回收源码分析(一)原创

1年前
729406

G1 垃圾回收(一)

垃圾回收算法

标记清除,标记复制,标记-清除-压缩,

image.png

  • 标记清除

标记清除呢就是比较直观的理解了,内存中当引用不可达之后这一块内存就要被释放出来,,当然我们知道java中的对象在内存中的分布不是连续的,每一次将标记的对象清除之后,就会释放出来当前的空间,这些空间大小不均,如果很小的话不足以再次分配的话,这就造成了大量的内存碎片,CMS就是基于该算法

  • 标记复制

image.png

将内存中分成俩块区域,俩块区域来回复制,一般是from区域和to区域,在垃圾回收发生器的时候,from区域所有存活的对象移动到to区,然后以此类推,to区再移回from区域,这样内存区域的利用率比较低,适用于朝生夕灭的对象。

压缩呢,则是增加一次压实操作,将碎片内存利用起来

在分代回收的Hotspot虚拟机中,新生代的垃圾收集采取标记复制算法,老年代采取标记清除算法。

  • CMS垃圾回收器

    低延时,并发收集,只用于老年代垃圾回收,新生代配合ParNew使用。无法进行压缩,压缩依赖于Full GC。

    下图是CMS垃圾呼死后的工作流程,一共触发2次STW,分别在初始标记和重标记阶段

image.png

  • G1垃圾回收器

    同样是低延时,提供增量压缩,适用于较大的Heap(>4G),可以设定GC预期。相较于CMS来说,G1不单单只用于新生代或者老年代。而是横跨整个堆。而且分代不再是来连续的内存空间,而是分布在不同的Region(后文会说),G1垃圾回收器把整个JVM 堆划分为N个(1M~32M)的等大的分区。默认是2048个分区。

    • 针对新生代

    STW ,并行,复制

    • 针对老年代

    STW ,并行标记清除,增量压缩

    G1垃圾回收的工作流程,同样是先在Eden去进行垃圾并发回收,然后回收内存。不同的是G1会在新生代GC的时候记录,用于老年代GC,GC停顿预测。当整个堆占用达到默认45%(-XX:InitiatingHeapOccupancyPercent=N),回进行老年代GC,同样,老年代也是并发GC,但是区别于CMS的是,G1的老年代GC一定会再进行一次新生代GC,类似于使用CMS垃圾回收器时候增加参数(-XX:+CMSScavengeBeforeRemark),老年代的GC使用<red>三色标记算法<red>来进行老年代初始标记,然后在重标记阶段使用SATB来解决并发标记时候可能是活跃对象的内存处理,然后回收全空的分区。还有G1的老年代GC不是立即发生的,而且这个发生的区域也不是整个堆,而是部分老年代分区进行GC,默认是1/8的老年代(-XX:G1MixedGCCountTarget=N),依据暂停的预期,G1会选择最多的区域进行优先回收。(-XX:G1MixedGCLiveThresholdPercent=N (default 85),(-XX:G1HeapWastePercent=N),下图是G1的回收工作流程。

image.png
>

image.png

分区(Heap Region)

上面简单讲述了几种垃圾回收器的信息,这里呢就G1的分区展开讲述。分区呢是G1特有的内存结构。参见源代码分区类型可以知道G1主要分为以下几种分区类型

  • 自由分区 (FHR)

  • 新生代分区(YHR)

  • 老年代分区(OHR)

  • 大对象分区(Humongous Heap Region)

    • 大对象头分区

    • 大对象连续分区

上面说G1垃圾回收器把整个JVM 堆划分为N个(1M~32M)的等大的分区。默认是2048个分区。这是在我们不指定分区大小(G1HeapRegionSize,默认为0.使用自推断。)的情况下,G1自动推断出来的,推断的逻辑参照源代码分区类setup_heap_region_size方法.

void HeapRegion::setup_heap_region_size(size_t initial_heap_size, size_t max_heap_size) {
uintx region_size = G1HeapRegionSize;
if (FLAG_IS_DEFAULT(G1HeapRegionSize)) {
size_t average_heap_size = (initial_heap_size + max_heap_size) / 2;
region_size = MAX2(average_heap_size / HeapRegionBounds::target_number(),
(uintx) HeapRegionBounds::min_size());
}
int region_size_log = log2_long((jlong) region_size);
// Recalculate the region size to make sure it's a power of
// 2. This means that region_size is the largest power of 2 that's
// <= what we've calculated so far.
region_size = ((uintx)1 << region_size_log);

// Now make sure that we don't go over or under our limits.
if (region_size < HeapRegionBounds::min_size()) {
region_size = HeapRegionBounds::min_size();
} else if (region_size > HeapRegionBounds::max_size()) {
region_size = HeapRegionBounds::max_size();
}

// And recalculate the log.
region_size_log = log2_long((jlong) region_size);

// Now, set up the globals.
guarantee(LogOfHRGrainBytes == 0, "we should only set it once");
LogOfHRGrainBytes = region_size_log;

guarantee(LogOfHRGrainWords == 0, "we should only set it once");
LogOfHRGrainWords = LogOfHRGrainBytes - LogHeapWordSize;

guarantee(GrainBytes == 0, "we should only set it once");
// The cast to int is safe, given that we've bounded region_size by
// MIN_REGION_SIZE and MAX_REGION_SIZE.
GrainBytes = (size_t)region_size;

guarantee(GrainWords == 0, "we should only set it once");
GrainWords = GrainBytes >> LogHeapWordSize;
guarantee((size_t) 1 << LogOfHRGrainWords == GrainWords, "sanity");

guarantee(CardsPerRegion == 0, "we should only set it once");
CardsPerRegion = GrainBytes >> CardTableModRefBS::card_shift;
}

具体视线逻辑如下:

  1. 首先判断JVM参数(G1HeapRegionSize)是否设定,如果没有设定,那么就是采取自推断模式来计算,计算依赖于堆的初始大小和最大值。用这俩个值的平均数整除默认的分区个数。得到分区的大小。

  2. 左移让分区的大小对其$2^N $幂

  3. 处理溢出,保证在1M-32M范围之内

  4. 设置一些全局变量的值,如卡表的大小,PreRegion的大小(用于设定Remember Set,内部PerRegionTable的位图_bm大小,用于存放卡表的索引)

停顿预测模型(基于滑动标准差)

上面我曾提到G1是低延时,可以设定GC停顿预期的回收器,具体是如何实现呢,设置的参数呢为(MaxGCPauseMillis),在当前的版本是JDK8U中源代码G1收集策略中是200MS。具体的默认值在不同的jdk版本中有不同的设定。具体是情况而定。

首先来说下衰减平均也叫滑动平均,主要用于去取一列数据的平均值$davg_n$,公式如下

GarbageCollection

其中$\alpha$为历史数据的权重,$V_n$代表平均值,$1-\alpha$为最近一次的数据权重,$\alpha$越小,对数据的影响越大。根据滑动平均的公式可得到滑动方差$davr_n$

GarbageCollection

参考源代码G1收集策略get_new_predition,该方法为G1的获取预测值的方法

double get_new_prediction(TruncatedSeq* seq) {
return MAX2(seq->davg() + sigma() * seq->dsd(),
seq->davg() * confidence_factor(seq->num()));
}
  1. davg方法表示滑动均值

  2. sigma代表对预测值的信赖度。默认50.也即是半信任(G1ConfidencePercent)

  3. dad代表滑动方差

  4. confidence_factor 一共了部分初始样本数据,当数据不足5个的时候,返回一个大于1小于2的数,供以样本计算。

  5. seq->num(),代表每次YoungGC记录的GC时间,存放在TruncateSeq中,

    参考源代码numberSeqAbsSeq::add. 该方法计算滑动均值和方差

    • void AbsSeq::add(double val) {
      if (_num == 0) {
      _davg = val;
      _dvariance = 0.0;
      } else {
      _davg = (1.0 - _alpha) * val + _alpha * _davg;
      double diff = val - _davg;
      _dvariance = (1.0 - _alpha) * diff * diff + _alpha * _dvariance;
      }
      }

    可以看到这个滑动平均的代码实现,_alpha默认是0.7,

举个例子来叙述G1为什么使用滑动平均来计算软实时停顿预测。看到上面的预测公式

起始令$V_0=0,\alpha=0.7$,依次对变量v进行赋值,不使用滑动平均和使用滑动平均结果数据如下。

不应用滑动平均赋值(随机数) 滑动平均赋值 time
0 / 0
10 3 1
20 8.1 2
10 8.67 3
0 6.009 4
40 16.2483 5
0 11.37381 6
10 10.961667 7
15 12.1731669 8

通过数据得到:滑动平均得到的值更加平缓光滑,抖动性更小,不会因为某次的异常取值而使得滑动平均值波动很大

 

相关阅读

G1垃圾回收源码分析(一)

G1垃圾回收源码分析(二)

G1垃圾回收源码分析(三)

分类:
标签:
请先登录,再评论

暂无回复,快来写下第一个回复吧~

为你推荐

不起眼,但是足以让你有收获的JVM内存分析案例
分析 这个问题说白了,就是说有些int[]对象不知道是哪里来的,于是我拿他的例子跑了跑,好像还真有这么回事。点该 dump 文件详情,查看相关的 int[] 数组,点该对象的“被引用对象”,发现所
从一起GC血案谈到反射原理
前言 首先回答一下提问者的问题。这主要是由于存在大量反射而产生的临时类加载器和 ASM 临时生成的类,这些类会被保留在 Metaspace,一旦 Metaspace 即将满的时候,就会触发 Fu
关于内存溢出,咱再聊点有意思的?
概述 上篇文章讲了JVM在GC上的一个设计缺陷,揪出一个导致GC慢慢变长的JVM设计缺陷,可能有不少人还是没怎么看明白的,今天准备讲的大家应该都很容易看明白 本文其实很犹豫写不写,因为感觉没有
协助美团kafka团队定位到的一个JVM Crash问题
概述 有挺长一段时间没写技术文章了,正好这两天美团kafka团队有位小伙伴加了我微信,然后咨询了一个JVM crash的问题,大家对crash的问题都比较无奈,因为没有现场,信息量不多,碰到这类问题我
又发现一个导致JVM物理内存消耗大的Bug(已提交Patch)
概述 最近我们公司在帮一个客户查一个JVM的问题(JDK1.8.0_191-b12),发现一个系统老是被OS Kill掉,是内存泄露导致的。在查的过程中,阴差阳错地发现了JVM另外的一个Bug。这个B
JVM实战:优化我的IDEA GC
IDEA是个好东西,可以说是地球上最好的Java开发工具,但是偶尔也会卡顿,仔细想想IDEA也是Java开发的,会不会和GC有关,于是就有了接下来对IDEA的GC进行调优 IDEA默认JVM参数: -
不起眼,但是足以让你收获的JVM内存案例
今天的这个案例我觉得应该会让你涨姿势吧,不管你对JVM有多熟悉,看到这篇文章,应该还是会有点小惊讶的,不过我觉得这个案例我分享出来,是想表达不管多么奇怪的现象请一定要追究下去,会让你慢慢变得强大起来,
如何通过反射获得方法的真实参数名(以及扩展研究)
前段时间,在做一个小的工程时,遇到了需要通过反射获得方法真实参数名的场景,在这里我遇到了一些小小的问题,后来在部门老大的指导下,我解决了这个问题。通过解决这个问题,附带着我了解到了很多新的知识,我觉得