深入内幕 on 鹿鸣青野的blog

GMP 调度模型

Tue, 13 Oct 2026 00:00:00 +0000

C++ 里你要手写线程池、任务队列、负载均衡；Go 用 G/M/P 三件套在运行时层面把它全包了

一、简述

goroutine 不是 OS 线程，它比线程轻几个数量级。让几十万 goroutine 复用少数几个内核线程的，就是本章主角——GMP 调度模型。学完你会明白：go func() 背后发生了什么、为什么 goroutine 能在系统调用阻塞时"让位"、GOMAXPROCS 到底是什么、以及 M:N 用户态协程调度器是如何设计的。

核心要点：G（goroutine，任务）、M（Machine，OS 线程，工人）、P（Processor，调度上下文，工位）。P 的数量才是真正同时跑的 “线程数”，G 挂在 P 的本地队列上排队执行，M 抢到 P 才干活。运行时自动完成了 C++ 里你手写线程池 + 任务队列 + work-stealing 的全部工作。

二、C++ 对照速查表

概念	C++	Go	关键差异
并发执行单元	`std::thread`	goroutine (G)	`std::thread` 直接映射 OS 线程，G 是用户态任务
线程池	自写 / `BS::thread_pool` 等	内置 GMP	Go 运行时自动复用 M，无需自建池
任务队列	`std::queue<std::function>` + mutex	P 本地队列 runq	每个 P 有 256 长的本地队列，另有全局限队列
线程数量	自己定 / `std::thread::hardware_concurrency`	`GOMAXPROCS`（默认 = CPU 核数）	P 的数量决定并行度，M 可多于 P
线程阻塞迁移	无自动机制	M 阻塞时 P 移交	系统调用/锁阻塞时，P 被交给其它 M 继续执行 G
栈	固定大小（默认 1~8MB）	初始 2KB，动态增长	G 栈可扩容，按需分配
让出 CPU	无（靠 OS 时间片）	`runtime.Gosched()`	G 主动让出 P，避免饿死其它 G
抢占	内核时间片抢占	运行时信号抢占（Go 1.14+）	协作式 + 抢占式混合
work-stealing	手写	内置	空闲 P 偷其它 P 的队列任务，均衡负载
主线程	`int main()`	`m0` + `g0`	运行时专用线程和调度 goroutine

三、逐主题详解

3.1 三个字母分别是什么

┌──────────────────────────────────────────────────────────────┐
│ GMP 关系示意 │
│ │
│ G (goroutine) M (machine) P (processor) │
│ ┌──────┐ ┌───────┐ ┌─────────────┐ │
│ │ 用户 │ │ 内核 │ │ 调度上下文 │ │
│ │ 代码 │──调度于──→ │ OS线程 │──绑定于──→│ 本地队列 │ │
│ │ 栈G │ │ 栈M │ │ runq[256] │ │
│ └──────┘ └───────┘ └─────────────┘ │
│ 任务 工人 工位 │
└──────────────────────────────────────────────────────────────┘

G（goroutine）：一个待执行的函数 + 它的栈 + 上下文（寄存器现场）。创建的每个 go func() 都对应一个 G。它只是任务元数据，不是执行载体。G 结构体字段很长（src/runtime/runtime2.go），核心有栈描述 stack、当前函数 sched（保存 PC/SP）、状态 atomicstatus、所属 P 的指针、是否可被抢占等。
M（Machine）：真实的 OS 线程，由内核调度。M 负责真正执行 G 的机器码。创建 M 要付出系统调用成本（约 1MB 内核栈 + 内核结构，线程栈），远贵于创建 G。M 通常不超过几千个，且有上限（受系统资源约束，默认 maxmcount=10000）。
P（Processor）：你可以把它理解成"工位/许可令牌"。P 里有本地可运行队列 runq（长度 256）。G 想被调度运行，必须先被放进某个 P 的 runq，然后 P 绑定到某个 M 上执行队列里的 G。
P 的数量 = GOMAXPROCS（默认取 CPU 逻辑核数），它决定了同一时刻真正并行执行的 goroutine 上限。P 多了，并行度就高；P = 1 时行为接近单线程。

C++ 对照：M ≈ 一个真正运行在 CPU 上的线程；P ≈ 每个线程手头那个任务队列；G ≈ 任务队列里的任务项。你写线程池时是"一个线程，抢全局任务队列"，Go 优化成"每线程一队列 + 偷取"，减少锁竞争。

Go 内存模型：happens-before

Tue, 13 Oct 2026 00:00:00 +0000

C++ 有 std::atomic + 内存序（memory_order），Go 有更少的口子但边界更清楚——channel / Mutex / Once / atomic 各自建立 happens-before

一、简述

“变量加了锁就不会有竞态"这种直觉在并发世界里是危险的。真正需要回答的问题是：goroutine A 写了一个值，goroutine B 什么时候能确定读到它？ Go 用一份官方文档——The Go Memory Model——精确规定了这些"什么时候”。它定义了 happens-before 关系：同步原语（channel、Mutex、WaitGroup、Once、atomic）在收发/加解锁/等待/原子操作之间建立序，从而保证内存可见性。理解它，你才知道为什么"不加同步 flag 读 bool"可能读到旧值，也才知道怎么写出不靠运气的并发程序。

核心要点：happens-before（HB）是"一个事件必须在另一个事件之前发生且其结果可见"的形式化保证。Go 的并发正确性全部建立在"你用了某个同步原语，它就给你对应的一条 HB 边"上。不用原语 = 没有边 = 编译器/硬件随便重排。

二、C++ 对照速查表

概念	C++	Go	关键差异
内存模型文档	`[memory_order]` 标准章节	The Go Memory Model（官方文档）	C++ 需要你精确选 memory_order；Go 不给选项，只规定用了哪个同步原语获得哪条 HB 边
互斥锁	`std::mutex` 加锁/解锁	`sync.Mutex` Lock/Unlock	C++ 还要额外配 `atomic` 才能安全读共享变量；Go 锁内一切可见
放松内存序	`memory_order_relaxed`	无对应概念	Go 只有两档：同步原语→对应 HB 保证，非同步→无保证
原子操作	`std::atomic<T>`（load/store/fetch等）	`sync/atomic`	Go 1.19 之前 atomic 只防撕裂不建 HB；1.19+ 视作同步点
初始化一次	`std::once_flag`	`sync.Once`	`once.Do` 完成后，所有 `Do` 返回点看到其写入
线程等待	`std::thread::join`	`sync.WaitGroup.Wait`	`Wait` 返回后看到各 `Done` 的写入
通信同步	`mutex`+`cv` 手写	channel	收发建立 HB，官方推荐优先 channel
主动读屏障	`atomic_thread_fence`	无直接对应	Go 用 `atomic.Load`/互斥代替 fence
悬而未决的"下次可见"	无	“稍后某个时刻可见"是合法但无保证	这是最常见的 bug 来源
数据竞争检测	TSan（第三方）	`go test -race` 内建	干干净净的"竞态即报”

三、逐主题详解

3.1 你已经在 C++ 里见过的"序"

C++ 的 memory_order 有三种强度：relaxed（无序）、acquire/release（只保证可见但不能越过）、seq_cst（全局一致）。Go 的模型把选择收敛成一条规则：

pprof 性能调优

Tue, 13 Oct 2026 00:00:00 +0000

C++ 里要弄 4~5 套工具（perf / valgrind / gprof / TSan）；Go 把 CPU、内存、goroutine、锁的剖面图都装进了一个 pprof

一、简述

性能调优第一步永远不是"猜"，是"量"。Go 的 pprof（profile）机制提供一套统一的剖析框架：CPU、堆内存、分配、goroutine、锁竞争、阻塞延时的剖面数据，既能离线抓（runtime/pprof、go test -cpuprofile），也能在线实时抓（net/http/pprof）。配合 go tool pprof 的 top / list / peek / web 交互和火焰图，你能在几分钟内定位 CPU 热点、内存黑洞、goroutine 泄漏。对用惯 perf/valgrind/gprof 的 C++ 开发者来说，这是一次"多工具合一"的升级。

核心要点：pprof 是采样式剖析：按频率打断程序，记录当时正在执行的函数调用栈，最后统计"每个函数在多少样本里出现"。flat 是"函数自己耗的"，cum 是"含它调用的所有子函数"——读懂这两个数字是使用 pprof 的核心。

二、C++ 对照速查表

概念	C++	Go	关键差异
CPU 剖析	`perf record/report`	`runtime/pprof` + `cpu.prof`	Go 内置采样器，无需 perf_event 权限
堆内存剖析	`valgrind --tool=massif` / `heaptrack`	`memprofile` + heap view	pprof 同时给 inuse/alloc 两维度
线级热点	`perf annotate`	`go tool pprof -list`	直接给源码行统计
火焰图	`perf script` + 第三方 FlameGraph	`go tool pprof -http`（内链火焰图）	一命令内建
死锁/锁竞争	手写 + `helgrind`	mutex/block profile	并发调优必备
调用图	`gprof`（编译期插桩）	pprof 自动采样	Go 无插桩成本，直接采样
内存泄漏排查	`valgrind --leak-check`	goroutine profile + `alloc_objects`	Go 看"分配来源"而非"泄漏点"
运行中抓取	需 `perf` 权限/SAMPLING	`net/http/pprof` 一键开	线上服务开端口即可

三、逐主题详解

3.1 profile 是什么：采样式剖析

时间轴 ──────────────────────────────────────────►
采样点：每隔 t（如 100 次/秒 = 10ms）触发 SIGPROF
每次记录：当前 goroutine 的完整调用栈（PC → 函数名）
┌────┐┌────┐┌────┐┌────┐
│foo ││bar ││foo ││baz │ 每个采样点保留栈帧
│ main││ foo││ main││ foo │ 最后统计: foo 出现 3/4 次
└────┘└────┘└────┘└────┘

CPU profile：默认每 10ms（100Hz）采样一次正在执行的 G 的栈。只有"在 CPU 上运行"的 G 会被采到——所以纯 IO/阻塞的 goroutine 在 CPU profile 里很低。
heap profile：不是采样，是快照。记录"当前存活对象"的分配点（用于看内存滞留）或"累计分配"（-alloc_space/-alloc_objects，用于看分配大山）。
goroutine profile：每个 goroutine 当前栈（含状态），看泄漏。
mutex/block profile：记录锁等待与阻塞事件（需要 runtime.SetBlockProfileRate / SetMutexProfileFraction 开启）。

3.2 离线抓取：`runtime/pprof` 与 `go test -profile`

方式一：go test 直接出谱（最常用）

unsafe 与 cgo 互操作

Tue, 13 Oct 2026 00:00:00 +0000

C++ 的 reinterpret_cast + extern "C" 在 Go 里被装进了两个官方包：unsafe（打破类型/GC 规则）和 cgo（跨语言边界）

一、简述

Go 追求内存安全，但现实里有三类需求绕不开"不安全"：解析二进制布局、优化热路径、调用 C 库。Go 给的两把钥匙：unsafe 包的 unsafe.Pointer 允许你绕过类型系统（但仍受 GC 语义约束），cgo 允许你直接调用 C 函数（import "C" + //export 双向互操作）。本章把两者的语义、内存规则、坑、风险一次性讲透——很多线上故障就是从"玩 unsafe 没算清 GC"或"cgo 调用频繁导致线程放大"开始的。

核心要点：unsafe.Pointer 像"元指针"，可被 GC 追踪；uintptr 只是整数，GC 不追踪——所以不允许"把指针存成 uintptr 长期持有"。cgo 让你调 C，但每次调用都伴随 goroutine 栈切换与可能的线程膨胀，且 C.CString 分配的内存必须自己 C.free。CGO_ENABLED=0 是纯静态交叉编译的开关，代价是放弃 cgo。

二、C++ 对照速查表

概念	C++	Go	关键差异
无类型转换	`reinterpret_cast<T*>`	`unsafe.Pointer` 转换	Go 的三步规则更受限，且有 GC 约束
类型大小	`sizeof(T)`	`unsafe.Sizeof(x)`	一样，但 Go 的 `Sizeof` 返回 `uintptr`
对齐要求	`alignof(T)`	`unsafe.Alignof(x)`	语义相同
成员偏移	`offsetof`	`unsafe.Offsetof(s.F)`	Go 对嵌套/嵌入结构有规则限制
指针算术	`p + n`（任意）	`uintptr(p) + n` 转回	Go 用 uintptr 防 GC 丢对象（坑）
跨语言符号	`extern "C"`	`//export` / 声明	Go 还自动处理了 C 的 ABI 与参数传值
头文件	`#include`	`// #include <...>` 注释块 + `import "C"`	cgo 注释必须紧跟 import
C 字符串生命周期	`std::string`/手管 char*	`C.CString` → `C.free`	Go 里 C 内存在你的掌控（GC 不管）
跨语言回调	函数指针显式传	`//export` 导出给 C	回调时 cgo 会切换刻意绑的线程
交叉编译	工具链编译 C 代码	`CGO_ENABLED=0` 纯 Go	纯 Go 无 cgo 才能一路交叉到底

三、逐主题详解

3.1 `unsafe` 包三件套：Sizeof / Alignof / Offsetof

package main

import (
 "fmt"
 "unsafe"
)

type Header struct {
 Magic uint16 // 2 字节
 Flags byte // 1 字节
 Body uint32 // 4 字节（需要对齐）
}

func main() {
 h := Header{}
 fmt.Println("Sizeof:", unsafe.Sizeof(h)) // 8（不是 2+1+4=7，有 padding）
 fmt.Println("Alignof:", unsafe.Alignof(h)) // 4（最大成员对齐）
 fmt.Println("Offsetof Magic:", unsafe.Offsetof(h.Magic)) // 0
 fmt.Println("Offsetof Flags:", unsafe.Offsetof(h.Flags)) // 2
 fmt.Println("Offsetof Body:", unsafe.Offsetof(h.Body)) // 4（3 处 padding 1 字节填在中间）
}

Offsetof 要求字段是可寻址的（s.F 形式，不能是未导出字段）。
这些原语从 1.0 至今，官方 docs 明确：unsafe 不提供兼容性承诺，后续版本可能变——但在已知版本内是可靠的。
C++ 对照：sizeof/alignof/offsetof 早已内建，返回 size_t；Go 返回 uintptr。布局算法的直觉（对齐、padding）两者完全一致——你可以把你对 C++ 结构体内存布局的知识直接迁移过来。

3.2 `unsafe.Pointer` 与 `uintptr` 的区别（本章最核心）

特性	`unsafe.Pointer`	`uintptr`
本质	指针（与 `*T` 同族）	整数（地址的编号）
GC 追踪	✅ 是（对象可达性参与）	❌ 不是（就是个数字）
可做算术	❌ 不能直接 `+n`	✅ 可以
可长期保存	✅（Go 1.17+ 合法）	❌ 存久了=可能悬垂
转换	`T` ↔ `unsafe.Pointer` ↔ `U`	`uintptr(unsafe.Pointer(...))`

p := unsafe.Pointer(&x) // &x 是 *int → unsafe.Pointer（合法）
up := uintptr(p) // 转成整数（此时"失去指针身份"）
_ = up
// ⚠️ 一旦 p 指向的对象被 GC 移动/回收，up 就是"悬垂整数"
// Go 的 GC 不移动对象，但会回收；up 长期保存=访问已释放内存（未定义行为）

官方三步规则（Go 文档的『Conversion』/『Restrictions』，一共 7 条），核心是三种合法模式：

反射（reflection）

Tue, 13 Oct 2026 00:00:00 +0000

C++ 的 RTTI 只能拿到 typeid/dynamic_cast 少许信息；Go 的 reflect 能在运行时查看、遍历、修改任意类型与值

一、简述

反射（reflection）：程序在运行时检查自身的类型与结构，并据此做动态操作。Go 里就是 reflect 包：给你 reflect.Type（类型信息）和 reflect.Value（一段具体值），能动态读字段、读 tag、调方法、甚至修改可设置的值。序列化库（encoding/json）、ORM、配置解析、测试断言统统建立在这套 API 之上。但反射有显著的性能代价与脆弱性——本章教你怎么用、什么时候值得用。

核心要点：反射的入口是 reflect.TypeOf / reflect.ValueOf，一切操作都围着这两个对象转；可设置性（CanSet） 是反射修值的前提（变量要可寻址）；三大定律是官方给的使用边界。对 C++ 来说，typeid/dynamic_cast 只能做"类型识别"，Go 反射还能"改值、建新值、动态调用"，范围大得多，代价也大得多。

二、C++ 对照速查表

概念	C++	Go	关键差异
类型识别	`typeid(x).name()`	`reflect.TypeOf(x)`	C++ 只给名字，Go 给结构、字段、方法全图
运行时类型转换	`dynamic_cast<T>`（须多态）	首选类型断言 `x.(T)`；reflect 侧有 `Type.AssignableTo` / `ConvertibleTo` / `Implements` 做判断、`Value.Convert` 做转换	Go 反射不要求继承，直接看类型；reflect 包没有 `AssertableTo` 方法
遍历字段	`boost::pfr`/手写	`reflect.Value.NumField/Field`	Go 原生支持任意结构体遍历
读字段 tag	无标准机制	`reflect.StructTag.Get`	Go 的 struct tag 是反射的主要消费场景
动态改值	`*T` + `reinterpret_cast` 危险操作	`reflect.Value.Set*`	Go 有 `CanSet` 检查，越界即 panic
动态调用方法	`std::invoke`（C++17，仍要具体类型）	`reflect.Value.Method(i).Call(...)`	Go 无需编译期函数指针，纯运行时
创建新实例	`T{}` 写死 / 工厂模式	`reflect.New(T)`	反射可"凭空造值"，C++ 做不到通用
性能	零开销（编译期类型）	每次反射调用开销 ~几百 ns 起	Go 反射充满动态分派与检查
应用场景	typeid 用于调试/序列化	序列化/ORM/测试/DI	反射生态在 Go 里是日常
类型断言	C++ 无	`x.(T)` 是内置语法	注意反射 `TypeOf` + 断言可以互相换算

三、逐主题详解

3.1 反射两大入口：Type 与 Value

package main

import (
 "fmt"
 "reflect"
)

type Person struct {
 Name string `json:"name"`
 Age int `json:"age"`
}

func main() {
 p := Person{Name: "小甲", Age: 18}

 t := reflect.TypeOf(p) // 类型信息
 v := reflect.ValueOf(p) // 值信息

 fmt.Println("Type:", t) // main.Person
 fmt.Println("Kind:", t.Kind()) // struct
 fmt.Println("Value:", v) // {小甲 18}
 fmt.Println("TypeOf(v):", v.Type()) // main.Person
}

reflect.Type：描述"类型是什么"——包名、名称、Kind、字段列表、方法集、是否可比较等。URI：t.NumField()、t.Field(i)、t.Method(i)。
reflect.Value：描述"这段值是什么"——包含了底层值，可读可设（受 CanSet 约束）、可调方法、可转 interface。
Kind()：底层类别（Int、String、Slice、Struct、Map 等 26 种）。Type 是具体类型（main.Person），Kind 是粗类别（struct）——C++ 里没有直接对应，最接近 typeid 得不到 Kind；Go 里 Kind 用于判断"数据结构形状"。

3.2 从 Value 取回具体值：`Interface()`

v := reflect.ValueOf(p)
// 把 Value 还原成 interface{}
i := v.Interface()
// 再断言回具体类型
p2 := i.(Person)
fmt.Println(p2.Name) // 小甲

老代码里 v.Interface() + 类型断言是组合拳；Go 1.x 有 v.CanInterface() 检查（未导出字段、flag 受限时不可 Interface()）。
原则：反射只是"绕到类型系统后面看一眼"，看完一定要回到具体类型继续干活。

3.3 对 struct 字段遍历与 tag 读取（json 的底层原理）

func dumpStruct(s any) {
 v := reflect.ValueOf(s)
 t := v.Type()

 fmt.Printf("类型: %s\n", t)
 for i := 0; i < v.NumField(); i++ {
 field := t.Field(i) // reflect.StructField
 val := v.Field(i) // reflect.Value
 tag := field.Tag.Get("json") // 读 tag

 fmt.Printf(" 字段 %s kind=%v 值=%v tag=%q\n",
 field.Name, field.Type.Kind(), val.Interface(), tag)
 }
}

dumpStruct(Person{Name: "张三", Age: 22})
// 输出：
// 类型: main.Person
// 字段 Name kind=string 值=张三 tag="name"
// 字段 Age kind=int 值=22 tag="age"

这就是 encoding/json 的底层机制：遍历 struct 字段 → 看 json:"xxx" tag 决定键名/跳过 → 按字段类型编码/解码。
StructTag.Get("json") 可以返回 name,omitempty 这样的组合串（Lookup 可区分"有但空"和"没有"）。
字段可以是导出（大写）或未导出（小写）；未导出字段反射读值会 panic，写值 CanSet=false。

3.4 可设置性（CanSet）与修改值

反射改值前提：值必须是可以寻址的（addressable）。reflect.ValueOf(p) 拿到的是拷贝的 p——改它改不到原对象。

三色 GC 与写屏障

Tue, 13 Oct 2026 00:00:00 +0000

C++ 的 RAII/智能指针是"代码到哪回收到哪"；Go 的 GC 让事情自动发生——代价是你必须理解它何时跑、怎么跑

一、简述

Go 从 1.5 开始使用并发三色标记-清除垃圾回收器：标记阶段与应用并发跑，通过写屏障保证并发下的正确性，把 STW（Stop-The-World，全停）压缩到毫秒级。本章剖析三色算法、写屏障原理、GC 触发时机（GOGC / GOMEMLIMIT）、gctrace 日志解读，以及从 C++ 视角看"自动回收"带来的确定性问题。

核心要点：垃圾回收的本质是"追踪所有存活对象的引用图"。三色让追踪与程序运行并发，写屏障保证并发期间引用关系不变而漏标对象；GOGC==100 的意思是"堆翻倍时才触发下一次 GC"。理解这些，你才能在调优时不被玄学推着走。

二、C++ 对照速查表

概念	C++	Go	关键差异
生命周期管理	`new`/`delete`、RAII、`shared_ptr`	自动 GC	C++ 确定、Go 不确定（回收时点不定）
引用计数	手写计数 / `shared_ptr`	无引用计数	Go 用可达性分析，无循环引用问题
循环引用	`weak_ptr` 打破	天然解决	三色标记只关心可达性
悬垂指针	`shared_ptr` 防悬垂、`weak_ptr` 观测	不可能悬垂（GC 保证活着就安全）	但 `unsafe` 除外
析构时机	作用域结束/`shared_ptr` 归零	不确定（对象 GC 后才回收内存）	需要清理副作用时必须显式 `Close`
手动释放	`delete`	*不存在（`runtime.GC()` 只建议回收）	别依赖手工 GC
触发条件	无	heap 增长到阈值 / 周期 / 显式	`GOGC`、`GOMEMLIMIT` 控制
停顿	无（确定性）	少量 STW（毫秒级）	现在基本无感，但被 K8s CPU 限流仍可能抖动
代价感知	手工优化分配	分配快、回收不确定	追求低延迟要控制分配率

三、逐主题详解

3.1 为什么要 GC：先看可达性

GC 不关心"这块内存是不是有人 stack 上引用"的细节，只关心一件事：从根（root）出发，你能走到哪些对象？

逃逸分析与内存分配

Tue, 13 Oct 2026 00:00:00 +0000

C++ 里 new/delete、智能指针、内存池全靠手写；Go 用逃逸分析 + 分级分配器把"栈还是堆"自动定好了

一、简述

在 Go 里写 x := 42，变量到底放栈上还是堆上，不由你说了算，由编译器说了算。这个"说了算"的过程叫逃逸分析（escape analysis）。它决定了一个变量能否安全地呆在栈上（函数返回就免费销毁），还是必须逃逸到堆（交给 GC 管理）。这直接关系到顺滑度、GC 压力与性能——理解了它，你就从"手动管内存"（C++）切换到"理解自动管内存"（Go）的思维。

核心要点：栈上分配 = 零 GC 压力、函数返回即释放；堆上分配 = 每次都要触发 GC 或分配器。逃逸分析的目标很简单：能放栈就不放堆。用 go build -gcflags="-m" 就能窥见编译器的决策过程。

二、C++ 对照速查表

概念	C++	Go	关键差异
栈上分配	`int x;`（RAII，作用域结束自动析构）	`x := 42`，若未逃逸	Go 编译器决定，不是你决定
堆上分配	`new` / `malloc`，手动 `delete`	变量逃逸时自动堆分配	Go 无需/不能手动释放
智能指针	`shared_ptr` / `unique_ptr` 管理引用	GC 统一管理	逃逸对象由 GC 回收，无引用计数
返回局部对象	悬垂指针风险（返回局部地址）	返回局部指针 → 自动逃逸到堆，安全	见下方示例，关键差异
内存池/对象池	手写 `objpool` / 复用 vector	分配器内建（mcache → mcentral → mheap）	Go 内置分级分配器
大小类(size class)	手写	编译期确定，分配器按 size class 取块	C++ 分配器可替代，Go 内建
允许拷贝后仍安全	深拷贝麻烦	值语义默认，复制即深拷贝	逃逸分析顺带优化拷贝去重
大对象堆分配	依赖 malloc 行为	>32KB 直接 mheap，不经过 mcache	阈值不同，直觉一致
接口装箱	`void*` 转换，手动管理生命周期	具体值→`interface{}` 可能逃逸	装箱常伴随逃逸

三、逐主题详解

3.1 栈 vs 堆：先建立直觉

┌─────────────────── 栈（Stack）───────────────────┐
│ main() 的帧 │
│ ├─ 局部变量 x: 42 ← 编译器决定放这 │
│ └─ 调用 f() 的帧 │
│ └─ f 返回时，这一帧整体弹出，"免费释放" │
└─────────────────────────────────────────────────┘
┌─────────────────── 堆（Heap）───────────────────┐
│ 对象：(指向它的指针被 main 拿走了) │
│ 生命周期：直到 GC 认为没人引用它才回收 │
│ 成本：分配（分配器查找空闲块）+ 回收（GC 扫描） │
└─────────────────────────────────────────────────┘

栈上的变量：随函数帧创建/销毁。函数返回时，栈指针回落，整块内存"原地废弃"——无分配成本、无释放成本、无 GC 参与。这正是 C++ 栈对象的免费午餐。
堆上的变量：生命周期逃出当前函数，必须由 GC 跟踪回收。分配要走分配器、回收要看 GC 何时跑，每一笔都有成本。

Go 与 C++ 的最大不同：C++ 里 int x; 一定在栈上、new int 一定在堆上、返回局部变量地址=悬垂指针（未定义行为）。Go 里同一段代码，编译器可能让变量留在栈上，也可能挪去堆——全看会不会"逃逸"出当前函数。返回局部变量的指针在 Go 里完全安全：

深入内幕 on 鹿鸣青野的blog

GMP 调度模型

一、简述

二、C++ 对照速查表

三、逐主题详解

3.1 三个字母分别是什么

Go 内存模型：happens-before

一、简述

二、C++ 对照速查表

三、逐主题详解

3.1 你已经在 C++ 里见过的"序"

pprof 性能调优

一、简述

二、C++ 对照速查表

三、逐主题详解

3.1 profile 是什么：采样式剖析

3.2 离线抓取：runtime/pprof 与 go test -profile

unsafe 与 cgo 互操作

一、简述

二、C++ 对照速查表

三、逐主题详解

3.1 unsafe 包三件套：Sizeof / Alignof / Offsetof

3.2 unsafe.Pointer 与 uintptr 的区别（本章最核心）

反射（reflection）

一、简述

二、C++ 对照速查表

三、逐主题详解

3.1 反射两大入口：Type 与 Value

3.2 从 Value 取回具体值：Interface()

3.3 对 struct 字段遍历与 tag 读取（json 的底层原理）

3.4 可设置性（CanSet）与修改值

三色 GC 与写屏障

一、简述

二、C++ 对照速查表

三、逐主题详解

3.1 为什么要 GC：先看可达性

逃逸分析与内存分配

一、简述

二、C++ 对照速查表

三、逐主题详解

3.1 栈 vs 堆：先建立直觉

3.2 离线抓取：`runtime/pprof` 与 `go test -profile`

3.1 `unsafe` 包三件套：Sizeof / Alignof / Offsetof

3.2 `unsafe.Pointer` 与 `uintptr` 的区别（本章最核心）

3.2 从 Value 取回具体值：`Interface()`