Golang高级：3.2 内存管理与垃圾回收

在 Go 的性能问题里，CPU 往往只是表象，真正决定系统稳定性的，很多时候是内存行为：对象是如何分配的、什么时候逃逸到堆上、GC 为什么开始变频繁、为什么同样的业务逻辑会突然出现延迟抖动。

这一章不讲“背几个概念就结束”，而是从运行时设计出发，把 Go 的内存分配器、堆栈策略、逃逸分析、三色标记 GC、调优手段，以及 sync.Pool 的正确使用方式串起来。读完之后，你应该能回答下面这些工程问题：

为什么 Go 的小对象分配通常很快
为什么“返回指针”不一定就会上堆，但很多对象还是会逃逸
为什么 GC 次数会突然增加，且延迟抖动变大
GOGC 调高之后到底发生了什么
“内存压舱石（memory ballast）”为什么曾经流行，如今又为什么要谨慎使用
sync.Pool 到底是对象池，还是缓存

一、Go 内存分配器：TCMalloc 思想

Go 的内存分配器并不是直接照搬操作系统的 malloc，而是借鉴了 TCMalloc（Thread-Caching Malloc） 的核心思想：

按大小分级（size class）管理对象，减少碎片和元数据开销
线程/处理器本地缓存优先分配，避免频繁加锁
小对象和大对象走不同路径，让高频分配尽量便宜

Go runtime 里的实现细节和 TCMalloc 并不完全相同，但整体设计哲学非常一致。理解时可以抓住几个关键层次：

组件	作用	可以怎样理解
`mcache`	每个 P（Processor）私有的小对象缓存	分配热点对象时优先从本地拿，减少锁竞争
`mcentral`	按 size class 管理 span 的中心缓存	本地缓存不够时，从这里批量补货
`mheap`	管理更大粒度的页（page/span）	更底层的堆内存来源
tiny allocator	处理极小对象的特殊优化	避免为几个字节的对象付出完整分配成本

这里的关键不是死记结构名，而是理解 “分层缓存 + 按大小分类 + 批量获取” 这个设计。它直接解释了为什么 Go 对大量小对象分配相对友好。

1. 小对象为什么便宜

如果每次申请 16 字节、32 字节、64 字节都直接去找全局堆、加锁、切页、维护复杂元数据，那么高并发程序会非常慢。Go 的做法是：

把对象大小映射到 size class
先尝试从当前 P 绑定的 mcache 中拿对象
mcache 不够时，再从 mcentral 批量获取 span
只有更底层不够时，才向 mheap 甚至操作系统申请更多页

因此，小对象分配的热点路径通常很短。

2. 大对象为什么要单独处理

大对象如果还强行塞进小对象 size class，会导致两个问题：

内部碎片明显增大
管理粒度不合适，浪费 span

所以大对象往往会走更直接的路径，从更大粒度的 span/page 中分配。

3. 一个容易忽略的事实

分配快，不代表可以随便分配。

很多 Go 程序的性能问题，不是分配动作本身慢，而是：

分配频率太高，导致 GC 压力上升
对象生命周期不合理，短命垃圾过多
大量临时切片、字符串、map 节点反复创建

所以理解分配器的意义，不是为了“赞叹 runtime 很强”，而是为了在写代码时减少无意义分配。

4. 观察不同尺寸对象分配行为

下面的示例不会直接把 mcache/mcentral 的内部状态打印出来，但它能帮助你建立一个工程上的直觉：不同大小、不同数量的对象，会在 HeapAlloc、HeapInuse、Mallocs 上呈现出明显不同的增长模式。

package main

import (
	"fmt"
	"runtime"
)

func printMemStats(stage string) {
	var m runtime.MemStats
	runtime.ReadMemStats(&m)
	fmt.Printf("[%s] HeapAlloc=%d KB HeapInuse=%d KB Mallocs=%d NumGC=%d\n",
		stage,
		m.HeapAlloc/1024,
		m.HeapInuse/1024,
		m.Mallocs,
		m.NumGC,
	)
}

func allocBlocks(blockSize, count int) [][]byte {
	blocks := make([][]byte, 0, count)
	for i := 0; i < count; i++ {
		b := make([]byte, blockSize)
		b[0] = byte(i)
		blocks = append(blocks, b)
	}
	return blocks
}

func main() {
	runtime.GC()
	printMemStats("start")

	sizes := []struct {
		name  string
		size  int
		count int
	}{
		{name: "tiny-like", size: 16, count: 200000},
		{name: "small", size: 128, count: 100000},
		{name: "medium", size: 32 * 1024, count: 2000},
		{name: "large", size: 2 * 1024 * 1024, count: 8},
	}

	var keep [][][]byte
	for _, item := range sizes {
		blocks := allocBlocks(item.size, item.count)
		keep = append(keep, blocks)
		printMemStats(item.name)
	}

	fmt.Println("保留部分对象，模拟程序仍然持有引用")
	_ = keep[0][0][0]
	_ = keep[3][0][0]
}

一次实际运行输出如下：

[start] HeapAlloc=7235 KB HeapInuse=7584 KB Mallocs=1781 NumGC=2
[tiny-like] HeapAlloc=15096 KB HeapInuse=15432 KB Mallocs=201794 NumGC=2
[small] HeapAlloc=29951 KB HeapInuse=30272 KB Mallocs=301810 NumGC=3
[medium] HeapAlloc=93968 KB HeapInuse=94272 KB Mallocs=303841 NumGC=5
[large] HeapAlloc=110400 KB HeapInuse=110712 KB Mallocs=303861 NumGC=5
保留部分对象，模拟程序仍然持有引用

从这个结果里可以读出三个信息：

小对象会让 Mallocs 飙升得很明显，因为对象个数非常多
中等尺寸对象会快速推高 HeapAlloc
大对象数量不多，但单次增量大，对堆占用非常敏感

这正是 Go 分配器按大小分类处理的现实背景。

二、堆与栈的分配策略

很多人会把 Go 的内存分配理解成一句口号：

“局部变量在栈上”
“new 出来的在堆上”

这两句话都不准确。

Go 不是按你写了什么语法来决定对象在哪，而是由 编译器根据逃逸分析结果 决定：

如果对象的生命周期可以完全限制在当前调用栈内，就尽量放栈上
如果对象可能在函数返回后仍被外部引用，就必须放到堆上

1. 栈分配的特点

栈分配通常具备这些优势：

特性	栈上对象
分配速度	极快，通常只是移动栈指针
回收成本	函数返回时自动回收，无需 GC 逐个扫描
局部性	更好，CPU cache 友好
适合场景	生命周期短、作用域明确、不会逃逸

2. 堆分配的特点

堆分配不是“坏事”，但成本更高：

特性	堆上对象
生命周期	可跨函数、跨 goroutine 存活
分配成本	通常高于栈，且后续要参与 GC
使用场景	被外部引用、需要长期存在、结构较复杂
风险	对象过多会增加 GC 压力

3. 判断逻辑的本质

关键不在于对象“长得像值”还是“长得像指针”，而在于：

它会不会在当前函数外继续被使用
它会不会被装箱进接口
它会不会被闭包或 goroutine 捕获
编译器能不能证明它是局部且安全的

4. 示例：只在函数内部使用 vs 逃逸到全局变量

下面这个程序用 testing.AllocsPerRun 做一个很直观的实验：一个对象只在函数内部使用，另一个对象被放进全局变量，结果完全不同。

package main

import (
	"fmt"
	"testing"
)

type Point struct {
	X int
	Y int
}

var globalPoint *Point

func stackOnly() int {
	p := Point{X: 10, Y: 20}
	return p.X + p.Y
}

func forceHeap() {
	p := &Point{X: 10, Y: 20}
	globalPoint = p
}

func main() {
	stackAllocs := testing.AllocsPerRun(1000, func() {
		_ = stackOnly()
	})

	heapAllocs := testing.AllocsPerRun(1000, func() {
		forceHeap()
	})

	fmt.Printf("仅在函数内部使用: allocs/run = %.2f\n", stackAllocs)
	fmt.Printf("对象逃逸到全局变量: allocs/run = %.2f\n", heapAllocs)
	fmt.Printf("globalPoint=%+v\n", *globalPoint)
}

一次实际运行输出如下：

仅在函数内部使用: allocs/run = 0.00
对象逃逸到全局变量: allocs/run = 1.00
globalPoint={X:10 Y:20}

这段代码说明了两件事：

栈/堆不是语法决定的，而是“是否逃逸”决定的
一旦对象生命周期超出当前栈帧，GC 成本就跟着进来了

三、逃逸分析（Escape Analysis）

逃逸分析是 Go 编译器进行内存决策的核心机制。它要回答的问题只有一个：

这个对象能不能安全地待在当前栈帧里？

如果答案是否定的，对象就必须移动到堆上。

1. 常见的逃逸场景

在日常开发中，最常见的逃逸来源有：

场景	为什么会逃逸
返回局部变量指针	函数返回后对象仍需要存活
被接口 `any/interface{}` 持有	可能发生装箱，生命周期扩大
被闭包捕获	闭包可能晚于当前函数结束才执行
传入 goroutine	新 goroutine 的执行时机独立于当前栈帧
放入全局变量 / 堆对象字段	生命周期超出当前函数

2. 为什么逃逸分析很关键

逃逸本身不意味着代码错误，但它会影响：

分配次数
GC 扫描对象数量
堆增长速度
延迟稳定性

如果一个高频函数每次调用都制造几个不必要的堆对象，那么在高 QPS 场景下，GC 压力会非常明显。

3. 用 `go build -gcflags="-m"` 看编译器判断

下面是一个完整可运行示例：

package main

import "fmt"

type User struct {
	Name string
	Age  int
}

func buildOnStack() User {
	u := User{Name: "stack", Age: 18}
	return u
}

func buildOnHeap() *User {
	u := User{Name: "heap", Age: 20}
	return &u
}

func printAny(v any) {
	fmt.Println(v)
}

func main() {
	stackUser := buildOnStack()
	heapUser := buildOnHeap()
	printAny(stackUser.Name)
	fmt.Println(heapUser.Age)
}

编译命令：

go build -gcflags="-m" escape_demo.go

实际输出示例如下：

# command-line-arguments
examples/go-memory-gc/escape_demo.go:10:6: can inline buildOnStack
examples/go-memory-gc/escape_demo.go:15:6: can inline buildOnHeap
examples/go-memory-gc/escape_demo.go:20:6: can inline printAny
examples/go-memory-gc/escape_demo.go:21:13: inlining call to fmt.Println
examples/go-memory-gc/escape_demo.go:25:27: inlining call to buildOnStack
examples/go-memory-gc/escape_demo.go:26:25: inlining call to buildOnHeap
examples/go-memory-gc/escape_demo.go:27:10: inlining call to printAny
examples/go-memory-gc/escape_demo.go:28:13: inlining call to fmt.Println
examples/go-memory-gc/escape_demo.go:27:10: inlining call to fmt.Println
examples/go-memory-gc/escape_demo.go:16:2: moved to heap: u
examples/go-memory-gc/escape_demo.go:20:15: leaking param: v
examples/go-memory-gc/escape_demo.go:21:13: ... argument does not escape
examples/go-memory-gc/escape_demo.go:27:20: stackUser.Name escapes to heap
examples/go-memory-gc/escape_demo.go:27:10: ... argument does not escape
examples/go-memory-gc/escape_demo.go:28:13: ... argument does not escape
examples/go-memory-gc/escape_demo.go:28:22: heapUser.Age escapes to heap

4. 如何解读这些输出

重点看几类提示：

moved to heap: u：局部变量 u 被放到堆上了
leaking param: v：参数的生命周期被延展，可能逃逸
xxx escapes to heap：某个值因为装箱或传递方式，最终进了堆

要注意，-m 输出不是“性能判决书”，而是编译器给你的线索。真正需要你关注的是：

这个逃逸是否发生在热点路径上
是否能通过改写 API 或减少装箱来避免
避免后，代码是否仍然清晰可维护

5. 一个重要认知：不要为了“零逃逸”写出糟糕代码

逃逸分析是优化工具，不是教条目标。

下面这些做法往往比“强行消灭每个逃逸”更重要：

避免高频路径上的无意义接口装箱
避免循环里频繁创建临时对象
对大对象、缓冲区、编码器等高频复用资源做优化
先定位热点，再做有证据的优化

如果一个对象本来就应该跨函数、跨 goroutine 存活，那么它上堆完全正常。

四、垃圾回收器原理：三色标记法

Go 的 GC 是并发垃圾回收器。理解它时，最重要的基础模型就是 三色标记法。

1. 三种颜色分别表示什么

颜色	含义
白色	尚未被发现的对象；GC 结束时仍是白色，就会被回收
灰色	已经发现，但它引用的子对象还没扫描完
黑色	自身已扫描完成，且其可达子对象都已处理

GC 的核心过程可以概括为：

从根对象（栈、全局变量、寄存器等）开始标记
根对象先变成灰色
不断从灰色集合中取对象，扫描它引用的对象
扫描完成后把当前对象染成黑色
当灰色集合为空时，剩余白色对象就是不可达垃圾

2. 为什么一定要有“灰色”状态

如果只有黑白两种颜色，那么扫描过程中就无法区分：

“已经发现，但还没展开扫描”的对象
“彻底扫描完成”的对象

灰色状态实际上就是 GC 的工作队列。

3. 一个 ASCII 图示

下面用一个对象图来说明三色标记的推进过程：

对象引用关系：

Root --> A --> C
   \      \
    \      --> D
     --> B

E 为孤立对象（没有任何根可达）

初始状态：

黑色: (空)
灰色: Root
白色: A B C D E

扫描 Root 后：

黑色: Root
灰色: A B
白色: C D E

扫描 A 后：

黑色: Root A
灰色: B C D
白色: E

继续扫描直到灰色集合为空：

黑色: Root A B C D
灰色: (空)
白色: E   <- 不可达，将被回收

4. 写屏障为什么重要

如果程序在 GC 标记的同时还在修改对象引用关系，就可能破坏三色不变式。例如：

一个黑色对象新增了对白色对象的引用
但 GC 并不知道这件事
最终可能把仍然可达的对象误回收

这就是为什么现代并发 GC 必须依赖 写屏障（write barrier）。Go 当前 GC 的工程实现会结合三色标记和屏障机制，保证并发标记阶段的正确性。

5. 示例：用可达性变化观察对象被回收

下面这个示例使用 runtime.SetFinalizer 辅助观察“对象何时变得不可达”。

注意：finalizer 只适合教学演示，不适合作为业务控制流手段。

package main

import (
	"fmt"
	"runtime"
	"time"
)

type Node struct {
	name     string
	children []*Node
}

func newNode(name string) *Node {
	n := &Node{name: name}
	runtime.SetFinalizer(n, func(node *Node) {
		fmt.Println("finalizer: 回收节点", node.name)
	})
	return n
}

func main() {
	root := newNode("root")
	left := newNode("left")
	right := newNode("right")
	leaf := newNode("leaf")

	root.children = []*Node{left, right}
	left.children = []*Node{leaf}

	fmt.Println("第一次 GC：对象仍然可达，不应触发 finalizer")
	runtime.GC()
	time.Sleep(200 * time.Millisecond)

	fmt.Println("断开 root -> left 的引用后，再次触发 GC")
	root.children[0] = nil
	left = nil
	leaf = nil
	runtime.GC()
	runtime.KeepAlive(root)
	runtime.KeepAlive(right)
	time.Sleep(200 * time.Millisecond)

	fmt.Println("最后释放整棵树")
	root = nil
	right = nil
	runtime.GC()
	runtime.GC()
	time.Sleep(500 * time.Millisecond)
}

一次实际运行输出如下：

第一次 GC：对象仍然可达，不应触发 finalizer
断开 root -> left 的引用后，再次触发 GC
finalizer: 回收节点 left
最后释放整棵树
finalizer: 回收节点 leaf
finalizer: 回收节点 root
finalizer: 回收节点 right

这个结果告诉你：

只要对象还在可达链上，它就不会被回收
一旦从根对象断开，子图就可能在后续 GC 中被清理
finalizer 的执行时机和顺序并不严格稳定，因此它只是“观察窗口”，不是精确调度工具

五、GC 调优：`GOGC` 参数与内存压舱石

GC 调优最容易踩的坑，就是只会一句“把 GOGC 调大”。实际上，调优需要先理解 Go 的 GC 触发逻辑。

1. `GOGC` 到底控制什么

GOGC 控制的是：相对于上一次存活堆大小，堆还能增长多少比例时触发下一轮 GC。

可以粗略理解为：

GOGC=100：允许堆在“存活数据”基础上大约再增长 100%
GOGC=200：允许堆增长更多，GC 更少，但峰值内存更高
GOGC=50：更积极回收，内存更省，但 GC 更频繁

简化理解公式如下：

next_gc ≈ live_heap + live_heap * GOGC / 100

2. 调 `GOGC` 的本质是空间换时间

调整方向	结果
调高 `GOGC`	GC 次数减少，但堆峰值和 RSS 可能升高
调低 `GOGC`	GC 更积极，内存占用下降，但 CPU/延迟压力可能上升

所以问题从来不是“100 好还是 200 好”，而是：

你的服务是内存敏感，还是延迟敏感
业务对象是否大量短命
峰值流量时，RSS 是否会挤压容器限制

3. 什么是“内存压舱石（memory ballast）”

所谓 ballast，就是程序启动时人为分配一块大内存，并长期持有引用，让 runtime 认为“当前堆基线更大”，从而减少 GC 的触发频率。

它历史上曾被一些低延迟服务使用，原因是：

更大的堆基线意味着更少的 GC 轮次
某些场景下可以换来更平滑的尾延迟

但它的问题也很明显：

会显著抬高常驻内存
对容器环境和内存限制并不友好
只是“间接影响 GC 节奏”，不是精准治理手段

在现代 Go 版本里，很多场景更推荐优先考虑 减少分配、控制对象生命周期、结合内存上限机制，而不是默认上 ballast。

4. 示例：观察 `GOGC` 与 ballast 对 GC 次数的影响

下面程序支持两种实验方式：

默认运行：按当前 GOGC 做持续分配
USE_BALLAST=1：先持有 128MB ballast，再观察变化

package main

import (
	"fmt"
	"os"
	"runtime"
	"runtime/debug"
	"strconv"
)

func mustGetenvInt(key string, def int) int {
	if value := os.Getenv(key); value != "" {
		parsed, err := strconv.Atoi(value)
		if err == nil {
			return parsed
		}
	}
	return def
}

func churn(rounds int) {
	for i := 0; i < rounds; i++ {
		buf := make([]byte, 512*1024)
		buf[0] = byte(i)
	}
}

func printStats(stage string) {
	var m runtime.MemStats
	runtime.ReadMemStats(&m)
	fmt.Printf("[%s] HeapAlloc=%d MB HeapSys=%d MB NumGC=%d\n",
		stage,
		m.HeapAlloc/1024/1024,
		m.HeapSys/1024/1024,
		m.NumGC,
	)
}

func main() {
	gogc := mustGetenvInt("GOGC", 100)
	old := debug.SetGCPercent(gogc)
	defer debug.SetGCPercent(old)

	fmt.Println("当前 GOGC =", gogc)

	var ballast []byte
	if os.Getenv("USE_BALLAST") == "1" {
		ballast = make([]byte, 128*1024*1024)
		for i := 0; i < len(ballast); i += 4096 {
			ballast[i] = 1
		}
		fmt.Println("已启用 ballast: 128MB")
	}

	printStats("start")
	churn(300)
	printStats("after churn")

	if len(ballast) > 0 {
		fmt.Println("ballast 仍被引用，程序结束前不会释放")
	}
}

默认运行的一次输出如下：

当前 GOGC = 100
[start] HeapAlloc=7 MB HeapSys=10 MB NumGC=0
[after churn] HeapAlloc=18 MB HeapSys=33 MB NumGC=13

启用 ballast，并把 GOGC 调到 200 的一次输出如下：

当前 GOGC = 200
已启用 ballast: 128MB
[start] HeapAlloc=135 MB HeapSys=138 MB NumGC=1
[after churn] HeapAlloc=285 MB HeapSys=290 MB NumGC=1
ballast 仍被引用，程序结束前不会释放

从这个实验可以看到非常典型的权衡：

GC 次数确实可能显著下降
但堆占用和常驻内存上升得也非常明显

这类手段适不适合，必须结合部署环境、容器 limit、尾延迟目标一起看，而不是机械套用。

5. 调优建议：先做这些，再碰参数

优先级	建议
高	先减少热点路径上的对象分配
高	先缩短对象生命周期，减少短命垃圾
中	再观察 `GOGC` 对吞吐与 RSS 的影响
中	对极端低延迟场景再评估 ballast 这类手段
低	不要只凭压测一次结果就永久固化参数

一个成熟的经验是：GC 参数调优永远排在“减少无效分配”之后。

六、`sync.Pool` 的正确使用

sync.Pool 经常被误解成“万能缓存”或“对象池框架”。其实它的定位更窄：

它适合缓存可重复创建、可重复使用、且丢了也没关系的临时对象，以减少短期分配压力。

1. `sync.Pool` 适合什么

典型适用对象：

bytes.Buffer
strings.Builder
临时编码器/解码器包装对象
请求处理过程中的临时 []byte 容器

它们共同特点是：

生命周期短
复用收益高
不承载业务语义
就算下一次 Get 拿不到旧对象，也不影响正确性

2. `sync.Pool` 不适合什么

下面这些就不适合：

错误用法	为什么不合适
把连接、文件句柄塞进去长期复用	这类资源需要明确生命周期管理
把业务对象当缓存存进去	GC 后 pool 可能被清空，语义不可靠
`Put` 前不重置状态	容易造成脏数据复用
放很大的对象且长期不用	可能增加内存滞留

3. 一个关键原则：`sync.Pool` 不能参与程序正确性

你不能写出这样的逻辑：

“如果 pool 里有对象，我就能拿到上次那个值”
“这个对象我存在 pool 里，稍后一定还能取回来”

因为 Go runtime 在任意一次 GC 后，都可能清空 pool 中的对象。

4. 示例：复用 `bytes.Buffer`

下面是一个正确示例：

package main

import (
	"bytes"
	"fmt"
	"sync"
)

var bufferPool = sync.Pool{
	New: func() any {
		fmt.Println("创建新的 bytes.Buffer")
		return new(bytes.Buffer)
	},
}

func encodeLogLine(level, msg string) string {
	buf := bufferPool.Get().(*bytes.Buffer)
	buf.Reset()
	defer bufferPool.Put(buf)

	fmt.Fprintf(buf, "[%s] %s", level, msg)
	return buf.String()
}

func main() {
	messages := []struct {
		level string
		msg   string
	}{
		{level: "INFO", msg: "worker started"},
		{level: "WARN", msg: "cache miss"},
		{level: "INFO", msg: "worker finished"},
	}

	for _, item := range messages {
		line := encodeLogLine(item.level, item.msg)
		fmt.Println(line)
	}

	fmt.Println("注意：sync.Pool 里的对象可能在任意一次 GC 后被清空，不能把它当成持久缓存。")
}

一次实际运行输出如下：

创建新的 bytes.Buffer
[INFO] worker started
[WARN] cache miss
[INFO] worker finished
注意：sync.Pool 里的对象可能在任意一次 GC 后被清空，不能把它当成持久缓存。

这里有几个关键点：

使用 New 提供兜底创建逻辑
每次拿到对象后先 Reset()，避免脏状态残留
Put() 的对象只是“给 runtime 一个复用机会”，不是“保存起来以后一定还能拿到”
返回的是 buf.String() 生成的结果值，而不是把池中的对象继续向外泄露

5. 实战经验

在高并发服务里，sync.Pool 最常见的价值不是“把所有对象都池化”，而是对少数高频、短命、可重置的临时对象做精确优化。例如：

日志格式化 buffer
JSON 编码中转 buffer
RPC 编解码过程中的暂存对象
压缩/解压过程里的临时结构

如果你发现自己打算把一个复杂业务对象图放进 sync.Pool，那通常说明设计方向已经偏了。

七、结语

Go 的内存管理并不神秘，但它绝不是“交给 runtime 就行”的黑盒。真正的工程能力体现在三个层面：

理解分配器：知道小对象为什么快，大对象为什么敏感
理解编译器：知道堆栈分配取决于逃逸分析，而不是语法表象
理解 GC 权衡：知道 GOGC、ballast、sync.Pool 本质上都在做“分配频率、内存占用、延迟稳定性”的平衡

如果把这一章压缩成一句话，那就是：

Go 的性能优化，很多时候不是“让 CPU 跑更快”，而是“少制造垃圾、让对象活得更合理”。

当你能开始从“对象生命周期”和“分配行为”视角审视代码时，很多看似玄学的性能问题，都会变得具体而可解释。

📝 版权声明：本文为原创技术博客，转载请注明出处。

如文章中存在错误或不准确之处，欢迎在评论区指正，感谢您的阅读与支持！

Golang高级：3.2 内存管理与垃圾回收

一、Go 内存分配器：TCMalloc 思想

1. 小对象为什么便宜

2. 大对象为什么要单独处理

3. 一个容易忽略的事实

4. 观察不同尺寸对象分配行为

二、堆与栈的分配策略

1. 栈分配的特点

2. 堆分配的特点

3. 判断逻辑的本质

4. 示例：只在函数内部使用 vs 逃逸到全局变量

三、逃逸分析（Escape Analysis）

1. 常见的逃逸场景

2. 为什么逃逸分析很关键

3. 用 go build -gcflags="-m" 看编译器判断

4. 如何解读这些输出

5. 一个重要认知：不要为了“零逃逸”写出糟糕代码

四、垃圾回收器原理：三色标记法

1. 三种颜色分别表示什么

2. 为什么一定要有“灰色”状态

3. 一个 ASCII 图示

4. 写屏障为什么重要

5. 示例：用可达性变化观察对象被回收

五、GC 调优：GOGC 参数与内存压舱石

1. GOGC 到底控制什么

2. 调 GOGC 的本质是空间换时间

3. 什么是“内存压舱石（memory ballast）”

4. 示例：观察 GOGC 与 ballast 对 GC 次数的影响

5. 调优建议：先做这些，再碰参数

六、sync.Pool 的正确使用

1. sync.Pool 适合什么

2. sync.Pool 不适合什么

3. 一个关键原则：sync.Pool 不能参与程序正确性

4. 示例：复用 bytes.Buffer

5. 实战经验

七、结语

3. 用 `go build -gcflags="-m"` 看编译器判断

五、GC 调优：`GOGC` 参数与内存压舱石

1. `GOGC` 到底控制什么

2. 调 `GOGC` 的本质是空间换时间

4. 示例：观察 `GOGC` 与 ballast 对 GC 次数的影响

六、`sync.Pool` 的正确使用

1. `sync.Pool` 适合什么

2. `sync.Pool` 不适合什么

3. 一个关键原则：`sync.Pool` 不能参与程序正确性

4. 示例：复用 `bytes.Buffer`