go语言存在堆上的变量咋取值 go语言内存模型

学习笔记 2023-10-07 142°

Go内存管理

文章目录

Go内存管理

原文
Go内存管理的基本概念

Go内存大小转换

Go内存分配

小对象的内存分配
大对象的内存分配

Go垃圾回收和内存释放

Go的栈内存
总结

原文

前文提到Go内存管理源自TCMalloc
但它比TCMalloc还多了2件东西：

逃逸分析
垃圾回收

这是2项提高生产力的绝佳武器
这一大章节

我们先介绍Go内存管理和Go内存分配
最后涉及一点垃圾回收和内存释放

Go内存管理的基本概念

Go内存管理的许多概念在TCMalloc中已经有了

含义是相同的
只是名字有一些变化

先给大家上一幅宏观的图

借助图一起来介绍

Page

与TCMalloc中的Page相同
x64架构下1个Page的大小是8KB
上图的最下方

1个浅蓝色的长方形代表1个Page。

Span
Span与TCMalloc中的Span相同
Span是内存管理的基本单位

代码中为mspan
一组连续的Page组成1个Span

所以上图一组连续的浅蓝色长方形

代表的是一组Page组成的1个Span

另外，1个淡紫色长方形为1个Span。

mcache
- mcache与TCMalloc中的ThreadCache类似
- mcache保存的是各种大小的Span
- 但是mcache与ThreadCache也有不同点
mcentral
- mcentral与TCMalloc中的CentralCache类似
- 是所有线程共享的缓存
- 它按Span级别对Span分类
- 当mcache的某个级别Span的内存被分配光时
- 但是mcentral与CentralCache也有不同点
mheap
- mheap与TCMalloc中的PageHeap类似
- 它是堆内存的抽象
- 当mcentral的Span不够用时会向mheap申请内存
- 而mheap的Span不够用时会向OS申请内存
- 但是mheap与PageHeap也有不同点：
- mheap把Span组织成了树结构，而不是链表，并且还是2棵树

Go内存大小转换

- 代码里简称size指申请内存的对象大小
- 代码里简称class
- 相当于把size归类到一定大小的区间段
span class：
- 指span的级别
- 但span class的大小与span的大小并没有正比关系
- span class主要用来和size class做对应
- 1个size class对应2个span class
num of page：
- 代码里简称npage
- 代表Page的数量

Go内存分配

Go中的内存分类并不像TCMalloc那样分成小、中、大对象

但是它的小对象里又细分了一个Tiny对象
Tiny对象指大小在1Byte到16Byte之间
并且不包含指针的对象

小对象和大对象只用大小划定，无其他区分

小对象是在mcache中分配的
大对象是直接从mheap分配的
从小对象的内存分配看起

小对象的内存分配

大小转换这一小节
我们介绍了转换表
size class从1到66共66个

代码中_NumSizeClasses=67

代表了实际使用的size class数量
即67个，从1到67
size class 0实际并未使用到

numSpanClasses为span class的数量为134个

所以span class的下标是从0到133
所以上图中mcache标注了的span class是

span class 0到span class 133
每1个span class都指向1个span
也就是mcache最多有134个span

为对象寻找span

寻找span的流程如下：

计算对象所需内存大小size
根据size到size class映射，计算出所需的size class
根据size class和对象是否包含指针计算出span class
获取该span class指向的span

以分配一个不包含指针的，大小为24Byte的对象为例，根据映射表：

对应的size class为3

它的对象大小范围是(16,32]Byte
24Byte刚好在此区间
所以此对象的size class为3

Size class到span class的计算如下：

所以对应的span class为7
所以该对象需要的是span class 7指向的span

从span分配对象空间

Span可以按对象大小切成很多份
这些都可以从映射表上计算出来

以size class 3对应的span为例
span大小是8KB
每个对象实际所占空间为32Byte
这个span就被分成了256块
可以根据span的起始地址计算出每个对象块的内存地址

随着内存的分配
span中的对象内存块，有些被占用，有些未被占用
比如上图
- 整体代表1个span
当span内的所有内存块都被占用时
- 没有剩余空间继续分配对象
- mcache会向mcentral申请1个span
- mcache拿到span后继续分配对象
mcache向mcentral申请span

mcentral和mcache一样

都是0~133这134个span class级别
但每个级别都保存了2个span list，即2个span链表：

nonempty：

这个链表里的span

至少有1个空闲的对象空间
是mcache释放span时加入到该链表的

empty：

这个链表里的span

所有的span都不确定里面是否有空闲的对象空间
当一个span交给mcache的时候，就会加入到empty链表。

这两个东西名称一直有点绕

建议直接把empty理解为没有对象空间就好了

mcache向mcentral申请span时

mcentral会先从nonempty搜索满足条件的span
如果没有找到再从emtpy搜索满足条件的span
然后把找到的span交给mcache

mheap的span管理

mheap里保存了两棵二叉排序树
按span的page数量进行排序：

free：

free中保存的span是空闲并且非垃圾回收的span

scav：

scav中保存的是空闲并且已经垃圾回收的span

如果是垃圾回收导致的span释放

span会被加入到scav

否则加入到free

比如刚从OS申请的的内存也组成的Span

mheap中还有arenas

由一组heapArena组成

每一个heapArena都包含了连续的pagesPerArena个span

这个主要是为mheap管理span和垃圾回收服务
mheap本身是一个全局变量

它里面的数据

也都是从OS直接申请来的内存
并不在mheap所管理的那部分内存以内

mcentral向mheap申请span
- 当mcentral向mcache提供span时
- 此时
- mcentral需要向mheap提供需要的内存页数和span class级别
- 然后它优先从free中搜索可用的span
mheap向OS申请内存
- 当mheap没有足够的内存时
- mheap会向OS申请内存
- 在32位系统中，mheap还会预留一部分空间

大对象的内存分配

大对象的分配比小对象省事多了
99%的流程与mcentral向mheap申请内存的相同

所以不重复介绍了

不同的一点在于

mheap会记录一点大对象的统计信息

详情见mheap.alloc_m()

Go垃圾回收和内存释放

如果只申请和分配内存，内存终将枯竭
Go使用垃圾回收收集不再使用的span

调用mspan.scavenge()把span释放还给OS

（并非真释放，只是告诉OS这片内存的信息无用了，如果你需要的话，收回去好了）

然后交给mheap

mheap对span进行span的合并
把合并后的span加入scav树中

等待再分配内存时

由mheap进行内存再分配

Go程序是怎么把内存释放给操作系统的？

释放内存的函数是sysUnused，它会被mspan.scavenge()调用:

注释说 _MADV_FREE_REUSABLE 与 MADV_FREE 的功能类似
它的功能是给内核提供一个建议：

这个内存地址区间的内存已经不再使用，可以进行回收
但内核是否回收，以及什么时候回收，这就是内核的事情了
如果内核真把这片内存回收了

当Go程序再使用这个地址时
内核会重新进行虚拟地址到物理地址的映射
所以在内存充足的情况下

内核也没有必要立刻回收内存

Go的栈内存

从一个宏观的角度看

内存管理不应当只有堆，也应当有栈

每个goroutine都有自己的栈

栈的初始大小是2KB

100万的goroutine会占用2G

但goroutine的栈会在2KB不够用时自动扩容

当扩容为4KB的时候
百万goroutine会占用4GB

总结

Go的内存分配原理就不再回顾了，它主要强调两个重要的思想：

使用缓存提高效率
- 在存储的整个体系中到处可见缓存的思想
- Go内存分配和管理也使用了缓存，利用缓存
以空间换时间，提高内存管理效率
- 空间换时间是一种常用的性能优化思想
- 这种思想其实非常普遍