精华内容
下载资源
问答
  • 写屏障
    2022-03-03 22:58:08

    前言

    本文主要讲解三色标记具体工作原理,多标导致的浮动垃圾、漏标的处理方案(读写屏障)等。

    基本概念

       JVM 中的垃圾回收是基于 标记-复制、标记-清除和标记-整理三种模式的,那么其中最重要的其实是如何标记,像Serial、Parallel这类的回收器,无论是单线程标记和多线程标记,其本质采用的是暂停用户线程进行全面标记的算法,这种算法的好处就是标记的很干净,而且实现简单,缺点就是标记时间相对很长,导致STW的时间很长;

       那么后来就有了并发标记,适用于CMS和G1,并发标记的意思就是可以在不暂停用户线程的情况下对其进行标记,那么实现这种并发标记的算法就是三色标记法,三色标记法最大的特点就是可以异步执行,从而可以以中断时间极少的代价或者完全没有中断来进行整个GC。
       无论使用哪种算法,标记总是必要的一步。这是理算当然的,你不先找到垃圾,怎么进行回收?

    基本流程

    垃圾回收器的工作流程大体如下:

    1. 标记出哪些对象是存活的,哪些是垃圾(可回收);
    2. 进行回收(清除/复制/整理),如果有移动过对象(复制/整理),还需要更新引用。

    本文着重来看下标记的部分。

    三色标记

    基本算法

    要找出存活对象,根据可达性分析,从GC Roots开始进行遍历访问,可达的则为存活对象:
    在这里插入图片描述
    最终结果:A/D/E/F/G 可达

    我们把遍历对象图过程中遇到的对象,按“是否访问过”这个条件标记成以下三种颜色:

    • 白色:尚未被GC访问过的对象,如果全部标记已完成依旧为白色的,称为不可达对象,既垃圾对象。
    • 黑色:本对象已经被GC访问过,且本对象的子引用对象也已经被访问过了。
    • 灰色:本对象已访问过,但是本对象的子引用对象还没有被访问过,全部访问完会变成黑色,属于中间态。

    标记过程

    1. 在GC并发标记刚开始时,所以对象均为白色集合。
    2. 将所有GCRoots直接引用的对象标记为灰色集合。
    3. 判断若灰色集合中的对象不存在子引用,则将其放入黑色集合,若存在子引用对象,则将其所有的子引用对象放入灰色集合,当前对象放入黑色集合。
    4. 按照步骤三,以此类推,直至灰色集合中的所有对象变成黑色后,本轮标记完成,且当前白色集合内的对象称为不可达对象,既垃圾对象。

    多标与漏标

    问题:由于此过程是在和用户线程并发运行的情况下,对象的引用处于随时可变的情况下,那么就会造成多标和漏标的问题。

    多标与浮动垃圾

    如图:开始有A->B的引用,但此时应用执行 objA.fieldB = null,将引用断开
    在这里插入图片描述
    此刻之后,对象B/C/D是“应该”被回收的。然而因为B已经变为灰色了,其仍会被当作存活对象继续遍历下去。最终的结果是:这部分对象仍会被标记为存活,即本轮GC不会回收这部分内存。

    这部分本应该回收 但是 没有回收到的内存,被称之为“浮动垃圾”。浮动垃圾并不会影响应用程序的正确性,只是需要等到下一轮垃圾回收中才被清除。

    漏标

    如图:开始没有A->D的引用,但此时应用执行如下代码

    var D = objB.fieldD; 
    objB.fieldD = null;  // 灰色B 断开引用 白色D 
    objA.fieldD = D;  // 黑色A 引用 白色D
    

    在这里插入图片描述

    最终导致的结果是:D会一直停留在白色集合中,最后被当作垃圾进行清除。这直接影响到了应用程序的正确性,是不可接受的。

    读写屏障 —(类似AOP思想)

    不难分析,漏标只有同时满足以下两个条件时才会发生:
    条件一:灰色对象 断开了 白色对象的引用(直接或间接的引用);即灰色对象 原来成员变量的引用 发生了变化。
    条件二:黑色对象 重新引用了 该白色对象;即黑色对象 成员变量增加了 新的引用。

    从代码的角度看:

    var D = objB.fieldD; //1.读
    objB.fieldD = null;  // 2.写 
    objA.fieldD = D;  // 3.写
    
    1. 读取 对象B的成员变量fieldD的引用值,即对象D;
    2. 对象B 往其成员变量fieldD,写入 null 值。
    3. 对象A 往其成员变量fieldD,写入 对象D;

    我们只要在上面这三步中的任意一步中做一些“手脚”,将对象G记录起来,然后作为灰色对象再进行遍历即可。比如放到一个特定的集合,等初始的GC Roots遍历完(并发标记),该集合的对象 遍历即可(重新标记)。

    重新标记通常是需要STW的,因为应用程序一直在跑的话,该集合可能会一直增加新的对象,导致永远都跑不完。当然,并发标记期间也可以将该集合中的大部分先跑了,从而缩短重新标记STW的时间,这个是优化问题了。

    1.写屏障用于拦截第二和第三步;而读屏障则是拦截第一步。
    3.它们的拦截的目的很简单:就是在读写前后,将对象D给记录下来。

    写屏障

    给某个对象的成员变量赋值时,其底层代码大概长这样:

    /**
    * @param field 某对象的成员变量,如 D.fieldG
    * @param new_value 新值,如 null
    */
    void oop_field_store(oop* field, oop new_value) { 
        *field = new_value; // 赋值操作
    } 
    

    所谓的写屏障,其实就是指在赋值操作前后,加入一些处理(可以参考AOP的概念):

    void oop_field_store(oop* field, oop new_value) {  
        pre_write_barrier(field); // 写屏障-写前操作
        *field = new_value; 
        post_write_barrier(field, value);  // 写屏障-写后操作
    }
    
    (1) 写屏障 + SATB

    当对象B的成员变量的引用发生变化时(objB.fieldD = null;),我们可以利用写屏障,将B原来成员变量的引用对象D记录下来(保存到一个集合中):

    void pre_write_barrier(oop* field) {
        oop old_value = *field; // 获取旧值
        remark_set.add(old_value); // 记录 原来的引用对象
    }
    

    【当原来成员变量的引用发生变化之前,记录下原来的引用对象】
    这种做法的思路是:尝试保留开始时的对象图,即原始快照(Snapshot At The Beginning,SATB),当某个时刻 的GC Roots确定后,当时的对象图就已经确定了。
    重新标记阶段,再将集合中的对象重新标记为黑色,那么此时就不会回收这些对象了,但是会产生浮动垃圾(比如objA.fieldB = null此时也会记录该操作,B对象不会被回收)

    SATB破坏了条件一:【灰色对象 断开了 白色对象的引用】,从而保证了不会漏标。

    应用
    垃圾回收器G1默认机制,优点是效率较高,但会产生浮动垃圾

    (2) 写屏障 + 增量更新

    当对象A的成员变量的引用发生变化时(objA.fieldD = D;),我们可以利用写屏障,将A新的成员变量引用对象D记录下来(保存到一个集合中):

    void post_write_barrier(oop* field, oop new_value) {  
      if($gc_phase == GC_CONCURRENT_MARK && !isMarkd(field)) {
          remark_set.add(new_value); // 记录新引用的对象
      }
    }
    

    【当有新引用插入进来时,记录下新的引用对象】
    这种做法的思路是:不要求保留原始快照,而是针对新增的引用,将其记录下来等待遍历,即增量更新(Incremental Update)。
    重新标记阶段,再将集合中的对象重新扫描标记一遍,那么此时就获取了最终的对象图,也不会产生浮动垃圾。

    增量更新破坏了条件二:【黑色对象 重新引用了 该白色对象】,从而保证了不会漏标。

    应用
    垃圾回收器CMS默认机制,优点不会产生浮动垃圾,但效率较低。

    读屏障

    oop oop_field_load(oop* field) {
        pre_load_barrier(field); // 读屏障-读取前操作
        return *field;
    }
    

    读屏障是直接针对第一步:var D = objB.fieldD;;,当读取成员变量时,一律记录下来:

    void pre_load_barrier(oop* field, oop old_value) {  
      if($gc_phase == GC_CONCURRENT_MARK && !isMarkd(field)) {
          oop old_value = *field;
          remark_set.add(old_value); // 记录读取到的对象
      }
    }
    

    这种做法是保守的,但也是安全的。因为条件二中【黑色对象 重新引用了 该白色对象】,重新引用的前提是:得获取到该白色对象,此时已经读屏障就发挥作用了。

    为什么G1用SATB?CMS用增量更新?
    我的理解:SATB相对增量更新效率会高(当然SATB可能造成更多的浮动浮动垃圾),因为不需要在重新标记阶段深度扫描被删除引用对象,而CMS对增量引用的根对象会做深度扫描,G1因为很多对象都位于不同的region,CMS就一块老年代区域,重新扫描的话G1代价会比CMS高,所以G1选择SATB不深度扫描对象,只是简单的标记,等到下一轮GC再做深度扫描。

    更多相关内容
  • 垃圾回收问题1、三色标记法1.1 基本算法1.2 多标-浮动垃圾1.3 漏标-读写屏障1.3.1 写屏障(Store Barrier)(1) 写屏障 + SATB(2) 写屏障 + 增量更新1.3.2 读屏障(Load Barrier)1.4 三色标记法与现代垃圾回收器 ...


    读写屏障涉及到JVM和并发编程的知识,但是其概念又相差较多,容易混淆

    一、并发问题

    链接: 内存屏障中的读写屏障——并发问题.

    二、 垃圾回收问题

    关于垃圾回收算法,基本就是那么几种:标记-清除、标记-复制、标记-整理。在此基础上可以增加分代(新生代/老年代),每代采取不同的回收算法,以提高整体的分配和回收效率。
    无论使用哪种算法,标记总是必要的一步。这是理算当然的,你不先找到垃圾,怎么进行回收?

    垃圾回收器的工作流程大体如下:

    标记出哪些对象是存活的,哪些是垃圾(可回收);
    进行回收(清除/复制/整理),如果有移动过对象(复制/整理),还需要更新引用。
    本文着重来看下标记的部分。

    1、三色标记法

    1.1 基本算法

    要找出存活对象,根据可达性分析,从GC Roots开始进行遍历访问,可达的则为存活对象:
    在这里插入图片描述

    最终结果:A/D/E/F/G 可达
    我们把遍历对象图过程中遇到的对象,按“是否访问过”这个条件标记成以下三种颜色:

    • 白色:尚未访问过。
    • 黑色:本对象已访问过,而且本对象 引用到 的其他对象 也全部访问过了。
    • 灰色:本对象已访问过,但是本对象 引用到 的其他对象 尚未全部访问完。全部访问后,会转换为黑色。

    在这里插入图片描述
    假设现在有白、灰、黑三个集合(表示当前对象的颜色),其遍历访问过程为:

    • 初始时,所有对象都在 【白色集合】中;
    • 将GC Roots 直接引用到的对象 挪到 【灰色集合】中;
    • 从灰色集合中获取对象:
      • 将本对象 引用到的 其他对象 全部挪到 【灰色集合】中;
      • 将本对象 挪到 【黑色集合】里面。
    • 重复步骤3,直至【灰色集合】为空时结束。
    • 结束后,仍在【白色集合】的对象即为GC Roots 不可达,可以进行回收。

    注:如果标记结束后对象仍为白色,意味着已经“找不到”该对象在哪了, 不可能会再被重新引用。

    当Stop The World (以下简称 STW)时,对象间的引用 是不会发生变化的,可以轻松完成标记。
    而当需要支持并发标记时,即标记期间应用线程还在继续跑,对象间的引用可能发生变化,多标和漏标的情况就有可能发生

    1.2 多标-浮动垃圾

    假设已经遍历到E(变为灰色了),此时应用执行了 objD.fieldE = null :
    在这里插入图片描述
    D > E 的引用断开
    此刻之后,对象E/F/G是“应该”被回收的。然而因为E已经变为灰色了,其仍会被当作存活对象继续遍历下去。最终的结果是:这部分对象仍会被标记为存活,即本轮GC不会回收这部分内存。

    这部分本应该回收 但是 没有回收到的内存,被称之为“浮动垃圾”。浮动垃圾并不会影响应用程序的正确性,只是需要等到下一轮垃圾回收中才被清除。

    另外,针对并发标记开始后的新对象,通常的做法是直接全部当成黑色,本轮不会进行清除。这部分对象期间可能会变为垃圾,这也算是浮动垃圾的一部分。

    1.3 漏标-读写屏障

    假设GC线程已经遍历到E(变为灰色了),此时应用线程先执行了:

    var G = objE.fieldG; 
    objE.fieldG = null;  // 灰色E 断开引用 白色G 
    objD.fieldG = G;  // 黑色D 引用 白色G
    

    在这里插入图片描述
    E > G 断开,D引用 G
    此时切回GC线程继续跑,因为E已经没有对G的引用了,所以不会将G放到灰色集合;尽管因为D重新引用了G,但因为D已经是黑色了,不会再重新做遍历处理。
    最终导致的结果是:G会一直停留在白色集合中,最后被当作垃圾进行清除。这直接影响到了应用程序的正确性,是不可接受的。

    不难分析,漏标只有同时满足以下两个条件时才会发生:

    • 条件一:灰色对象 断开了 白色对象的引用(直接或间接的引用);即灰色对象 原来成员变量的引用 发生了变化。
    • 条件二:黑色对象 重新引用了 该白色对象;即黑色对象 成员变量增加了 新的引用。

    从代码的角度看:

    var G = objE.fieldG; // 1.读
    objE.fieldG = null;  // 2.写
    objD.fieldG = G;     // 3.写
    
    • 读取 对象E的成员变量fieldG的引用值,即对象G;
    • 对象E 往其成员变量fieldG,写入 null值。
    • 对象D 往其成员变量fieldG,写入 对象G ;

    我们只要在上面这三步中的任意一步中做一些“手脚”,将对象G记录起来,然后作为灰色对象再进行遍历即可。比如放到一个特定的集合,等初始的GC Roots遍历完(并发标记),该集合的对象 遍历即可(重新标记)。

    重新标记通常是需要STW的,因为应用程序一直在跑的话,该集合可能会一直增加新的对象,导致永远都跑不完。当然,并发标记期间也可以将该集合中的大部分先跑了,从而缩短重新标记STW的时间,这个是优化问题了。

    写屏障用于拦截第二和第三步;而读屏障则是拦截第一步。
    它们的拦截的目的很简单:就是在读写前后,将对象G给记录下来。

    1.3.1 写屏障(Store Barrier)

    给某个对象的成员变量赋值时,其底层代码大概长这样:

    /**
    * @param field 某对象的成员变量,如 D.fieldG
    * @param new_value 新值,如 null
    */
    void oop_field_store(oop* field, oop new_value) { 
        *field = new_value; // 赋值操作
    } 
    

    所谓的写屏障,其实就是指在赋值操作前后,加入一些处理(可以参考AOP的概念):

    void oop_field_store(oop* field, oop new_value) {  
        pre_write_barrier(field); // 写屏障-写前操作
        *field = new_value; 
        post_write_barrier(field, value);  // 写屏障-写后操作
    }
    
    (1) 写屏障 + SATB

    当对象E的成员变量的引用发生变化时(objE.fieldG = null;),我们可以利用写屏障,将E原来成员变量的引用对象G记录下来:

    void pre_write_barrier(oop* field) {
        oop old_value = *field; // 获取旧值
        remark_set.add(old_value); // 记录 原来的引用对象
    }
    

    【当原来成员变量的引用发生变化之前,记录下原来的引用对象】
    这种做法的思路是:尝试保留开始时的对象图,即原始快照(Snapshot At The Beginning,SATB),当某个时刻 的GC Roots确定后,当时的对象图就已经确定了。
    比如 当时 D是引用着G的,那后续的标记也应该是按照这个时刻的对象图走(D引用着G)。如果期间发生变化,则可以记录起来,保证标记依然按照原本的视图来。

    值得一提的是,扫描所有GC Roots 这个操作(即初始标记)通常是需要STW的,否则有可能永远都扫不完,因为并发期间可能增加新的GC Roots。

    SATB破坏了条件一:【灰色对象 断开了 白色对象的引用】,从而保证了不会漏标。

    一点小优化:如果不是处于垃圾回收的并发标记阶段,或者已经被标记过了,其实是没必要再记录了,所以可以加个简单的判断:

    void pre_write_barrier(oop* field) {
      // 处于GC并发标记阶段 且 该对象没有被标记(访问)过
      if($gc_phase == GC_CONCURRENT_MARK && !isMarkd(field)) { 
          oop old_value = *field; // 获取旧值
          remark_set.add(old_value); // 记录  原来的引用对象
      }
    }
    
    (2) 写屏障 + 增量更新

    当对象D的成员变量的引用发生变化时(objD.fieldG = G;),我们可以利用写屏障,将D新的成员变量引用对象G记录下来:

    void post_write_barrier(oop* field, oop new_value) {  
      if($gc_phase == GC_CONCURRENT_MARK && !isMarkd(field)) {
          remark_set.add(new_value); // 记录新引用的对象
      }
    }
    

    【当有新引用插入进来时,记录下新的引用对象】
    这种做法的思路是:不要求保留原始快照,而是针对新增的引用,将其记录下来等待遍历,即增量更新(Incremental Update)。

    增量更新破坏了条件二:【黑色对象 重新引用了 该白色对象】,从而保证了不会漏标。

    1.3.2 读屏障(Load Barrier)
    oop oop_field_load(oop* field) {
        pre_load_barrier(field); // 读屏障-读取前操作
        return *field;
    }
    

    读屏障是直接针对第一步:var G = objE.fieldG;,当读取成员变量时,一律记录下来:

    void pre_load_barrier(oop* field, oop old_value) {  
      if($gc_phase == GC_CONCURRENT_MARK && !isMarkd(field)) {
          oop old_value = *field;
          remark_set.add(old_value); // 记录读取到的对象
      }
    }
    

    这种做法是保守的,但也是安全的。因为条件二中【黑色对象 重新引用了 该白色对象】,重新引用的前提是:得获取到该白色对象,此时已经读屏障就发挥作用了。

    1.4 三色标记法与现代垃圾回收器

    现代追踪式(可达性分析)的垃圾回收器几乎都借鉴了三色标记的算法思想,尽管实现的方式不尽相同:比如白色/黑色集合一般都不会出现(但是有其他体现颜色的地方)、灰色集合可以通过栈/队列/缓存日志等方式进行实现、遍历方式可以是广度/深度遍历等等。

    对于读写屏障,以Java HotSpot VM为例,其并发标记时对漏标的处理方案如下:

    • CMS:写屏障 + 增量更新
    • G1:写屏障 + SATB
    • ZGC:读屏障
      工程实现中,读写屏障还有其他功能,比如写屏障可以用于记录跨代/区引用的变化,读屏障可以用于支持移动对象的并发执行等。功能之外,还有性能的考虑,所以对于选择哪种,每款垃圾回收器都有自己的想法。

    值得注意的是,CMS中使用的增量更新,在重新标记阶段,除了需要遍历 写屏障的记录,还需要重新扫描遍历GC Roots(当然标记过的无需再遍历了),这是由于CMS对于astore_x等指令不添加写屏障的原因,具体可参考这里。

    参考资料
    维基百科:Tracing_garbage_collection#Tri-color_marking
    R大在谈G1时提到的SATB,本文代码参考出处
    《深入理解Java虚拟机》第三版
    《新一代垃圾回收器ZGC设计与实现》
    黑马程序员JUC并发
    链接:https://www.jianshu.com/p/12544c0ad5c1.

    展开全文
  • 目录为什么要有写屏障1、Store Buffer提升MESI性能2、Store Buffer导致读写乱序3、写屏障总结 关于内存屏障,我翻阅了很多文章,都没有给人讲的比较明白,因为我看了许多文章之后,仍然有以下几个疑问: 为什么要有...

    《内存屏障(Memory Barrier)(一)什么是写屏障?》
    《内存屏障(Memory Barrier)(二)什么是读屏障?》
    《内存屏障(Memory Barrier)(三)volatile关键字是怎么实现的?》


    关于内存屏障,我翻阅了很多文章,都没有给人讲的比较明白,因为我看了许多文章之后,仍然有以下几个疑问:

    • 为什么要有内存屏障?
    • 什么是LoadLoad,LoadStore,StoreStore,StoreLoad?他们之间的区别到底是什么?
    • 写屏障和读屏障有什么不同?

    带着这样的疑问,在这一系列文章中,我想从原理开始一点一点说清楚。

    为什么要有写屏障

    1、Store Buffer提升MESI性能

    之前我们在说MESI缓存一致性协议中,说过,如果CPU0更新了数据,要通知CPU1置为失效,其图示如下:

    缓存一致性图片
    那么在这个时间点中,cpu0要一直等待到cpu1的返回,才能执行赋值操作,此时MESI缓存一致性协议的效率就非常低了,此时,是通过中间加入了一层Store Buffer来提升缓存一致性的性能,图示如下:
    StoreBuffer
    此时数据先写入Store Buffer,等到收到AcKnowledgement的时候,再把数据刷入缓存。

    但是这个时候还有一个问题,写数据走了Store Buffer,如果读取的时候不走Store Buffer直接走cache,不就导致数据不一致了么,所以,读要同时走cache和Store Buffer。图示如下:
    cup读Store

    2、Store Buffer导致读写乱序

    有了Store Buffer,性能得到了提升,不过你看看下面一种情况:
    读写两cpu

    • cup0:先写了a=1,再写了b=1
    • cpu1:先读了b,再读了a。

    这种情况下,按理来说,因为是先写a,再写b,那么读取的时候,一定是b的值变了,a的值也会变。

    但是因为Store Buffer的存在,最后确是未必,

    1. a的值可能因为是Share(共享)先被写入了Store Buffer,并发送通知其他cpu置为Invalid(失效)
    2. b的值,可能因为在cache中已经存在并且是Exclusive(独占)直接被写进cache中。
    3. 读取的时候因为先读b的值,b被刷进主存供读取
    4. 后面要读a,因为还没收到失效通知,从cache中直接拿到a,断言失败。

    其实上面四步的逻辑你看不懂也没关系,因为我有时候脑子也会乱,你只要记得是因为Store Buffer导致读写的顺序不一致即可,这里说明是为了方便你的理解。

    3、写屏障

    上面的例子,如果在写a=1之后,加入一层写屏障,让a=1的结果等到收到其他cpu返回通知,并写入cache后,就可以解决。就变成这样:

    a=1;
    写屏障
    b=1;
    

    这就是写屏障的作用。

    总结

    我们这篇文章说了

    • 通过引入Store Buffer 提升了MESI的性能
    • 引入Store Buffer后导致读写乱序
    • 通过写屏障,来保证写的顺序
    展开全文
  • 写屏障是指 编译器在编译期间生成一段代码,该代码可以拦截用户程序的内存读写操作,在用户程序操作之前执行一个 hook 函数,根据 hook 函数的不同,分为 Dijkstra 插入写屏障 和 Yuasa 删除写屏障。 需要注意的是...

    垃圾回收简称 GC,就是对程序中不再使用的内存资源进行自动回收释放的操作。

    常见的垃圾回收算法

    引用计数:每个对象维护一个 引用计数,当对象被创建或被其他对象引用时,计数 +1;如果引用该对象的对象被销毁时,计数 -1 ;当计数为 0 时,回收该对象。

    • 优点:对象可以很快被回收,不会出现内存耗尽或到达阀值才回收。
    • 缺点:不能很好的处理循环引用;需要实时维护计数引用。

    标记-清除:从根变量开始遍历所有引用的对象,引用的对象会被标记,没有被标记的则进行回收。

    • 优点:解决了引用计数的缺点;
    • 缺点:需要 STW(stop the world),暂时停止程序运行。

    分代收集:按照对象生命周期长短划分不同的代空间,生命周期长的放入老年代,短的放入新生代,不同代有不同的回收算法和回收频率。

    • 优点:回收性能好;
    • 缺点:算法复杂。

    go1.3 版本之前使用的是 标记-清除 算法,但是执行该算法时,需要停掉用户程序(STW),即保证 GC 和 用户程序 是串行 的。这种算法简单,但是会严重影响用户程序的执行。

    go1.5 版本开始后提出了 三色标记法,它优化了标记过程,同时结合 屏障技术 极大的缩短了 STW 的时间,让 用户程序 和 GC 在 标记和清除阶段 可以并行运行。

    三色标记法

    三色抽象

    三色抽象定义了三种不同类型的对象,并用不同的颜色相称:

    • 白色:未搜索的对象,在回收周期开始时所有对象都是白色,在回收周期结束时所有的白色都是垃圾对象
    • 灰色:正在搜索的对象,该类对象可能还存在外部引用对象
    • 黑色:已搜索完的对象,这类对象不再有外部引用对象

    标记流程

    1、初始状态下所有对象都是 白色 的;

    2、从 根节点对象 开始遍历所有对象,把遍历到的对象变成 灰色,放入待处理队列;

    3、遍历所有灰色对象,将遍历到的灰色对象变成 黑色,同时将它引用的对象变成灰色并加入到待处理队列;

    4、循环步骤3,直到 待处理队列为空(所有灰色对象都变为黑色);

    5、剩下没有被标记的 白色 对象就认为是垃圾对象。

    其中,根节点对象 主要指执行 GC 时刻所有的 全局对象栈上的对象(函数参数与内部变量)。

    并发问题:

    如果仅按以上的标记清除过程处理,在没有用户程序并发修改对象引用的情况下,回收可以正常结束。但如果用户态程序在标记阶段更新了对象引用关系,就可能会导致问题的出现:

    用以上过程为例,在 A 对象已经被标记为 黑色 后,用户程序修改了引用关系,将 A 对象 引用到 白色对象 E,而此时 A对象 已经被标记为黑色,gc 扫描不会再对它进行处理,最后,E 对象就会被错误的清除。

    怎么防止以上问题的出现呢?

    首先,出现该问题是因为在 GC 执行的时候,用户程序并发的修改了对象引用关系,而且,修改的引用关系 同时满足 以下两个条件:

    1. 黑色对象引用了白色对象;
    2. 该白色对象没有被其他灰色对象引用 或者 灰色对象与它之间的可达关系遭到破坏。

    解决方法是实现以下 三色不变式:

    • 强三色不变式:黑色节点不允许引用白色节点,破坏了条件一。
    • 弱三色不变式:黑色节点允许引用白色节点,但是该白色节点必须有其他灰色节点的引用或间接引用,破坏了条件二。

     怎么实现呢?

    一个直观的想法就是在用户程序修改对象引用关系的时候,在相关对象上做点手脚,以此来破坏以上 2 个条件同时产生,这其实就是 写屏障 干的事。

    写屏障是指 编译器在编译期间生成一段代码,该代码可以拦截用户程序的内存读写操作,在用户程序操作之前执行一个 hook 函数,根据 hook 函数的不同,分为 Dijkstra 插入写屏障 Yuasa 删除写屏障

    需要注意的是,基于对栈空间实现写屏障产生的性能损耗和实现复杂度的考虑,go 没有对 栈空间对象 使用写屏障。

    写屏障(Write Barrier)

    Dijistra 插入写屏障

    // 当前下游对象 slot, 新下游对象 ptr
    func writePointer(slot *unsafe.Pointer, ptr unsafe.Pointer) {
        shade(ptr); // 将新引用对象 ptr 标记为灰色
        *slot = ptr; 
    }

    堆对象 增加引用对象的时候,先把该引用对象置为 灰色,这样就可以保证不会有黑色对象引用白色对象,满足 强三色不变式

    但是因为栈空间对象是没有写屏障的,因此,在标记过程中,可能出现 黑色的栈对象 引用到 白色对象 的情况,所以在一轮三色标记完成后 需要开启 STW,重新对 栈上的对象 进行三色标记。

    图解:

    在 A 、C 对象已经被标记为 黑色 后,用户程序执行 A.ref = E , C.ref = G ,

    因为 A 属于栈对象, 因此不会对它新增的引用对象做处理, 因此,E 为 白色

    而 C 属于堆对象,按照屏障函数的处理,要将它引用的对象 G 着为 灰色

    本轮标记结束后,E 对象保持为白色,因此,还要开启 STW,对 栈区 重新做一次三色标记

    Yuasa 删除写屏障

    // 当前下游对象 slot, 新下游对象 ptr
    func writePointer(slot *unsafe.Pointer, ptr unsafe.Pointer) {
        shade(*slot); // 将当前引用对象 *slot 标记为灰色
        *slot = ptr;  
    }

    在删除某对象的引用对象时,针对 被删除的对象,如果自身为灰色,则不用处理,如果为白色,那么将该对象标记为灰色,满足 弱三色不变式

    图解:

    1、A 、D 对象为 黑色,B、E 为 灰色 ,其他对象为白色;

    2、用户程序执行 B.ref = nil , E.ref = C,按照屏障函数处理:删除对白色对象 的引用,要将白色对象着为灰色,因此执行 B.ref = nil 要将 C 对象被着为 灰色; F 同理;

    3、继续三色标记;

    4、最后 F 和 G 对象 也会被标记为黑色而保留至下一轮,虽然它们已然可以被清理。

    可以看到,删除写屏障有两个缺点:

    1. 回收精度低:因为该方法保守的认为所有被删除的节点将来可能会被黑色节点引用,因此在删除的时候要将其置为灰色,而这个节点可能再也不会被其他节点引用,从而导致该节点以及它引用下的其他节点都在本轮 gc 后被保留下来,要待到下轮 gc 才可以被清除。
    2. 必须在 gc 开启时执行 STW,扫描根集合,保证所有堆上在用的对象要么为灰色,要么处于灰色保护下,即保证 根黑,下一级在堆上的全灰。

    第 2 点 讲的是什么鬼,首先 举个反例

    A、B 属于两个不同的协程栈对象,假如现在不在 gc 开始前扫描整个栈区,可能出现:

    1、扫描 g1 栈对象,执行三色标记,将 A、C 标记为黑色后;

    2、扫描 g2 栈对象,将 B 标记为灰色,然后执行用户程序代码 B.C.ref = D, B.ref = nil因为 栈区没有实现写屏障,因此,B 删除 对 D 的引用后 D仍然为白色;

    3、继续三色标记,因为 C 已经为黑色对象,不会再被扫描,导致最后 D、G 始终保持为白色而被删除。

    再来看下 正确的过程

    先扫描根集合,使 A、B 栈节点都变为黑色,C、D 堆节点变为灰色,堆区其他所有节点都处于灰色节点的可达链路上,这样就可以保证以后即使 B 删除了对 D 对象的引用后,G 对象也不会被清除。

    正反例都举完了,你可能还存在一个疑问,在执行过程中,如果用户代码 new 了一个对象,并且被某个黑色节点引用,比如, A.ref = new(F),  那这个新构建的对象不是也会被误删。

    其实,这个时候我们回过头来想想,这个 F 对象如果没有发生逃逸,它会是一个栈对象,那在 gc 开始时就会被扫黑,如果这个 F 对象发生了逃逸,是一个堆对象,那么它也会因为 A 被扫黑的过程中成为了一个灰色对象。

    感觉有点废话,但是我曾经脑补过这场景,想了好久才想明白。

    混合写屏障

    回顾一下,单独的写屏障都有各自的缺陷:

    插入写屏障 需要在一轮标记结束后执行 STW,重新对栈区执行一次扫描标记;

    删除写屏障 需要在 gc 开始阶段扫描整个栈,生成起始快照。

    在 go 1.8 版本引入了 混合写屏障技术,集两种写屏障各自的优点于一身。

    // 当前下游对象 slot, 新下游对象 ptr
    writePointer(slot, ptr){
        shade(*slot)  // 对应删除写屏障,将当前引用对象 *slot 标记为灰色
        shade(ptr)    // 对应插入写屏障,将新引用对象 ptr 标记为灰色
        *slot = ptr
    } 

    针对 栈区 和 堆区 分别采用以下策略处理:

    栈区:

    栈上对象全部扫描标记为黑色(每个栈单独扫描,无需 STW 整个程序,停止单个扫描栈即可);

    GC 期间,任何在栈上创建的新对象,均为黑色(不用再对栈重新扫描);

    堆区:

    被删除的对象标记为灰色(删除写屏障);

    被添加的对象标记为灰色(插入写屏障)。

    gc 触发时机

    gcTriggerHeap:堆内存的分配达到控制器计算的触发堆大小,初始大小环境变量 GOGC,之后堆内存达到上一次垃圾收集的 2 倍时才会触发GC;

    gcTriggerTime:距离上一次垃圾回收超过一定阈值时,该时间由 runtime.forcegcperiod 变量控制,默认为 2 分钟。

    gcTriggerCycle: 要求启动新一轮的GC, 已启动则跳过, 手动触发GC的runtime.GC()会使用这个条件。

    展开全文
  • 弄懂Golang GC、三色标记、混合写屏障机制
  • 内存屏障中的读写屏障——并发问题一、并发问题1、概述2、Volatile...声明写屏障后,写屏障之前的代码都会同步到主存当中,保证之后的线程读到的都是最新的; 2.2、保证有序性 但是Volatile无法解决指令交错:
  • 【JVM】三色标记法与读写屏障

    千次阅读 2020-05-24 10:54:22
    对于读写屏障,以Java HotSpot VM为例,其并发标记时对漏标的处理方案如下: CMS:写屏障 + 增量更新 G1:写屏障 + SATB ZGC:读屏障 工程实现中,读写屏障还有其他功能,比如写屏障可以用于记录跨代/区引用的变化...
  • } 应用写屏障后,虚拟机就会为所有赋值操作生成相应的指令,一旦收集器在写屏障中增加了更新卡表操作,无论更新的是不是老年代对新生代对象的引用,每次只要对引用进行更新,就会产生额外的开销,不过这个开销与...
  • 一、Go垃圾回收发展历史 1.3之前:原始的标记清除算法(mark and sweep) 1.3 减少STW暂停的时间范围 1.5 三色并发标记 1.8 混合写屏障(hybrid write barrier)机制
  • 面试官上来就让讲Golang GC, 我道袍一挥,气定神闲,还好提前准备了,把三色标记法,屏障机制等信手拈来,把面试官镇住了.....
  • 不停的重复这一步直至灰色集合为空 4、删除白色对象 上面就是最原始的三色标记法流程,但是在gc过程中也会有新的对象产生或者关联,就会可能出现无法删除或者无法保护的情况了 这时候就需要写屏障了 二.屏障机制 1....
  • 设置为灰色,因为SATB关注的是引用的删除,将 o1.filed = new O2() 修改为o1.field = null 这种,会将O2对象置为灰色,加入操作栈,重新进行扫描,解决漏标问题 写屏障: SATB记录的是删除引用的对象,通过写屏障来...
  • 来源 |奇伢云存储责编 | 晋兆雨图片来源 | CSDN 下载自视觉中国大纲插入写屏障删除写屏障混合写屏障golang 混合写屏障实现源码文件写屏障代码触发点对象置灰暂停 gorout...
  • Go GC 写屏障

    2020-08-10 13:12:47
    1.插入屏障:A指向B,将B标记为灰色 注意:栈区B不会被标为灰色,堆区才会 缺点:标记完需要STW,扫描栈区重新标记 2.删除屏障:A不在指向B,将B标记为灰色 注意:栈区B不会被标记为灰色,堆区才会 缺点:B可能不会...
  • 再谈HotSpot JVM GC机制中的写屏障

    千次阅读 多人点赞 2020-05-05 23:48:54
    HotSpot通过写屏障(write barrier)来维护卡表。我们已经知道,内存屏障的主要作用是防止指令重排序,它也是volatile关键字的基础。有了写屏障,JVM就可以保证引用发生改变时,对卡表中的卡做标记与访问内存的顺序...
  • Golang 三色标记、混合写屏障GC模式图文全分析 垃圾回收(Garbage Collection,简称GC)是编程语言中提供的自动的内存管理机制,自动释放不需要的对象,让出存储器资源,无需程序员手动执行。 Golang中的垃圾回收主要...
  • 引言:在JVM中,使用到了记忆集这种数据...大家都知道,在Spring框架中,采用了AOP来增强Bean实例的方法,写屏障技术和AOP技术类似,AOP技术在方法的前后增加特定的环节来增强目标方法的功能,写屏障技术在写操作的前后
  • 文章目录golang 混合写屏障插入写屏障删除写屏障混合写屏障golang 混合写屏障实现源码文件写屏障代码触发点`runtime·gcWriteBarrier``wbBufFlush`置灰暂停 goroutine,栈扫描`scanstack`抢占调度`newstack`总结 ...
  • 插入写屏障 伪代码 对象丢失的必要条件 写屏障是怎么解决问题? 并发的垃圾回收 golang 语言设计的根本性追求就是高并发,低延迟,所以golang 的垃圾回收也是持续在优化。golang 的垃圾回收是并发垃圾回收设计,...
  • 你显然已经知道,分代垃圾收集器需要扫描被老对象引用的新对象,扫描所有的老对象看起来很合适,但是破坏了某些分代的优势,所以你需要慢慢淡忘它。卡表是一种取舍: 告诉
  • 写屏障与记忆集: 每次在对一个对象引用进行赋值的时候,会产生一个写屏障中断操作,然后检查将要写入的引用指向的对象是否和该引用当前指向的对象处在不同的region中;如果不同,通过CardTable将相关的引用信息...
  • 接上一篇 golang 垃圾回收的梳理,这篇讲删除写屏障,golang 的内存写屏障是由插入写屏障到混合写屏障过渡的。虽然 golang 从来没有直接使用删除写屏障,但是混合写屏障却用到了删除写屏障的思路。 删除写屏障:也...
  • 整理自:Golang中GC回收机制三色标记与混合写屏障 目标 理解Golang中GC垃圾回收机制 Go v1.3 v1.3之前的标记-清除(mark and sweep)方法 步骤: 第一步:暂停业务逻辑,找出不可达的对象和可达的对象; 第二步:开始...
  • 三色标记法与读写屏障 路过的猪关注 12020.02.14 17:16:39字数 2,694阅读 5,217 前言 本文主要介绍了三色标记法的基本思路、多标导致的浮动垃圾、漏标的处理方案(读写屏障)等。 1. 垃圾回收的简单回顾 ...
  • 并发标记的主要问题是垃圾回收器在标记对象的过程中,用户线程可能正在改变对象引用关系图,从而造成漏标和错标。... 四、写屏障 以上无论是对引用关系记录的插入还是删除,虚拟机的记录操作都是通过写屏障实现的。
  • Golang三色标记GC和混合写屏障笔记功能快捷键合理的创建标题,有助于目录的生成如何改变文本的样式插入链接与图片如何插入一段漂亮的代码片生成一个适合你的列表创建一个表格设定内容居中、居左、居右SmartyPants...
  • 本文将系统的详细介绍Golang中GC的全分析过程,包括垃圾回收的方式递进。 内容包括: G0 V1.3之前的标记-清除(mark ...三色不变式、插入屏障、删除屏障 ) Go V1.8混合写屏障机制 * Go V1.8混合写屏障机制的全场景分析
  • 由于Golang的GC机制一直在持续迭代,本文叙述的主要是Go1.9版本及以后的GC机制,该版本中Golang引入了 混合写屏障大幅度地优化了STW的时间。具体GC机制的版本迭代可以参考 :GC的过去、现在和未来 基本概念 GC的...
  • 什么是锁缓存:MESI一致性协议+读写屏障,数据读写就变成强一致性的了 锁缓存就是MESI一致性协议+读写屏障 什么时候用总线锁,什么时候用缓存锁:操作的数据大于64字节时 第三部分,问题一的解答 ...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 44,346
精华内容 17,738
关键字:

写屏障