这篇文章跟大家分析一下“golang 垃圾回收该如何分析”。内容详细易懂，对“golang 垃圾回收该如何分析”感兴趣的朋友可以跟着小编的思路慢慢深入来阅读一下，希望阅读后能够对大家有所帮助。下面跟着小编一起深入学习“golang 垃圾回收该如何分析”的知识吧。
现代编程语言一般都有垃圾回收功能。这个能极大的减轻程序员的负担，并且减少大部分场景的问题。要知道，c 语言里面最常见的就是踩内存，内存泄漏，野指针等问题。golang 作为一个新新语言，自然垃圾回收功能少不了的。当前 golang 的垃圾回收基于的理论是三色标记法，并且通过合理的使用内存屏障技术，把垃圾回收的 stw 几乎消灭（旁白：这个正确的理解，并不是没有 stw，只是非常非常短了）。
首先，内存稍高级的管理有两个方式，了解两个名词：
由于 c 语言自身设计的问题，无法实现 GC，所以 c 程序怎么管理内存呢？引用计数就是最常用的稍高级的管理方式。引用计数怎么用？常用姿势如下：
obj_ref(obj);{ do_something ; }obj_unref(obj);
引用计数 RC 的使用看上面非常简单，但其实是非常有讲究的，这里不深入了。此处还是由 golang 的垃圾回收展开。
golang 的垃圾回收我们经常听到三色标记法，三色指的是白色，灰色，黑色，分别表示三种状态，至于三色标记法的理论此处不表，我们从简单的理解切入。
首先，我们思考下一个不需要思考的问题：垃圾回收是做什么的？golang 为什么需要垃圾回收？
c 程序跑起来是需要内存的，栈内存由编译器来管理，堆内存由程序员来管理，这个就是 c 程序出内存问题的源头，程序员是人，是人就可能出错，各种编程人员的素质也是参差不齐，实际场景也是各种复杂的情况交织。
所以，我们回归本源问题，我们本质上只是想要一个内存而已，管理它只是迫不得已。内存用完了，程序员最好也不管。程序员只管用，不管回收。这个就会垃圾回收的由来。
我们再进一步，c 程序还需要程序员自己决定从栈上分配内存，还是堆上分配内存？
那么这个事情是程序员必须要做的吗？并不是，本质上程序只是需要一个对象，决定这个事情也是迫不得已。
golang 解决这个事情，就是对应的”逃逸分析“。逃逸分析解决一个问题，在保证 golang 程序正确性的前提下，在编译阶段决定对象的分配位置，栈上？堆上？
底线：golang 只需要保证一个点，回收的一定是不用的垃圾，那么就不会出功能性问题，回收的慢点一定程度都 ok 的。
怎么保证回收的一定是垃圾？首先看张图：
先说结论：
现在关键的问题是：这个黄色块怎么找出来的？
换个说法：你把在用的找明白，剩下的就是没在用的垃圾了。什么是在用的呢？从所有的根出发，只要是引用覆盖到的，就认为在用。
方法：从根处扫描，把所有的根扫描完，每个根扫描到底。按照之前的三色标记来说，扫描完了的是黑色，正在扫描的是灰色的，没扫描的是白色的。根扫描完了，那么最后只会剩下两种颜色的，黑色，白色。白色就是没用的垃圾，这种清理掉就没事。
问两个问题：
答案：
下面说另一个关键点：怎么扫描是安全的？
还真别说，golang 1.0 就是这么干的。这种实现非常简单也易于理解，但是无法适用于生产环境，你一停整个程序，就要暂停业务，一停就几秒，所以前期的 golang 根本就不能用呀。
所以呀，为了能够在线上生产场景使用，而不仅仅是个玩具，那么必须要做到垃圾回收不影响业务代码的运行才行。也就是并发喽（旁白：不并发也行，只要你能想到好办法，能做到：能回收垃圾，又不影响业务）？简单的并发就有要考虑的问题了，先说不安全的例子（扫描和业务并发）：
初始场景：
业务和扫描并发：
最后结果：
这白色的就是要被回收的，但我们一看就知道，有一个白色的被引用了，回收就野指针了，被回收掉就垮掉了。
怎么解决这个问题？接下来就是内存屏障出场了。golang 内存屏障也有一个演进过程：
先说屏障的本质：
屏障的作用：
关于golang 垃圾回收该如何分析就分享到这里啦，希望上述内容能够让大家有所提升。如果想要学习更多知识，请大家多多留意小编的更新。谢谢大家关注一下亿速云网站！
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
