国外做珠宝的网站有哪些,北京网站制建设公司,网上做效果图网站有哪些软件,厦门网站建设哪家不错这里是Z哥的个人公众号每周五11#xff1a;45 按时送达当然了#xff0c;也会时不时加个餐#xff5e;我的第「203」篇原创敬上大家好#xff0c;我是 Z 哥。今天带来一篇久违的技术型文章。之前也有不少小伙伴会问#xff0c;Z 哥你好久没发技术性文章了。其实主要原因有… 这里是Z哥的个人公众号每周五1145 按时送达当然了也会时不时加个餐我的第「203」篇原创敬上大家好我是 Z 哥。今天带来一篇久违的技术型文章。之前也有不少小伙伴会问Z 哥你好久没发技术性文章了。其实主要原因有以下几点。第一目前的工作偏业务以及管理的确在技术上的精力投入不如之前那么多。这也限制了自己在纯技术性方面的知识输出。第二虽然自己在工作之余也会有一部分精力专门用于技术学习但是大多是以新技术、新框架等的了解、熟悉为主。涉及到的知识 Level 相对比较浅就算发出来对大家的帮助也不大就没发。第三从长远来看自己也不想太把自己局限在技术的圈子里。因为在我看来技术只是一门手艺是吃饭的家伙但是吃饭的家伙从来都不仅仅是技术还有很多其它的方面。甚至其中很多事情不像具体的技术细节那样「标准化」有很多是通过血汗积累的「非标准化」经验我认为这些经验的价值不亚于技术知识。因此作为有志与大家交朋友的 Z 哥自然就不想把自己局限在「技术」这个小圈子里。好了回到本文的正题。最近正好在学习 Golang对它的里面用到的三色标记法的 GC 机制有些好奇最开始是因为名字让我联想到了三色杯冷饮就稍微多深入了解了一下在这里分享出来或许将来对你面试啥的有些帮助。/01 判断对象存活的思路/在 GC 领域里判断对象存活的主流思路是两个「引用计数」和「可达性分析」。01 引用计数顾名思义引用计数的思路就是给每个对象进行计数每被其它对象引用一次计数就 1引用失效后计数就 -1。当计数器的数值为 0就意味着它没有被使用可以回收。02 可达性分析可达性分析的思路就是通过引用链路判断对象是否可被触达如果能触达说明该对象当前正在被使用不可回收反之没有触达到的对象则认为是无使用的可以回收。这个引用链路的结构类似于有向有环图但是根节点不止一个是一个集合称之为 GCRoots。 目前主流的 GC 机制大多用的是「可达性分析」这条路线。Go、Java、.Net等都是如此。为什么引用计数不好用呢因为它有一个特别严重的问题无法处理循环引用。像上图这样的情况引用计数永远不为 0这些对象就永远不会被回收这会严重影响回收的效果。但是它也并不是一无是处它的回收实时性效果更好可以配合「可达性分析」一起使用发挥各自的优点在不同的场景下使用不同的策略。由于「可达性分析」思路是主流所以后续发展出来的很多回收算法都以这个思路为基础的三色标记法就是其中之一。我们今天主要来聊聊它。/02 三色标记法/在讲具体原理之前先了解一个概念「Stop The World 」简称「STW」。垃圾回收器的工作流程大体如下标记出哪些对象是存活的哪些是可回收的。进行回收清除/复制/整理。如果在回收期间有移动过的对象复制/整理还需要更新引用。第一步做标记的过程又可以分成两个步骤。标记 GC ROOT 能关联到的对象。这里会 STW。从 GCRoots 的直接关联对象开始遍历整个对象图。这里不会STW。垃圾回收算法主要做的就是第一步中的第二步三色标记法也不例外它将从GC Roots 开始遍历的对象标记为以下三种颜色白色初始值。本次回收没被扫描过的对象默认都是白色的。而确认不可达的对象也是白色但是会被标记「不可达」。灰色中间状态。本对象有被外部引用但是本对象引用的其它对象尚未全部检测完。黑色本对象有被其它对象引用且已检测完本对象引用的其它对象。其实这三种颜色是啥不重要的重要的是它们所表达的状态灰色的中间状态标记过程结束后只会存在白色或者黑色。整个过程中这些状态是如下图这样变化的。看似很完美的解决方案其实也存在的一个问题标记过程中对象引用发生了变化。它会导致两个问题「多标」和「漏标」。多标就是下图这样由于步骤2不会STW所以可能存在扫描过A将它标记为黑色后又重新引用了一个原本已经被标记为白色的DC断开了与D的引用。此时D就会被回收掉导致程序出现意料之外的bug。「漏标」就是这样对象 E/F/G 是“应该”被回收的。然而因为 E 已经变为灰色了其仍会被当作存活对象继续遍历下去。最终的结果是这部分对象仍会被标记为存活即本轮 GC 不会回收这部分内存。传统的解决这两个问题的思路有两个在断开引用的时候做额外处理。在「黑色」对象重新建立「白色」对象的引用时做额外处理。回收开始后新建的对象默认为黑色。第一个思路专业叫法是「写屏障」第二个是「读屏障」。其实名字就是噱头你可以把它们俩当我们平时编程中用到的 AOP 概念来理解在修改和读取之前做一些操作。基于「写屏障」可以延伸出两个方案增量更新Incremental Update。针对新增的引用将其记录下来等待重新遍历。这个操作在「修改操作后」进行JVM 中的 CMS 垃圾回收器就是这个思路。原始快照Snapshot At The BeginningSATB。当某个时刻 的 GC Roots 确定后当时的对象图就已经确定了。如果期间发生变化则可以记录起来保证标记依然按照原本的视图来。这个操作在「修改操作前」进行JVM中 的 G1 垃圾回收器用的就是这个思路。理论上配合 「Remembered Set」SATB 的效率是比增量更新要高的不过会消耗更多的内存。基于「读屏障」的方案是在「黑色」对象重新建立「白色」对象的引用前将这个白色对象记录下来避免被回收掉。这个动作在「读取操作前」进行JVM 中的 ZGC 垃圾回收器就是这个思路。在 Golang1.8版本之后里用的是一种新的机制称之为「混合写屏障」机制。它的思路总结下来就是4句话将对象分为堆上的对象和栈上的对象。GC 开始将栈上的对象全部扫描并标记为黑色无需 STW。并且之后不再进行第二次重复扫描在 GC 期间任何在栈上创建的新对象均为黑色。在 GC 期间在堆上被删除或者添加的对象都标记为灰色。后续继续扫描。你看其实这些原理也没那么复杂我相信只要你搞清楚了自己面对的是什么问题你也能想到这些方案。好了总结一下。这篇呢Z 哥和你分享了我对 Golang 中的 GC 机制「三色标记法」的了解。GC 的底层判断对象存活思路主要是两个引用计数和可达性分析。由于引用计数存在循环引用问题所以大多数 GC 都是按照后者的思路实现的Golang 也不例外。「三色标记法」的原理是将对象分为了三种状态白色默认值。本次回收没被扫描过的对象都是白色的。确认不可达的对象也是白色但是会被标记「不可达」。灰色中间状态。本对象有被外部引用但是本对象引用的其它对象尚未全部检测完。黑色本对象有被其它对象引用且已检测完本对象引用的其它对象。最终将白色状态的对象回收掉。为了解决其中会存在的漏标、多标问题它通过「混合写屏障」的机制来解决。思路是将对象分为堆上的对象和栈上的对象。GC 开始将栈上的对象全部扫描并标记为黑色无需 STW。并且之后不再进行第二次重复扫描在 GC 期间任何在栈上创建的新对象均为黑色。在 GC 期间在堆上被删除或者添加的对象都标记为灰色。后续继续扫描。希望对你有所帮助。推荐阅读如何做好知识管理一些微服务拆分的浅见原创不易如果你觉得这篇文章还不错就「点赞」或者「在看」一下吧鼓励我的创作 也可以分享我的公众号名片给有需要的朋友们。如果你有关于软件架构、分布式系统、产品、运营的困惑可以试试点击「阅读原文」
