GoTips-- 内存管理2

内存管理

span

span是用于管理arena页的关键数据结构

type mspan struct {
	next      *mspan  //链表前向指针，用于将span链接起来
	prev      *mspan  //链表前向指针，用于将span链接起来
	startAddr uintptr // 起始地址，也即所管理页的地址
	npages    uintptr // 管理的页数

	nelems uintptr // 块个数，也即有多少个块可供分配
	
	allocBits *gcBits //分配位图，每一位代表一个块是否已分配
	
	allocCount uint16    // 已分配块的个数
	spanclass  spanClass // class表中的class ID
	
	elemsize uintptr // class表中的对象大小，也即块大小

}

cache

有了管理内存的基本单位span，还要有个数据结构来管理span，这个数据结构叫mcentral，各线程需要内存时
从mcentral管理的span中申请内存，为了避免多线程申请内存时，不断的加锁，golang为每个线程分配了span
的缓存，即cache

type mcache struct {
	alloc [67 * 2]*mspan // 按class分组的mspan列表
}

mchache在初始化时是没有任何span的，在使用过程中会动态的从central中获取并缓存下来，跟据使用情况，每种
class的span个数也不相同。

central

cache作为线程的私有资源为单个线程服务，而central则是全局资源，为多个线程服务，当某个线程内存不足时会
向central申请，当某个线程释放内存时又会回收进central

type mcentral struct {
	lock      mutex     //互斥锁
	spanclass spanClass // span class ID
	nonempty  mSpanList // non-empty 指还有空闲块的span列表
	empty     mSpanList // 指没有空闲块的span列表
	nmalloc uint64 // 已累计分配的对象个数

}

线程从central获取span步骤如下：

1. 加锁
2. 从nonempty列表获取一个可用span，并将其从链表中删除
3. 将取出的span放入empty链表
4. 将span返回给线程
5. 解锁
6. 线程将该span缓存进cache

线程将span归还步骤如下:

1. 加锁
2. 将span从empty列表删除
3. 将span加入noneempty列表
4. 解锁

heap

从mcentral数据结构可见，每个mcentral对象只管理特定的class规格的span。事实上每种class都会对应一个
mcentral,这个mcentral的集合存放于mheap数据结构中。

type mheap struct {
	lock mutex

	spans []*mspan

	bitmap uintptr //指向bitmap首地址，bitmap是从高地址向低地址增长的

	arena_start uintptr //指示arena区首地址
	arena_used  uintptr //指示arena区已使用地址位置

	central [67 * 2]struct {
		mcentral mcentral
		pad      [sys.CacheLineSize - unsafe.Sizeof(mcentral{})%sys.CacheLineSize]byte
	}
}

mheap管理着全部的内存，事实上Golang就是通过一个mheap类型的全局变量进行内存管理的

系统预分配的内存分为spans、bitmap、arean三个区域，通过mheap管理起来。接下来看内存分配过程

内存分配过程：

针对待分配对象的大小不同有不同的分配逻辑：
(0, 16B) 且不包含指针的对象： Tiny分配
(0, 16B) 包含指针的对象：正常分配
[16B, 32KB] : 正常分配
(32KB, -) : 大对象分配其中Tiny分配和大对象分配都属于内存管理的优化范畴，这里暂时仅关注一般的分
配方法。

以申请size为n的内存为例，分配步骤如下：

1. 获取当前线程的私有缓存mcache
2. 跟据size计算出适合的class的ID
3. 从mcache的alloc[class]链表中查询可用的span
4. 如果mcache没有可用的span则从mcentral申请一个新的span加入mcache中
5. 如果mcentral中也没有可用的span则从mheap中申请一个新的span加入mcentral
6. 从该span中获取到空闲对象地址并返回

总结

Golang内存分配是个相当复杂的过程，其中还掺杂了GC的处理，这里仅仅对其关键数据结构进行了说明，了解其原理而又不至于深陷实现细节。

1. Golang程序启动时申请一大块内存，并划分成spans、bitmap、arena区域

2. arena区域按页划分成一个个小块

3. span管理一个或多个页

4. mcentral管理多个span供线程申请使用

5. mcache作为线程私有资源，资源来源于mcentral

垃圾回收

常见的垃圾回收方法：引用计数（py）、标记清除(go)、分代收集(java)

内存标记（Mark）

span中维护了一个个内存块，并由一个位图表示每个内存块分配的情况，在span数据结构中还有另一个位图gcmarkbits用于标记内存块被引用情况。

三色标记法

需要有一个标记队列来存放待标记的对象，可以简单想象成把对象从标记队列中取出，将对象的引用状态标记在span的gcmarkBits，把对象引用到的其他对象再放入队列中

三色，对应了垃圾回收过程中对象的三种状态：
灰色：对象还在标记队列中等待
黑色：对象已被标记，gcmarkBits对应的位为1（该对象不会在本次GC中被清理）
白色：对象未被标记，gcmarkBits对应的位为0（该对象将会在本次GC中被清理）

STW（Stop The World）：停掉所有的goroutine，专心做垃圾回收，待垃圾回收结束后再恢复goroutine

内存逃逸

指由编译器决定内存分配的位置，不需要程序员指定。函数中申请一个新的对象
如果分配在栈中，则函数执行结束可自动将内存回收；
如果分配在堆中，则函数执行结束可交给GC（垃圾回收）处理;

每当函数中申请新的对象，编译器会跟据该对象是否被函数外部引用来决定是否逃逸：

1. 如果函数外部没有引用，则优先放到栈中；（如内存过大超过栈的存储能力）
2. 如果函数外部存在引用，则必定放到堆中；

栈上分配内存比在堆中分配内存有更高的效率
栈上分配的内存不需要GC处理
堆上分配的内存使用完毕会交给GC处理
逃逸分析目的是决定内分配地址是栈还是堆
逃逸分析在编译阶段完成

Tips：

函数传递指针真的比传值效率高吗？我们知道传递指针可以减少底层值的拷贝，可以提高效率，但是如果拷贝的数据量小，由于指针传递会产生逃逸，可能会使用堆，也可能会增加GC的负担，所以传递指针不一定是高效的。
不需要GC处理
堆上分配的内存使用完毕会交给GC处理
逃逸分析目的是决定内分配地址是栈还是堆
逃逸分析在编译阶段完成

Tips：

函数传递指针真的比传值效率高吗？我们知道传递指针可以减少底层值的拷贝，可以提高效率，但是如果拷贝的数据量小，由于指针传递会产生逃逸，可能会使用堆，也可能会增加GC的负担，所以传递指针不一定是高效的。