160 lines
5.9 KiB
Markdown
160 lines
5.9 KiB
Markdown
|
---
|
|||
|
|
tags: [go, golang, go-principle, memory-management]
|
|||
|
|
create time: 2026-06-07 15:55
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
# 内存管理机制
|
|||
|
|
|
|||
|
|
## 概述
|
|||
|
|
|
|||
|
|
本文从 TCMalloc 的设计思想出发，解析 Go 堆内存管理的三层架构（mheap → mcentral → mcache），以及小对象和大对象的分配策略。理解内存管理能帮你优化程序的内存使用、减少 GC 压力。
|
|||
|
|
|
|||
|
|
> [!question] ❓ 思考
|
|||
|
|
> 为什么 Go 的内存管理器要分成三层？每个 P 都配一个 mcache 真的是为了无锁访问吗？超过 32KB 的大对象为什么不走 mcache 而直接去 mheap 拿？
|
|||
|
|
|
|||
|
|
## 正文
|
|||
|
|
|
|||
|
|
### 一、设计渊源：TCMalloc
|
|||
|
|
|
|||
|
|
Go 的内存管理借鉴了 Google 的 **TCMalloc**（Thread-Caching Malloc）思想。TCMalloc 的核心设计是"以空间换时间"——用多层缓存避免锁竞争。
|
|||
|
|
|
|||
|
|
```mermaid
|
|||
|
|
flowchart LR
|
|||
|
|
ThreadCache["ThreadCache<br/>每个线程独立，无锁"] --> CentralCache["CentralCache<br/>所有线程共享，加锁"]
|
|||
|
|
CentralCache --> PageHeap["PageHeap<br/>OS 内存页管理"]
|
|||
|
|
style ThreadCache fill:#e8f5e9
|
|||
|
|
style CentralCache fill:#fff9c4
|
|||
|
|
style PageHeap fill:#ffebee
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
TCMalloc 的基本单位：
|
|||
|
|
| 层级 | 名称 | 说明 |
|
|||
|
|
|------|------|------|
|
|||
|
|
| 最底层 | **Page** | 与 OS 内存页对应，通常是 4KB |
|
|||
|
|
| 中层 | **Span** | 一组连续的 Page，是内存管理的基本单位 |
|
|||
|
|
| 上层 | **ThreadCache** | 每个线程私有的空闲块链表，按大小分类 |
|
|||
|
|
| 顶层 | **CentralCache** | 所有线程共享，加锁访问 |
|
|||
|
|
|
|||
|
|
### 二、Go 的内存管理架构
|
|||
|
|
|
|||
|
|
Go 将 TCMalloc 改造为三层层级结构，适配 GMP 模型：
|
|||
|
|
|
|||
|
|
```mermaid
|
|||
|
|
graph TB
|
|||
|
|
subgraph M["用户请求分配"]
|
|||
|
|
Small["小对象 (≤32KB)"]
|
|||
|
|
Large["大对象 (>32KB)"]
|
|||
|
|
end
|
|||
|
|
|
|||
|
|
subgraph SmallPath["小对象路径"]
|
|||
|
|
MC["mcache<br/>每P一个，无锁"] --> MSC["mcentral<br/>全局共享，加锁"]
|
|||
|
|
MSC --> MH["mheap<br/>管理OS页面"]
|
|||
|
|
end
|
|||
|
|
|
|||
|
|
subgraph LargePath["大对象路径"]
|
|||
|
|
MH2["mheap"] --> OS["直接向OS申请"]
|
|||
|
|
end
|
|||
|
|
|
|||
|
|
Small --> SmallPath
|
|||
|
|
Large --> LargePath
|
|||
|
|
style MC fill:#e8f5e9
|
|||
|
|
style MSC fill:#fff9c4
|
|||
|
|
style MH fill:#ffebee
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
#### 核心组件对照表
|
|||
|
|
|
|||
|
|
| Go 组件 | TCMalloc 对应 | 说明 |
|
|||
|
|
|---------|-------------|------|
|
|||
|
|
| `mcache` | ThreadCache | 每个 P 私有，无锁访问 |
|
|||
|
|
| `mcentral` | CentralCache | 全局共享，需加锁 |
|
|||
|
|
| `mheap` | PageHeap | 管理 OS 页面的树结构 |
|
|||
|
|
|
|||
|
|
> [!tip] 💡 为什么是每个 P 而不是每个 M？
|
|||
|
|
> Go 最多有 GOMAXPROCS 个 M 同时运行，每个 P 配一个 mcache 就能保证所有 M 在各自的 P 上执行时无锁分配。这比 TCMalloc 的"每个线程一个 cache"更精确。
|
|||
|
|
|
|||
|
|
### 三、Span Class：67 种规格
|
|||
|
|
|
|||
|
|
Go 对小对象按大小分成了 67 个 class，每个 class 对应固定的对象大小和 span 包含的对象数：
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
class bytes/obj bytes/span objects tail waste
|
|||
|
|
1 8 8192 1024 0 87.50%
|
|||
|
|
2 16 8192 512 0 43.75%
|
|||
|
|
...
|
|||
|
|
17 256 8192 32 0 5.86%
|
|||
|
|
...
|
|||
|
|
58 16384 16384 1 0 12.49%
|
|||
|
|
66 32768 32768 1 0 12.50%
|
|||
|
|
0 >32KB N/A 1 N/A N/A
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
> [!note] 📝 源码要点
|
|||
|
|
> Span class 由两个因素决定：(1) 对象大小所在的 size class；(2) 是否包含指针（noscan）。公式：`spanClass = sizeClass<<1 | noscan`。这意味着同一个 size class 会有 scan/noscan 两种变体。
|
|||
|
|
|
|||
|
|
#### 分配一个小对象的步骤
|
|||
|
|
|
|||
|
|
```go
|
|||
|
|
// 以分配一个含指针的 20 字节对象为例
|
|||
|
|
size := 20
|
|||
|
|
|
|||
|
|
// Step 1: 根据大小找 size class
|
|||
|
|
sizeclass = size_to_class8[divRoundUp(size, 8)] // = 3 (范围 (16, 32])
|
|||
|
|
|
|||
|
|
// Step 2: 计算 span class (含指针 => noscan=false)
|
|||
|
|
spc = makeSpanClass(sizeclass, false) // = 3<<1|0 = 6
|
|||
|
|
|
|||
|
|
// Step 3: 从当前 P 的 mcache 中获取对应 span
|
|||
|
|
span = c.alloc[spc]
|
|||
|
|
|
|||
|
|
// Step 4: 从 span 中取一个空闲对象
|
|||
|
|
v = nextFreeFast(span)
|
|||
|
|
if v == 0 {
|
|||
|
|
v, span, _ = c.nextFree(spc) // span 不够时向 mcentral 申请
|
|||
|
|
}
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### 四、大对象分配 (>32KB)
|
|||
|
|
|
|||
|
|
大对象不走 mcache/mcentral，直接在 mheap 上分配：
|
|||
|
|
|
|||
|
|
```mermaid
|
|||
|
|
flowchart TD
|
|||
|
|
Req["分配 >32KB 对象"] --> Calc["计算需要的页数和 span class=0"]
|
|||
|
|
Calc --> SearchFree{"搜索 free 树"}
|
|||
|
|
SearchFree -->|找到| Split{span > 需求?}
|
|||
|
|
SearchFree -->|未找到| SearchScav{"搜索 scav 树<br/>已扫描的空闲 span"}
|
|||
|
|
SearchScav -->|找到| Split
|
|||
|
|
SearchScav -->|未找到| OSAlloc["向 OS 申请 mmap"]
|
|||
|
|
OSAlloc --> ReSearch["重新搜索 free + scav"]
|
|||
|
|
ReSearch --> Split
|
|||
|
|
Split -->|是| Divide["分割 span<br/>一部分给请求，余下放回 free"]
|
|||
|
|
Split -->|否| Done["直接使用"]
|
|||
|
|
Divide --> Done
|
|||
|
|
style Req fill:#e3f2fd
|
|||
|
|
style Done fill:#e8f5e9
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
> [!warning] ⚠️ 注意
|
|||
|
|
> 频繁分配超大对象会显著增加内存消耗和 GC 负担。建议对大数据使用 `[]byte` 复用或对象池（`sync.Pool`）。
|
|||
|
|
|
|||
|
|
### 五、Tiny Object 优化
|
|||
|
|
|
|||
|
|
Go 还有一个特殊类别：**Tiny Object**（1~16 字节且不含指针）。多个 tiny object 可以共用同一个 span 中的不同 slot，大幅减少小对象的数量浪费。
|
|||
|
|
|
|||
|
|
> [!info] ℹ️ 补充
|
|||
|
|
> Tiny object 从 Go 1.9 引入。对于常见的短字符串、小整数包装等场景，tiny object 能将内存利用率提升 50% 以上。
|
|||
|
|
|
|||
|
|
## 小结
|
|||
|
|
|
|||
|
|
- Go 内存管理基于 TCMalloc，分为 mcache（无锁）→ mcentral（加锁）→ mheap（OS 页面）三层
|
|||
|
|
- 小对象（≤32KB）按 67 种 span class 分类分配，每个 P 的 mcache 实现无锁
|
|||
|
|
- 大对象（>32KB）直接在 mheap 上分配，可能触发 OS mmap
|
|||
|
|
- Tiny object（1~16 字节无指针）可合并存放，节省内存
|
|||
|
|
|
|||
|
|
## 关联笔记
|
|||
|
|
|
|||
|
|
- [[hzh/GolangStar/Go语言原理/gmp调度原理]] — GMP 模型中 P 与 mcache 的关系
|
|||
|
|
- [[hzh/GolangStar/Go语言原理/逃逸分析]] — 变量分配到栈还是堆
|
|||
|
|
- [[hzh/GolangStar/Go语言原理/垃圾回收]] — GC 如何配合内存管理
|