内存管理
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步骤如下:
- 加锁
- 从nonempty列表获取一个可用span,并将其从链表中删除
- 将取出的span放入empty链表
- 将span返回给线程
- 解锁
- 线程将该span缓存进cache
线程将span归还步骤如下:
- 加锁
- 将span从empty列表删除
- 将span加入noneempty列表
- 解锁
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的内存为例,分配步骤如下:
- 获取当前线程的私有缓存mcache
- 跟据size计算出适合的class的ID
- 从mcache的alloc[class]链表中查询可用的span
- 如果mcache没有可用的span则从mcentral申请一个新的span加入mcache中
- 如果mcentral中也没有可用的span则从mheap中申请一个新的span加入mcentral
- 从该span中获取到空闲对象地址并返回
总结
Golang内存分配是个相当复杂的过程,其中还掺杂了GC的处理,这里仅仅对其关键数据结构进行了说明,了解其原理而又不至于深陷实现细节。
-
Golang程序启动时申请一大块内存,并划分成spans、bitmap、arena区域
-
arena区域按页划分成一个个小块
-
span管理一个或多个页
-
mcentral管理多个span供线程申请使用
-
mcache作为线程私有资源,资源来源于mcentral
垃圾回收
常见的垃圾回收方法:引用计数(py)、标记清除(go)、分代收集(java)
内存标记(Mark)
span中维护了一个个内存块,并由一个位图表示每个内存块分配的情况,在span数据结构中还有另一个位图gcmarkbits用于标记内存块被引用情况。
三色标记法
需要有一个标记队列来存放待标记的对象,可以简单想象成把对象从标记队列中取出,将对象的引用状态标记在span的gcmarkBits,把对象引用到的其他对象再放入队列中
三色,对应了垃圾回收过程中对象的三种状态:
灰色:对象还在标记队列中等待
黑色:对象已被标记,gcmarkBits对应的位为1(该对象不会在本次GC中被清理)
白色:对象未被标记,gcmarkBits对应的位为0(该对象将会在本次GC中被清理)
STW(Stop The World):停掉所有的goroutine,专心做垃圾回收,待垃圾回收结束后再恢复goroutine
内存逃逸
指由编译器决定内存分配的位置,不需要程序员指定。函数中申请一个新的对象
如果分配在栈中,则函数执行结束可自动将内存回收;
如果分配在堆中,则函数执行结束可交给GC(垃圾回收)处理;
每当函数中申请新的对象,编译器会跟据该对象是否被函数外部引用来决定是否逃逸:
- 如果函数外部没有引用,则优先放到栈中;(如内存过大超过栈的存储能力)
- 如果函数外部存在引用,则必定放到堆中;
栈上分配内存比在堆中分配内存有更高的效率
栈上分配的内存不需要GC处理
堆上分配的内存使用完毕会交给GC处理
逃逸分析目的是决定内分配地址是栈还是堆
逃逸分析在编译阶段完成
Tips:
函数传递指针真的比传值效率高吗?我们知道传递指针可以减少底层值的拷贝,可以提高效率,但是如果拷贝的数据量小,由于指针传递会产生逃逸,可能会使用堆,也可能会增加GC的负担,所以传递指针不一定是高效的。
不需要GC处理
堆上分配的内存使用完毕会交给GC处理
逃逸分析目的是决定内分配地址是栈还是堆
逃逸分析在编译阶段完成
Tips:
函数传递指针真的比传值效率高吗?我们知道传递指针可以减少底层值的拷贝,可以提高效率,但是如果拷贝的数据量小,由于指针传递会产生逃逸,可能会使用堆,也可能会增加GC的负担,所以传递指针不一定是高效的。