go语言内存 go语言内存申请和释放( 三 )


有了管理内存的基本单位span,还要有个数据结构来管理span , 这个数据结构叫mcentral , 各线程需要内存时从mcentral管理的span中申请内存,为了避免多线程申请内存时不断的加锁 , Golang为每个线程分配了span的缓存 , 这个缓存即是cache 。src/runtime/mcache.go:mcache定义了cache的数据结构
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的要多,说明本线程中分配的小对象要多一些 。
cache作为线程的私有资源为单个线程服务,而central则是全局资源,为多个线程服务,当某个线程内存不足时会向central申请,当某个线程释放内存时又会回收进central 。src/runtime/mcentral.go:mcentral定义了central数据结构:
lock: 线程间互斥锁,防止多线程读写冲突
spanclass : 每个mcentral管理着一组有相同class的span列表
nonempty: 指还有内存可用的span列表
empty: 指没有内存可用的span列表
nmalloc: 指累计分配的对象个数线程从central获取span步骤如下:
将span归还步骤如下:
从mcentral数据结构可见,每个mcentral对象只管理特定的class规格的span 。事实上每种class都会对应一个mcentral,这个mcentral的集合存放于mheap数据结构中 。src/runtime/mheap.go:mheap定义了heap的数据结构:
lock: 互斥锁
spans: 指向spans区域,用于映射span和page的关系
bitmap:bitmap的起始地址
arena_start: arena区域首地址
arena_used: 当前arena已使用区域的最大地址
central: 每种class对应的两个mcentral
从数据结构可见,mheap管理着全部的内存 , 事实上Golang就是通过一个mheap类型的全局变量进行内存管理的 。mheap内存管理示意图如下:
系统预分配的内存分为spans、bitmap、arean三个区域,通过mheap管理起来 。接下来看内存分配过程 。
针对待分配对象的大小不同有不同的分配逻辑:
(0, 16B) 且不包含指针的对象: Tiny分配
(0, 16B) 包含指针的对象:正常分配
[16B, 32KB] : 正常分配
(32KB, -) : 大对象分配其中Tiny分配和大对象分配都属于内存管理的优化范畴,这里暂时仅关注一般的分配方法 。
以申请size为n的内存为例,分配步骤如下:
Golang内存分配是个相当复杂的过程,其中还掺杂了GC的处理 , 这里仅仅对其关键数据结构进行了说明,了解其原理而又不至于深陷实现细节 。1、Golang程序启动时申请一大块内存并划分成spans、bitmap、arena区域
【go语言内存 go语言内存申请和释放】2、arena区域按页划分成一个个小块 。
3、span管理一个或多个页 。
4、mcentral管理多个span供线程申请使用
5、mcache作为线程私有资源 , 资源来源于mcentral 。
Golang 1.14中内存分配、清扫和内存回收 Golanggo语言内存的内存分配是由golang runtime完成go语言内存,其内存分配方案借鉴自tcmalloc 。

推荐阅读