阅读 552

golang的内存管理方式

TCMalloc

go内存管理比较复杂,它借鉴了谷歌的TCMalloc内存分配算法,全称Thread-Caching Malloc,即线程缓存的malloc,实现了高效的多线程内存管理,用于替代系统的内存分配相关的函数(malloc、free,new等)。 它的好处就是程序启动的时候先向操作系统申请一大块内存,然后根据规则切割成小内存块,根据对象的大小分配对应规格的内存块,并且在回收的时候也并不是直接还给操作系统,而是自己管理空闲的内存,这样下一次有新对象的时候,直接分配,不需要找操作系统了,减少和操作系统这种往来的开销。

go内存结构

几个概念

  • 虚拟内存:假设现在有个Go代码A, A逻辑都非常复杂,代码都1亿行,占用10G,而此时我的电脑内存一共才8G,还运行一大堆软件,所剩内存无几,那么代码A是不是就不能运行了?答案肯定不是,我们平时代码中看到的地址都是虚拟地址,通过MMU进行虚拟地址转换成为物理地址,加载代码,一条一条运行指令,然后释放虚拟内存。

image.png

  • 栈区:从高地址开始,向低地址扩展,内存管理简单,不需要自己free,系统自动回收,GC友好
  • 堆区:从低地址开始,向高地址扩展,申请和释放需要自己动手,操作麻烦。

我们说的go的内存管理,其实就是对堆内存的管理,主要通过runtime来分配和管理,不需要程序员自己去new和free。

mspan

go程序在初始化的时候,会去申请一大块的虚拟内存(并不是真正的内存空间)arena,这块内存的大小是512G,这就是堆内存。因为操作系统是页式存储,所以arena本质也是由一页一页组成的。

image.png 这里的一个page=8k,在现实情况中,有时候申请的对象可能很小,也有可能很大,于是不同的page数量组成了不同的mspan。

image.png

go根据class的size,又分为67种mspan。

carbon (3).png 这里列出了66种,还有一种大于32k的大对象(class=0)从mheap直接分配,下面会讲。 解释下sizeclass:

  1. 第一列为class的索引,递增
  2. 第二列为对象的大小
  3. 第三列为span的大小
  4. 第四列为可以存储的对象数
  5. 第五列tail waste是span%obj计算的结果,因为span的大小并不一定是对象大小的整数倍。
  6. 最后一列max waste代表最大浪费的内存百分比

假设现在要申请一个对象的大小为16B,对应的class是2,关联的span是8192,也就是一个page,那么对于这个对象它就能申请到一个页组成的mspan。mspan里面又按照8*2n大小(8b,16b,32b .... )分割,每一个mspan又分为多个object,go将相同class的mspan以链表的方式连在一起。

image.png

image.png

heap bitmap

堆内存已经申请到,并且根据object大小,分成了不同类型的mspan。但是当我们申请内存时,这些一块一块的object,我们怎么知道是不是被用了?于是bitmap出现了,bitmap主要用于标识每个object块使用状态,是否被GC标记过。bitmap中一个byte大小的内存对应arena区域中4个指针大小(指针大小为 8B )的内存,4位标记object是否被使用,4位标记object是否被GC标记,所以bitmap区域的大小是512GB/(4*8B)=16GB。

image.png

mcache

每个m会绑定一个p,每个p在某个时间点只能运行一个goroutine,每个p都有一个mcache(本地分配器),当申请一个小于32k的对象时,会优先从本地的mcache中查找可用的mspan。这样的好处就是基于本地p,寻找mspan的时候不需要加锁,效率高。如果没有mcache,类似只有一块全局的内存,那么每个goroutine去申请的时候,存在竞争,必然要加锁。

image.png 每个mcache持有一批mspan,不同的sizeclass系列,上面说到有67种mspan,但实际上有2*67种,每个sizeclass对应指针类型和非指针类型的,对于非指针类型的object,在GC的时候可以快速回收,不需要顺着指针一层一层找。

mcentral

当mcache中没有找到可用的mspan的时候,会去向mcentral申请。mcentral会为所有的mcache提供切割好的mspan,mcentral根据上面的sizeclass分为67*2种(指针和非指针类型),每种mcentral管理一种mspan。

image.png

  • lock:因为mcentral是全局的,被所有线程M共享,所以从mcentral获取mspan时要加锁
  • spanclass:每种mcentral负责的mspan类型
  • noempty:双端链表,表示还有空闲的mspan可以使用
  • empty:双端链表,表示没有空闲的mspan可以使用,已经被mcache取走还没有归还的mspan

mcache向mcentral申请的流程:

  1. 根据对象的大小,找到对应的sizeclass的mcentral
  2. 获取加锁,从noempty的链表中找到一个可用的mspan,并将其从noempty中删除,将取出的mspan加入到empty链表中,mspan返回给工作线程,解锁。
  3. 归还加锁,将mspan从empty链表中删除,将mspan加入noempty链表中,解锁。

因为根据spanclass可以分为不同的mcentral,所以不同的工作线程在获取不同类型的mcentral时,互不干扰。

mheap

当mcentral也没有可用的mspan,会向真正全局的mheap申请,mheap管理的就是一开始申请的堆内存,mheap不负责切割内存。如果mheap没有足够的内存,那么会向操作系统申请一大块内存,对于大于32k的对象不会经过mcache、mcentral分配器,而会直接从mheap上申请对应数量的page给应用程序。

image.png

tiny分配器

按照上面的规则,假设现在有个int32变量占4b,那么应该获取sizeclass=1的对应的mspan,每个object是8b,那么在int32用掉4b后,还剩4b。对于bool占用一个字节,还是7b。可以发现对于这些小对象,可能会造成很多的内碎片。

image.png 针对这些小对象,tiny分配器决定对于<=16b的内存申请时,都会从spanclass=2的对应的规格中获取一个16b的对象以供使用,并且多个对象可以复用这个16b的空间,争取把内碎片降到最低。

image.png

  1. 申请int16空间,占用2b
  2. 获取一个16b的object
  3. 申请int32空间,复用之前的object,占用4b
  4. 申请int64空间,复用之前的object,占用8b
  5. object剩余2b

真实的情况还要考虑内存对齐的问题,这里只是简单说明。

总结:obj<=16b的走tiny分配器, 16b<obj<=32k走mcache->mcentral->mheap这套流程,obj>32k直接走mheap分配。

文章分类
后端
文章标签