平时在写代码的时候，关注的是写出能实现业务逻辑的代码，因为现在计算机的内存也比较宽裕，所以写程序的时候也就没怎么考虑垃圾回收这一方面的知识。俗话说，出来混总是要还的，所以既然每次都伸手向内存索取它的资源，那么还是需要知道什么时候以及如何把它还回去比较好。
一：垃圾回收机制的意义
java 语言中一个显著的特点就是引入了java回收机制，是c++程序员最头疼的内存管理的问题迎刃而解，它使得java程序员在编写程序的时候不在考虑内存管理。由于有个垃圾回收机制，java中的额对象不在有“作用域”的概念，只有对象的引用才有“作用域”。垃圾回收可以有效的防止内存泄露，有效的使用空闲的内存；
内存泄露：指该内存空间使用完毕后未回收，在不涉及复杂数据结构的一般情况下，java的内存泄露表现为一个内存对象的生命周期超出了程序需要它的时间长度，我们有是也将其称为“对象游离”；
二：垃圾回收机制的算法
java语言规范没有明确的说明JVM 使用哪种垃圾回收算法，但是任何一种垃圾回收算法一般要做两件基本事情：（1）发现无用的信息对象；（2）回收将无用对象占用的内存空间。使该空间可被程序再次使用。
1。引用计数法（Reference Counting Collector）
1.1:算法分析：
引用计数算法是垃圾回收器中的早起策略，在这种方法中，堆中的每个对象实例都有一个引用计数器，点一个对象被创建时，且该对象实例分配给一个变量，该变量计数设置为1 ，当任何其他变量赋值为这个对象的引用时，计数加1 ，（a=b ，则b引用的对象实例计数器+1）但当一个对象实例的某个引用超过了生命周期或者被设置为一个新值时，对象实例的引用计数器减1，任何引用计数器为0 的对象实例可以当做垃圾收集。 当一个对象的实例被垃圾收集是，它引用的任何对象实例的引用计数器减1.
https://www.cnblogs.com/andy-zcx/p/5522836.html
标准C++没有垃圾回收机制的原因：
1) 没有共同基类
C++是从C发展而成，允许直接操作指针，允许将一个类型转换为另一个类型，对于一个指针无法知道它真正指向的类型；而Java或C#都有一个共同基类
2) 系统开销
垃圾回收所带来的系统开销，不符合C++高效的特性，使得不适合做底层工作
3) 耗内存
C++产生的年代内存很少，垃圾回收机制需要占用更多的内存
4) 替代方法
C++C++有析构函数、智能指针、引用计数去管理资源的释放，对GC的需求不迫切
基于引用计数的垃圾回收明显在 C++ 使用者中认同率更高，所以这个原则对于 C++ 的垃圾回收也更为重要。由于没有语言强制，当程序复杂度增高，集成的第三方代码来源复杂之后，如果垃圾回收只是一个库而不是一个语言的强制特性的话，系统的开发者和维护者会越来越无力保证所有模块都采用垃圾回收，也没办法避免不同的模块采用实现细节千差万别的垃圾回收。这样整个系统的垃圾回收根本无法作为一个降低复杂度的工具，它本身就成了更大的复杂度的根源。（像上文括号中提到的那类 bug，你并不是总能把所有的裸指针很容易的替换成 shared_ptr。不说有时候你不能获得源代码，就算在获得所有源码的情况下，修改低层库的一个指针的存储方式带来的代码修改量也是不可接受的。）
https://blog.csdn.net/guoyuqi0554/article/details/8075416
趁着这个机会我总结了一下常见的 GC 算法。分别是：引用计数法、Mark-Sweep法、三色标记法、分代收集法。
https://blog.csdn.net/a369405354/article/details/87970892
1. 引用计数法
原理是在每个对象内部维护一个整数值，叫做这个对象的引用计数，当对象被引用时引用计数加一，当对象不被引用时引用计数减一。当引用计数为 0 时，自动销毁对象。
目前引用计数法主要用在 c++ 标准库的 std::shared_ptr 、微软的 COM 、Objective-C 和 php 中。
但是引用计数法有个缺陷就是不能解决循环引用的问题。循环引用是指对象 A 和对象 B 互相持有对方的引用。这样两个对象的引用计数都不是 0 ，因此永远不能被收集。
另外的缺陷是，每次对象的赋值都要将引用计数加一，增加了消耗。
2. Mark-Sweep法（标记清除法）
这个算法分为两步，标记和清除。
- 标记：从程序的根节点开始， 递归地 遍历所有对象，将能遍历到的对象打上标记。
- 清除：讲所有未标记的的对象当作垃圾销毁
如图所示。
但是这个算法也有一个缺陷，就是人们常常说的 STW 问题（Stop The World）。因为算法在标记时必须暂停整个程序，否则其他线程的代码可能会改变对象状态，从而可能把不应该回收的对象当做垃圾收集掉。
当程序中的对象逐渐增多时，递归遍历整个对象树会消耗很多的时间，在大型程序中这个时间可能会是毫秒级别的。让所有的用户等待几百毫秒的 GC 时间这是不能容忍的。
golang 1.5以前使用的这个算法。
3. 三色标记法
三色标记法是传统 Mark-Sweep 的一个改进，它是一个并发的 GC 算法。
原理如下，
- 首先创建三个集合：白、灰、黑。
- 将所有对象放入白色集合中。
- 然后从根节点开始遍历所有对象（注意这里并不递归遍历），把遍历到的对象从白色集合放入灰色集合。
- 之后遍历灰色集合，将灰色对象引用的对象从白色集合放入灰色集合，之后将此灰色对象放入黑色集合
- 重复 4 直到灰色中无任何对象
- 通过write-barrier检测对象有变化，重复以上操作
- 收集所有白色对象（垃圾）
过程如上图所示。
这个算法可以实现 "on-the-fly"，也就是在程序执行的同时进行收集，并不需要暂停整个程序。
但是也会有一个缺陷，可能程序中的垃圾产生的速度会大于垃圾收集的速度，这样会导致程序中的垃圾越来越多无法被收集掉。
使用这种算法的是 Go 1.5、Go 1.6。
4. 分代收集
分代收集也是传统 Mark-Sweep 的一个改进。这个算法是基于一个经验：绝大多数对象的生命周期都很短。所以按照对象的生命周期长短来进行分代。
一般 GC 都会分三代，在 java 中称之为新生代（Young Generation）、年老代（Tenured Generation）和永久代（Permanent Generation）；在 .NET 中称之为第 0 代、第 1 代和第2代。
原理如下：
- 新对象放入第 0 代
- 当内存用量超过一个较小的阈值时，触发 0 代收集
- 第 0 代幸存的对象（未被收集）放入第 1 代
- 只有当内存用量超过一个较高的阈值时，才会触发 1 代收集
- 2 代同理
因为 0 代中的对象十分少，所以每次收集时遍历都会非常快（比 1 代收集快几个数量级）。只有内存消耗过于大的时候才会触发较慢的 1 代和 2 代收集。
因此，分代收集是目前比较好的垃圾回收方式。使用的语言（平台）有 jvm、.NET 。
golang 的 GC
go 语言在 1.3 以前，使用的是比较蠢的传统 Mark-Sweep 算法。
1.3 版本进行了一下改进，把 Sweep 改为了并行操作。
1.5 版本进行了较大改进，使用了三色标记算法。go 1.5 在源码中的解释是“非分代的、非移动的、并发的、三色的标记清除垃圾收集器”
go 除了标准的三色收集以外，还有一个辅助回收功能，防止垃圾产生过快手机不过来的情况。这部分代码在 runtime.gcAssistAlloc 中。
但是 golang 并没有分代收集，所以对于巨量的小对象还是很苦手的，会导致整个 mark 过程十分长，在某些极端情况下，甚至会导致 GC 线程占据 50% 以上的 CPU。
因此，当程序由于高并发等原因造成大量小对象的gc问题时，最好可以使用 sync.Pool 等对象池技术，避免大量小对象加大 GC 压力。
go采用三色标记和写屏障：
- 起初所有的对象都是白色
- 扫描找出所有可达对象，标记为灰色，放入待处理队列
- 从队列提取灰色对象，将其引用对象标记为灰色放入队列
- 写屏障监视对象的内存修改，重新标色或放回队列
关于go的写屏障(write barrier)，可以阅读最近一篇比较热的文章《Proposal: Eliminate STW stack re-scanning》。 作者主要介绍下个版本Go为了消除STW所做的一些改进，包括写屏障的优化方式。
并发的三色标记算法是一个经典算法，通过write barrier，维护”黑色对象不能引用白色对象”这条约束，就可以保证程序的正确性。Go1.5会在标记阶段开启write barrier。在这个阶段里，如果用户代码想要执行操作，修改一个黑色对象去引用白色对象，则write barrier代码直接将该白色对象置为灰色。去读源代码实现的时候，有一个很小的细节：原版的算法中只是黑色引用白色则需要将白色标记，而Go1.5实现中是不管黑色/灰色/白色对象，只要引用了白色对象，就将这个白色对象标记。这么做的原因是，Go的标记位图跟对象本身的内存是在不同的地方，无法原子性地进行修改，而采用一些线程同步的实现代价又较高，所以这里的算法做过一些变种的处理。