Go 语言为咱们做了很多，创建对象不再须要咱们手动申请内存，也不必思考对象应用完后开释内存，这些对开发者来说都是通明的；然而作为一名 Go 开发者，内存治理和垃圾回收还是有必要深入研究的。毕竟，内存与 CPU 是程序高效运行的根底。
虚拟内存
Linux 为每个过程保护一个独自的虚拟内存空间（组织为一些区域 / 段的汇合，如代码段，数据段，堆，共享库段，以及用户栈都是不同的区域），如下图所示：
说到这里就不得不提一下零碎调用 mmap，其要求内核创立一个新的虚拟内存区域（留神是新的区域，和堆是平级关系，即 mmap 函数并不是在堆上分配内存的）；最好是从地址 addr 开始（个别传 null），并将文件形容 fd 符指定的对象的一个间断的 chunk（大小为 len，从文件偏移 offset 开始）映射到这个新的区域；当 fd 传 - 1 时，可用于申请分配内存。
函数 mmap 申明如下 (munmap 函数开释该虚拟内存区域)：
void* mmap (void * addr , size_t len , int prot , int flags , int fd , off_t offset)
int munmap(void *addr, size_t length);参数 prot 形容这个区域的访问控制权限，能够取以下值：
PROT_EXEC // 页内容能够被执行
PROT_READ // 页内容能够被读取
PROT_WRITE // 页能够被写入
PROT_NONE // 页不可拜访 参数 flags 由形容被映射对象类型的位组成，如 MAP_SHARED 示意与其它所有映射这个对象的过程共享映射空间；MAP_PRIVATE 示意建设一个写入时拷贝的公有映射，内存区域的写入不会影响到原文件。
Go 语言底层在向操作系统申请内存时，一次申请 64M 内存，就是通过 mmap 函数申请的。另外留神，操作系统分配内存通常是按页（4K）调配的，也就是说即便过程申请 3K 内存，操作系统会调配 4K 字节。
如何设计动态内存分配器
Go 过程向操作系统一次申请 64M 内存，那么业务代码须要内存时怎么调配呢？要晓得业务申请内存是灵便多变的，申请与开释机会，申请内存块大小等等都是随机的。因而，须要设计一个内存分配器来实现这一类内存调配需要。要实现分配器必须思考以下几个问题：
1. 闲暇块组织：如何记录闲暇块；如何标记内存块是否闲暇；2. 调配：如何抉择一个适合的闲暇块来解决调配申请；3. 宰割：闲暇块个别状况会大于理论的调配申请，咱们如何解决这个闲暇块中的残余局部；4. 回收：如何解决一个刚刚被开释的块；- 思考 1：闲暇块组织
内存调配与开释申请时齐全随机的，最终会造成堆内存被宰割为若干个内存小块，其中有些处于已调配状态，有些处于闲暇状态；咱们须要额定的空间来标记内存状态以及内存块大小；
下图为 malloc 设计思路：
注：图中显示额定应用 4 字节记录以后内存块属性，其中 3 比特记录是否闲暇，29 比特记录内存块大小；理论 malloc 头部格局可能会依据版本等调整；不管咱们应用 malloc 调配多少字节的内存，理论 malloc 调配的内存都会多几个字节；
注：闲暇内存块可能会被组织为一个链表构造，由此能够遍历所有闲暇内存块，直到查找到一个满足条件的为止；
- 思考 2：如何抉择适合的闲暇块
在解决内存调配申请时，须要查找闲暇内存链表，找到一个满足申请条件的闲暇内存块，抉择什么查找算法；而且很有可能存在多个符合条件的闲暇内存块，此时如何抉择？
目前有很多比拟成熟的算法，如首次适配，最佳适配，最差适配等；
- 思考 3：如何调配
在查找到满足条件的闲暇内存块时，此内存个别状况会比理论申请调配的内存空间要大；全副调配给用户，节约空间；因而个别会将此闲暇内存块切割为两个小块内存，一块调配给用户，一块标记为新的闲暇内存
- 思考 4：如何回收：
当用户调用 free() 函数开释内存时，须要将此块内存从新标记为闲暇内存，并且插入闲暇链表；然而须要留神的是，此块内存可能可能与其余闲暇内存拼接为更大的闲暇内存；此时还须要算法来解决闲暇内存的合并；
- 思考 5：内存调配效率问题：
用户申请分配内存时，须要遍历闲暇内存链表，直到查找到一个满足申请条件的闲暇内存；由此可见，算法复杂度与链表长度成正比；咱们能够将闲暇内存依照空间大小组织为多个闲暇链表，内存大小相近的造成一个链表；此时只须要依据申请内存大小查找相应闲暇链表即可；更进一步的，闲暇内存只会被切割为固定大小，如 2^n 字节，每种字节大小的闲暇内存造成一个链表；（用户理论调配的内存是 2^n 字节，大于用户理论申请）
总结：任何内存分配器都须要额定的空间（数据结构）记录每个内存块大小及其调配状态
Go 版本内存分配器
Go 语言是如何实现这种内存分配器的呢？与下面介绍的 malloc 一样，在内存块头部额定增加几个字节吗？其实不是的，Go 语言是基于 bitmap 标识的，针对每一个内存块，应用一个比特位示意该内存块闲暇与否。
Go 语言内存治理的根本单元是 mspan，mspan 构造蕴含字段 allocBits（就是 bitmap），记录着每一个内存块闲暇还是已调配：
type mspan struct {
// 页数，Go 定义页大小为 8K
npages uintptr // number of pages in span
//bitmap，记录每一个内存块闲暇与否
allocBits *gcBits
//bitmap 的缓存，缓存 64bit，用于疾速查找（De Bruijn 算法）allocCache uint64
// 每种规格 mspan 负责调配的内存块大小
elemsize uintptr // computed from sizeclass or from npages
}另外，为了晋升闲暇内存查找效率，Go 语言定义了多种规格的 mspan，每种规格的 mspan 只负责调配固定大小的内存块（总计 67 种规格大小），如下：
// class bytes/obj bytes/span objects tail waste max waste min align
// 1 8 8192 1024 0 87.50% 8
// 2 16 8192 512 0 43.75% 16
// 3 24 8192 341 8 29.24% 8
// 4 32 8192 256 0 21.88% 32
// 5 48 8192 170 32 31.52% 16
......
// 67 32768 32768 1 0 12.50% 8192这里只截取了前 5 种规格的定义，如第一种规格负责调配的内存块大小不超过 8 字节，每一个 mspan 大小为 8K，所以每一个 mspan 最多只能调配 1024 个内存块。max waste 是什么呢？示意最大内存节约比例，想想退出每次只申请一字节内存呢？Go 内存分配器也会抉择第一种规格的 mspan，这样最差状况节约了 7 / 8 的内存（87.50%）。
对于一个 mspan，须要多少比特位示意内存块闲暇状态呢？这就与该 mspan 划分的内存块数目无关了；咱们看一下 allocBits 初始化逻辑：
func (h *mheap) allocSpan(npages uintptr, typ spanAllocType, spanclass spanClass) (s *mspan) {
// 页 * 页大小 = 页字节数
nbytes := npages * pageSize
// 计算 mspan 最多能宰割为多少内存块
s.nelems = nbytes / s.elemsize
// 申请 bitmap
s.allocBits = newAllocBits(s.nelems)
}
//newAllocBits 计算 bitmap 所需字节数
blocksNeeded := uintptr((nelems + 63) / 64)
bytesNeeded := blocksNeeded * 8allocBits 存储对应内存块是否闲暇，0 示意闲暇 1 示意已调配。参考上面对 mspan 的介绍，内存申请的逻辑根本也就分明了：依据申请内存的大小，确定 mspan 规格，查找 bitmap（比特位 0），如果找到标记已调配，返回内存块地址。
// 内存申请入口
func mallocgc(size uintptr, typ *_type, needzero bool) unsafe.Pointer {
// 依据申请内存大小，计算 mspan 规格
sizeclass = size_to_class8[divRoundUp(size, smallSizeDiv)]
spc := makeSpanClass(sizeclass, noscan)
// 获取对应规格的 mspan
span = c.alloc[spc]
// 查找闲暇内存块
v := nextFreeFast(span)
x = unsafe.Pointer(v)
return x
}查找闲暇内存块其实就是在 bitmap 中搜寻 0 比特，一般搜索算法工夫复杂度为 O(n)，Go 语言应用 De Bruijn 算法晋升搜寻效率。
Go 内存治理概述
Go 语言内存治理这么简略吗？显然不是。思考几个问题，Go 语言是多线程程序，必定会呈现多线程并发申请内存的状况，每次申请都须要加锁吗？这显然是不适合的。下面提到 Go 语言底层在向操作系统申请内存时，一次申请 64M 内存，然而内存治理的根本单位又是 mspan，64M 内存怎么转化为 mspan 呢？最初，内存治理还随同着垃圾回收（内存开释），这就更简单了（前面篇章会介绍）。
如上图所示，每一个逻辑处理器 P 都缓存着 mspan（缓存在 p.mcache，是一个数组），这样协程在申请内存时，只须要在以后 P 的 mcache 查找闲暇内存就行了，这里缓存了所有规格的 mcache，定义如下：
type p struct {mcache *mcache}
type mcache struct {
// mspan 数组，numSpanClasses == 136
alloc [numSpanClasses]*mspan // spans to allocate from, indexed by spanClass
}alloc 数组存储所有规定的 mspan，数组长度为 136。之前介绍不是说 mspan 只有 67 种规格吗？这里须要解释下：为了晋升垃圾回收效率，Go 语言在分配内存时，会思考要存储的对象是否蕴含指针，将有指针和无指针的内存分为了两种规格的 mspan，这样垃圾回收扫描时，就不会扫描无指针的 mspan 了。这么一算，mspan 规格数应该是 67 2 = 134，还有两种规格呢？这两种规格的 mspan 负责大块内存的调配（大于 32768 = 4 8192 = 4page），同样分为有指针和无指针。
如果当然逻辑处理器 P 的缓存 mcache 曾经调配完了呢？这时候就只能从全局的 mcentral 调配了，mcentral 同样分为 136 种规格，每种规格的 mcentral 存储着一些 mspan（可能有闲暇内存，可能没有闲暇内存；可能曾经被垃圾回收标记 - 清理了，可能只是被垃圾回收标记了然而还没有清理），接下来就是从对应规格的 mcentral 查找可用的 mspan 了。
type mheap struct {
// 全局 mcentral
central [numSpanClasses]struct {mcentral mcentral}
}
type mcentral struct {
spanclass spanClass
//partial 存储有闲暇内存的 mspan
partial [2]spanSet // list of spans with a free object
//full 存储的 mspan 没有闲暇内存
full [2]spanSet // list of spans with no free objects
}留神多个协程可能会并发拜访 mcentral，所以这里的一些操作是须要加锁的。参考 mcentral 构造的定义，查找 mspan 的逻辑应该是怎么样的呢：1）查找 partial 已被清理的 mspan 数组，如果有返回 mspan；2）查找 partia 未被清理的 mspan 数组，如果有则执行清理工作，并返回该 mspan；3）查找 full 未被清理的 mspan 数组，如果有则执行清理工作，并返回该 mspan。另外，查找 mcentral 也是有次数限度的，最多遍历查找 100 次，如果查找 100 次后还没有找到可用的 mspan，则申请新的 mspan。
如果在全局 mcentral 没有查找到可用的 mspan 呢？那只能向 pageCache 申请新的 mspan 了。同样的，每一个逻辑处理器 P 都缓存有 pageCache（缓存有 64 个闲暇页），用于解决页的调配申请。留神从 p.pageCache 调配 mspan 是不须要加锁的。
如果逻辑处理器 P 的缓存 pageCache 也没有足够的闲暇页呢？那就通过页分配器 pageAlloc 调配缓存页呗，页分配器的内存从哪来呢？这里就是从操作系统申请的，而且一次申请 64M 内存，这块内存称之为 heapArena。
内存调配的入口函数是 mallocgc，整个函数调用链路如下所示，有趣味的读者能够浏览学习;
// 内存调配入口
func mallocgc(size uintptr, typ *_type, needzero bool) unsafe.Pointer
// 查找闲暇内存块，如果没有申请 mspan
func (c *mcache) nextFree(spc spanClass) (v gclinkptr, s *mspan, shouldhelpgc bool)
// 获取新的 mspan
func (c *mcache) refill(spc spanClass)
//mcentral 查找可用 mspan
func (c *mcentral) cacheSpan() *mspan
//mcentral 申请新的 mspan
func (c *mcentral) grow() *mspan
// 申请 mspan
func (h *mheap) allocSpan(npages uintptr, typ spanAllocType, spanclass spanClass) (s *mspan)
// 从 p.pageCache 申请 mspan
func (c *pageCache) alloc(npages uintptr) (uintptr, uintptr)
//pageCache 缓存不够，申请新的 pageCache
func (p *pageAlloc) allocToCache() pageCache
//pageAlloc 申请内存
func (h *mheap) grow(npage uintptr) (uintptr, bool)
func (p *pageAlloc) grow(base, size uintptr)
// 向操作系统申请 heapArena（64M）func (h *mheap) sysAlloc(n uintptr) (v unsafe.Pointer, size uintptr)内存逃逸
什么是内存逃逸呢？一句话解释就是一个对象（变量）原本应该调配在栈上，后果调配到堆内存了。咱们都晓得个别函数内写的局部变量等，应该是调配在栈上的，随着函数的调用与返回，该局部变量也会同步调配与开释；然而在某些状况下该局部变量是不能调配到栈上的，只能调配到堆内存。
编译阶段能够通过 - m 剖析内存逃逸的状况，如下：
// -N 禁止编译优化 -l 禁止内联 -m 输入优化详情（包含逃逸剖析），能够多个，- m 越多输入信息越多（最多 4 个）go build -gcflags '-N -m -m -l' test.go举一个例子，假如函数有一个局部变量，同时函数返回了该局部变量的地址，这能够吗？在局部语言如 C 这种写法是行不通的，因为函数返回后，该局部变量的地址会开释。然而 Go 语言是容许这种写法的，只是这种状况下，该局部变量会逃逸到堆内存。
package main
import "fmt"
func main() {ret := test()
fmt.Println(ret)
}
func test() *int {
var num = 10
return &num
}
/*
go build -gcflags '-N -m -m -l' test.go
# command-line-arguments
./test.go:11:6: num escapes to heap:
./test.go:11:6: flow: ~r0 = &num:
./test.go:11:6: from &num (address-of) at ./test.go:12:9
./test.go:11:6: from return &num (return) at ./test.go:12:2
./test.go:11:6: moved to heap: num
./test.go:7:13: ... argument does not escape
*/能够很显著的看到，”moved to heap: num”，阐明变量 num 逃逸到堆上了。
再比方，假如一个局部变量的赋值给 map 或者切片呢，而且赋值的不是值而是地址，函数返回后，局部变量也会随之开释，这显然会引起异样，所以这种局部变量也会逃逸到堆内存，如上面程序所示
package main
var score = make(map[int]*int, 0)
func main() {
s := 100
score[0] = &s
}
/*
go build -gcflags '-N -m -m -l' test.go
# command-line-arguments
./test.go:6:2: s escapes to heap:
./test.go:6:2: flow: {heap} = &s:
./test.go:6:2: from &s (address-of) at ./test.go:7:13
./test.go:6:2: from score[0] = &s (assign) at ./test.go:7:11
./test.go:6:2: moved to heap: s
./test.go:3:17: make(map[int]*int, 0) escapes to heap:
./test.go:3:17: flow: {heap} = &{storage for make(map[int]*int, 0)}:
./test.go:3:17: from make(map[int]*int, 0) (spill) at ./test.go:3:17
./test.go:3:17: from score = make(map[int]*int, 0) (assign) at ./test.go:3:5
./test.go:3:17: make(map[int]*int, 0) escapes to heap
*/能够很显著的看到，”moved to heap: s”，阐明变量 s 逃逸到堆上了。另外，变量 score 是一个 map，make 函数底层也是在堆上申请的内存（参考 map 章节）。
当然还有其余状况，比方局部变量占用内存十分大，这时候就不适宜调配到栈上了，等等，这里就不一一介绍了，简略理解即可。
总结
本篇文章从虚拟内存开始，逐渐介绍了动态内存分配器的设计思路，引入 Go 语言内存调配设计，最初整体介绍了 Go 内存治理整个流程，最初还简略介绍了内存逃逸的基本概念。下一篇将联合内存治理的内容，开始介绍垃圾回收实现过程。