---
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 如何配合内存管理