详解Go的内存分配机制

最新推荐文章于 2024-08-17 12:23:59 发布

壹个人的火锅

最新推荐文章于 2024-08-17 12:23:59 发布

阅读量949

点赞数 12

文章标签： golang 后端内存分配

本文链接：https://blog.csdn.net/m0_63512120/article/details/141085844

版权

go的内存分配器就是维护一块大的全局内存，每个线程（go中为P）维护一块小的私有内存，私有内存不足再从全局申请。

1 基础概念

做法是：先向系统申请一块内存，然后将内存切割成小块，通过一定的内存分配算法管理内存。以64为系统为例，Golang程序启动时会向系统申请的内存如下图所示：

预申请的内存划分为spans、bitmap、arena三部分。其中arena即为所谓的堆区，应用中需要的内存从这里分配。其中spans和bitmap是为了管理arena区而存在的。

arena的大小为512G，为了方便管理把arena区域划分成一个个的page，每个page为8KB,一共有512GB/8KB个页
spans区域存放span的指针，每个指针对应一个page，所以span区域的大小为(512GB/8KB)*指针大小8byte= 512M
bitmap区域大小也是通过arena计算出来，不过主要用于GC

2 span

span是用于管理arena页的关键数据结构，每个span中包含1个或多个连续页，为了满足小对象分配，span中的一页会划分更小的粒度，而对于大对象比如超过页大小，则通过多页实现

2.1 class

根据对象大小，划分了一系列class，每个class都代表一个固定大小的对象，以及每个span的大小。如下表所示

//	class		bytes/obj		bytes/span		objects		waste bytes
//	1		      8				  8192			1024			0
//	2		      16			  8192			512		    	0
//	3		      32			  8192			256				0
//	4		      48			  8192			170				0
//	5		      64			  8192			128				0
//	6		      80			  8192			102				0
//	7		      96			  8192			85				0
//	8		      112			  8192			73				0

class：class ID，每个span结构中都有一个class ID, 表示该span可处理的对象类型
bytes/obj：该class代表对象的字节数
bytes/span：每个span占用堆的字节数，也即页数*页大小
objects：每个span可分配的对象个数，也即（bytes/spans）/（bytes/obj）
waste bytes：每个span产生的内存碎片，也即（bytes/spans）%（bytes/obj）

2.2 span数据结构

span是内存管理的基本单位,每个span用于管理特定的class对象, 跟据对象大小，span将一个或多个页拆分成多个块进行管理。

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 表中的对象大小，也即块大小
}

以class 10为例，span和管理的内存如下图所示：

spanclass为10，参照class表可得出npages=1，nelems=56，elemsize为144。其中startAddr是在span初始化时就指定了某个页的地址。allocBits指向一个位图，每位代表一个块是否被分配，本例中有两个块已经被分配，其allocCount也为2。 next和prev用于将多个span链接起来，这有利于管理多个span，接下来会进行说明

3 cache

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

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

alloc为mspan的指针数组，数组大小为class总数的2倍。数组中每个元素代表了一种class类型的span列表，每种class类型都有两组span列表，第一组列表中所表示的对象中包含了指针，第二组列表中所表示的对象不含有指针，这么做是为了提高GC扫描性能，对于不包含指针的span列表，没必要去扫描。

根据对象是否包含指针，将对象分为noscan和scan两类，其中noscan代表没有指针，而scan则代表有指针，需要 GC进行扫描。

mcache和span的对应关系如下图所示：

mchache在初始化时是没有任何span的，在使用过程中会动态的从central中获取并缓存下来，根据使用情况，每种 class的span个数也不相同。上图所示，class 0的span数比class1的要多，说明本线程中分配的小对象要多一些。

4 central

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

central数据结构

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

线程从central获取span步骤

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

线程将span归还步骤如下

加锁
将span从empty列表删除
将span加入noneempty列表
解锁

5 heap

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

heap的数据结构

type mheap struct {
    lock        mutex        // 互斥锁，用于同步访问
    spans       []*mspan     // 指向 spans区域，用于映射span和page的关系
    bitmap      uintptr      // 指向 bitmap 首地址，bitmap 是从高地址向低地址增长的
    arena_start uintptr      // 指示 arena 区首地址
    arena_used  uintptr      // 指示 当前arena已使用区域的最大地址
    central     [67*2]struct { // 每种class对应的两个mcentral
        mcentral mcentral
        pad      [sys.CacheLineSize - unsafe.Sizeof(mcentral{})%sys.CacheLineSize]byte
    }
}