Siyang's Blog

【翻译】深入理解 Go 运行时：垃圾回收器

Sat, 28 Mar 2026 22:32:29 +0800

本文章为译文，原作者 Jesús Espino。在这里查看他关于 Go Runtime 的系列文章：Understanding the Go Runtime

在上一篇文章中，我们探讨了 Go 调度器——goroutine 如何被多路复用到操作系统线程上、GMP 模型，以及运行时用来保持 CPU 忙碌的所有技巧。但我们还没有解决一个根本问题：所有这些 goroutine 都会分配内存，而必须有人来清理它们。这就是垃圾回收器的工作，也是我们今天要探讨的内容。

在本文中，我们将研究在 Go 1.26 中运行的垃圾回收器，该版本引入了 GreenTea GC。如果您使用的是更早版本的 Go，不用担心——整体结构是相同的。主要区别在于标记阶段，当我们讲到那里时，会简要说明旧方法的差异。如果您想了解更多关于 GreenTea 的信息，Michael Knyszek 在 GopherCon 2025 上做了一个关于它的精彩演讲。

Go 的垃圾回收器是一个非移动、并发、三色、标记-清除的回收器。形容词很多——但它们都意味着什么呢？让我们逐一分解。

非移动意味着 GC 从不重新定位内存中的对象。一旦一个对象被分配到一个特定的地址，它将在其整个生命周期中保持不变。这是一件大事——它意味着指针保持有效，这使得像 unsafe.Pointer 和 cgo 互操作这类事情简单得多。一些垃圾回收器（如 Java 的 G1 或 ZGC）确实会移动对象以压缩内存并减少碎片，但 Go 采取了不同的方法：它依赖其基于大小类的分配器来最小化碎片，而无需移动任何对象。

并发意味着 GC 的大部分工作是在程序持续运行的同时完成的。它不会在整个回收周期中停止世界（stop the world）（暂停所有 goroutine 以便只运行 GC）——只有两次非常短暂的暂停。其余时间，GC goroutine 与你的应用程序 goroutine 一起运行，共享 CPU 时间。

三色指的是标记阶段使用的算法。每个对象在概念上被标记为白色、灰色或黑色——我们稍后会详细介绍。

标记-清除描述了两种主要操作：首先，标记所有仍然可达（存活）的对象；然后，清除堆并回收任何未被标记的对象（垃圾）。概念上简单，但在实践中很棘手——尤其是当你的程序在 GC 试图追踪指针的同时还在修改指针时。

注意：本文引用了 Go 内存分配器的概念——特别是 span、size classes 以及 mcache/mcentral/mheap 层次结构。虽然并非严格要求的阅读材料，但我鼓励你先阅读内存分配器这篇文章。

【翻译】深入理解 Go 运行时：调度器

Mon, 16 Mar 2026 00:01:50 +0800

本文章为译文，原作者 Jesús Espino。在这里查看他关于 Go Runtime 的系列文章：Understanding the Go Runtime

在上一篇文章中，我们探讨了 Go 的内存分配器 (memory allocator) 如何管理堆内存——从操作系统获取大块区域 (arenas)，将它们划分为 spans 和大小类 (size classes)，并使用三级层次结构 (mcache, mcentral, mheap) 使得大多数分配操作无需加锁。其中一个关键细节是每个 P（处理器）都有自己的内存缓存。但我们从未真正解释过 P 是什么，或者运行时如何决定哪个 goroutine 在哪个线程上运行。这正是调度器的工作，也是我们今天要探讨的内容。

调度器是运行时中负责回答一个看似简单的问题的组件： 接下来该运行哪个 goroutine？ 你的程序中可能有成百上千甚至数百万个 goroutine，但 CPU 核心只有寥寥几个。调度器的工作就是将这些 goroutine 多路复用到少量的 OS 线程上，让每个核心都保持忙碌，同时确保没有 goroutine 会被饿死。

如果你曾经使用过 goroutine 和 channel，那么你已经在不知不觉中受益于调度器了。每一个 go 语句，每一次 channel 的发送和接收，每一个 time.Sleep ——它们都与调度器交互。让我们来看看它是如何工作的。

让我们从最基本的构建块开始——整个调度器所围绕的三个核心结构。

GMP 模型

调度器建立在三个概念之上，通常称为 GMP 模型 ： G（goroutine）， M（machine/OS 线程），以及 P（处理器）。我们在启动引导那篇文章中曾简单提及，现在让我们来仔细看看它们。

让我们逐一了解。

G — Goroutine

一个 G 就是一个 goroutine——Go 运行时对一段并发工作的表示。每当你写下 go f()，运行时就会创建一个（或复用一个）G 来跟踪该函数的执行。

【翻译】深入理解 Go 运行时：内存分配器

Mon, 16 Mar 2026 00:01:49 +0800

本文章为译文，原作者 Jesús Espino。在这里查看他关于 Go Runtime 的系列文章：Understanding the Go Runtime

在上一篇文章中，我们探讨了 Go 运行时如何引导自身 —— 从操作系统将控制权交给 Go 二进制文件，到你的 func main() 开始运行。在引导过程中，运行时最先设置的事情之一就是 内存分配器（memory allocator）。这就是我们今天要探索的内容。

可以把内存分配器想象成一个仓库管理员。你的程序不断需要不同大小的箱子 —— 有时很小，有时很大 —— 而且需要快速拿到它们。分配器的工作就是尽可能快地分发这些箱子，保持仓库井井有条以避免浪费，并与垃圾收集器协作，回收不再被使用的箱子。

但在我们深入了解仓库本身之前，先来聊聊数据实际在何时被放到那里。

何时发生内存分配？

并非程序中的每个变量都会经过内存分配器。Go 有两个存放数据的地方：栈（stack） 和 堆（heap）。

栈比较简单。每个函数调用都在栈上获得自己的一小块临时空间，当函数返回时，这块空间自动消失。它快速且简单 —— 无需记账。

但有时，数据需要在创建它的函数结束后继续存在。也许你返回了一个指向某物的指针，或者存储了一个程序其他部分稍后会使用的值。这些数据不能存活在栈上 —— 当函数返回时它们就会消失。因此它们被放在 堆（heap） 上，这是一个生命周期更长的内存区域。

Go 编译器在这方面实际上非常智能。它在编译时分析你的代码，以决定哪些数据可以留在栈上，哪些需要进入堆 —— 这被称为 逃逸分析（escape analysis）（我们在IR 文章中详细介绍过）。

每次有数据最终进入堆时，就是内存分配器发挥作用的时候了。它是在堆上寻找空闲空间并将其交出去的系统。这就是本文剩余部分要讲的内容。

一个小简化：上面的描述并不完整。在 Go 中，goroutine 的栈实际上是从堆上分配的 —— 所以是内存分配器提供了栈所需的空间。但是一旦栈被分配，其上的变量管理与堆对象的管理方式截然不同：它们只是栈帧中的偏移量，每个变量的分配不涉及分配器。因此，虽然分配器负责栈的内存，但它不参与将单个变量放置到栈上。在本文中，我们将聚焦于堆这方面。

所以分配器管理着堆内存。但这些内存最初又是从哪里来的呢？

为什么不直接向操作系统请求？

当你的程序需要内存时，总得有人提供它。最终，这个人就是操作系统。操作系统管理着机器上的所有物理 RAM，任何需要内存的进程都必须通过系统调用（如 Linux/macOS 上的 mmap 或 Windows 上的 VirtualAlloc）向操作系统请求。

【翻译】深入理解 Go 运行时：引导启动 (Bootstrap)

Mon, 16 Mar 2026 00:01:48 +0800

本文章为译文，原作者 Jesús Espino。在这里查看他关于 Go Runtime 的系列文章：Understanding the Go Runtime

当你编写 Go 代码时，背后发生了很多事情。goroutine 很轻量，channel 开箱即用，内存由运行时管理，你从来不需要考虑线程池。所有这一切都由 Go 运行时（Go runtime） 驱动——它是一个复杂的基础设施，会被编译进每一个 Go 二进制文件中。

这是本系列的第一篇文章，我们将从内部探究 Go 运行时。我们会研究 调度器（scheduler） 如何将 goroutine 多路复用到操作系统线程上，内存分配器（memory allocator） 如何实现无锁的快速路径分配，垃圾收集器（garbage collector） 如何在减少停顿时间的同时并发运行，以及 系统监控器（system monitor） 如何确保一切平稳运行。每个主题都将有各自深入的专门文章。

但在这些机制开始工作之前，它们必须被初始化。这就是 引导启动（bootstrap）——在操作系统启动你的二进制文件与你的 func main() 获得控制权之间运行的过程。这就是我们今天要探索的内容。

让我们从一个问题开始：Go 在“什么都不做”时有多快？

下面是一个 C 程序，它什么都不做：

int main() {
 return 0;
}

这是对应的 Go 程序：

package main

func main() {
}

让我们编译两者并进行比较：

$ gcc -o nothing_c nothing.c
$ go build -o nothing_go nothing.go

$ ls -lh nothing_c nothing_go
-rwxrwxr-x 1 user user 16K Feb 7 12:05 nothing_c
-rwxrwxr-x 1 user user 1.5M Feb 7 12:05 nothing_go

$ time ./nothing_c
real 0m0.001s

$ time ./nothing_go
real 0m0.002s

Go 的二进制文件几乎 大了 100 倍，运行时间大约 长了一倍。而且我们做的还 什么都不做。这是怎么回事？

关于一道面试题的分析：Batching HTTP 请求

Fri, 27 Feb 2026 02:25:02 +0800

最近在找工作，其中一家公司提出这道题目。

背景：FacesDetact() 只能串行调用，现在希望为程序添加批量处理功能，但不允许设置 delay 时间窗口，来一个请求，处理一个请求

分析：请求将会乱序到达，如果不设置数量或时间方面的窗口，其实程序需要处理的目标是积压态的网络请求（协程）

思路：如果需要对分散且独立到达的事件（参RxTS）做批量处理，其中必然需要有一个收束的阶段。如果能意识到这种现象的存在，最好是能意识到，可以针对该渠道做 batching 处理。在积压出现的时候，把被积压的请求进行批量取出，批量调用，然后返回

当时没有回答得很好，在处理请求装饰器的时候手忙脚乱，请求可以收拢，但生命周期如何管理呢？可能还是常见的编程范式用多了，哈哈，后来和 GPT 聊天，它虽然没有给出正确的答案，但它对 channel 的熟练运用到是给了我启发

Go 有「share memory by communicating」，我们可以控制权逆转，让我们的 handler 陷入 <-chan 的等待状态（当时是预期进行接口 HiJack）

后来想想，这不就是批量扇出扇入吗？查了下资料，的确是几乎完全一致的题目

下附草稿解答

 1package main
 2
 3import (
 4	"encoding/json"
 5	"fmt"
 6	"math"
 7	"net/http"
 8	"sync"
 9	"time"
 10)
 11
 12func main() {
 13	http.HandleFunc("/faces:detact", FacesDetactHandler)
 14	http.HandleFunc("/faces:detactv2", FacesDetactHandlerV2)
 15
 16	const listenAt = ":8080"
 17	fmt.Printf("serve at %s\n", listenAt)
 18	err := http.ListenAndServe(listenAt, http.DefaultServeMux)
 19
 20	if err != nil {
 21		fmt.Printf("http.ListenAndServe failed: %+v\n", err)
 22	}
 23}
 24
 25type Image []byte
 26
 27type Face struct{} /* position etc. */
 28
 29type DetactResult struct {
 30	Faces []Face `json:"faces"`
 31}
 32
 33func FacesDetactHandler(w http.ResponseWriter, r *http.Request) {
 34	type Req struct {
 35		Image Image `json:"image"`
 36	}
 37	var req Req
 38	var err error
 39	{
 40		err = json.NewDecoder(r.Body).Decode(&req)
 41		if err != nil {
 42			w.WriteHeader(http.StatusBadRequest)
 43			fmt.Fprintf(w, "error: %+v", err)
 44			return
 45		}
 46	}
 47
 48	result := FacesDetact([]Image{req.Image})
 49
 50	json.NewEncoder(w).Encode(result[0])
 51}
 52
 53type QueueItem struct {
 54	Image Image
 55	ResultWriteTo chan<- DetactResult // FIXME 可以根据情况分析有没有必要配置 len=1 的 buffer
 56}
 57
 58var queue chan QueueItem
 59
 60var FacesDetactHandlerV2Initial = sync.OnceFunc(func() {
 61	const maxBatchSize = 128
 62	queue = make(chan QueueItem, maxBatchSize+1)
 63	go func() {
 64		for {
 65			for queueIten := range queue {
 66				var todo = []QueueItem{queueIten}
 67				if len(queue) > 0 {
 68					consumeQuota := maxBatchSize - len(todo)
 69					if consumeQuota > len(queue) {
 70						consumeQuota = len(queue)
 71					}
 72					for i := 0; i < consumeQuota; i++ {
 73						todo = append(todo, <-queue)
 74					}
 75				}
 76
 77				var args []Image = make([]Image, len(todo))
 78				{
 79					for index, req := range todo {
 80						args[index] = req.Image
 81					}
 82				}
 83
 84				// enable to check how many req has been batching
 85				// fmt.Printf("args.length = %d\n", len(args))
 86				results := FacesDetact(args)
 87
 88				for index, result := range results {
 89					todo[index].ResultWriteTo <- result
 90				}
 91			}
 92		}
 93	}()
 94})
 95
 96func FacesDetactHandlerV2(w http.ResponseWriter, r *http.Request) {
 97	type Req struct {
 98		Image Image `json:"image"`
 99	}
100	var req Req
101	var err error
102	{
103		err = json.NewDecoder(r.Body).Decode(&req)
104		if err != nil {
105			w.WriteHeader(http.StatusBadRequest)
106			fmt.Fprintf(w, "error: %+v", err)
107			return
108		}
109	}
110
111	FacesDetactHandlerV2Initial()
112
113	resultQueue := make(chan DetactResult, 1)
114
115	queueReq := QueueItem{
116		Image: req.Image,
117		ResultWriteTo: resultQueue,
118	}
119
120	queue <- queueReq
121
122	result := <-resultQueue
123
124	json.NewEncoder(w).Encode(result)
125}
126
127var FacesDetactLocker sync.Mutex // 以防外部函数错误并行调用
128
129// FacesDetact 执行图像序列处理，因 GPU 底层限制，本函数不支持并行调用，请注意
130// images 与 results 为一对一的关系。本函数有冷启动时间，处理时间随图像数量近双曲线
131func FacesDetact(images []Image) (results []DetactResult) {
132	if len(images) <= 0 {
133		return
134	}
135	FacesDetactLocker.Lock()
136	defer FacesDetactLocker.Unlock()
137
138	results = make([]DetactResult, len(images))
139
140	time.Sleep(time.Duration(math.Pow(float64(len(images)), 0.1)) * 100 * time.Millisecond)
141
142	return
143}

在面试结束后重写优化以及调试的时候，观察数据会很有趣，因为机械压测带来的流量（like wrk but wrk2）很有规律，联合起 poolSize、具体耗时曲线、请求到达频次、放行逻辑，它们组成了一个可供线性规划的区域。

【翻译】软件工程中的认知负担（认知负荷才是关键）

Sun, 07 Sep 2025 12:09:00 +0800

这篇译文是 n1k0ver3E 和我一起翻译的，这里存档一下，他也完成了很多细致的审校工作，在这里对他表示感谢。如果读者想要阅读，推荐查看最新的版本

简介(Introduction)

这世上充斥着各种流行术语与“最佳实践”，但大多数最终都失灵了。我们需要更基础、更不可能出错的东西。

有时我们在阅读代码时会感到困惑。困惑消耗时间和金钱。困惑源于过高的“认知负荷”。它不是某种花哨的抽象概念，而是人类的一种基本约束。它不是臆想出来的，它的确存在，而且我们能真切感受到。

鉴于我们在阅读与理解代码上所花费的时间远多于书写代码所花费的，我们应当持续地自省：我们是否正在把过多的认知负荷添加到代码中。

认知负荷(Cognitive load)

认知负荷是指开发者为了完成一项任务需要动多少脑子。

阅读代码时，你会把变量的取值、控制流逻辑、调用序列等“装”进脑子里。普通人的工作记忆大约能同时容纳四个这样的信息块。一旦认知负荷接近这个阈值，理解就会变得困难得多。

假设我们被要求去修补一个完全陌生的项目。有人告诉我们，之前有位非常聪明的开发者贡献过：用了很多酷炫的架构、花哨的库、时髦的技术。也就是说，作者为我们制造了极高的认知负荷。

我们应该尽可能降低项目中的认知负荷。

我们会以一种非正式的方式使用“认知负荷”这个术语；有时它与认知负荷的科学概念一致，但我们并不确切知道在哪些地方一致、哪些地方不一致。

认知负荷的类型(Types of cognitive load)

内在负荷(Intrinsic)——由任务本身的固有难度引起。它不可消减，是软件开发的核心所在。

外在负荷(Extraneous)——由信息的呈现方式引入。由与任务不直接相关的因素造成，比如“聪明作者”的各种癖好。它可以被大幅削减。本文将聚焦于这种外在认知负荷。

下面直接看一些外在认知负荷的具体、可操作的例子。

我们将这样标注认知负荷的程度：
🧠：工作记忆刚刚清空，认知负荷为零
🧠++：工作记忆里已经有两个事实，认知负荷上升
🤯：认知过载，超过 4 个事实

我们的大脑远比这复杂且尚未被充分理解，但这个简化模型足以用来说明问题。

复杂的条件控制(Complex conditionals)

if val > someConstant // 🧠+
 && (condition2 || condition3) // 🧠+++, 前置条件需为 true，c2 或 c3 必须其一为 true
 && (condition4 && !condition5) { // 🤯, 到这一步我们基本已经被绕晕了
 ...
}

用有意义的中间变量重构：

isValid = val > someConstant
isAllowed = condition2 || condition3
isSecure = condition4 && !condition5 
// 🧠，无需死记条件表达式，变量名已自描述
if isValid && isAllowed && isSecure {
 ...
}

多层嵌套的 if 判断(Nested ifs)

if isValid { // 🧠+, 嵌套代码仅适用于有效输入
 if isSecure { // 🧠++, 仅对有效且安全的输入执行
 stuff // 🧠+++
 }
}

对比一下“提前返回”式的：

为什么再次书写博客

Tue, 10 Dec 2024 01:17:13 +0800

上一篇博客说到，看到互联网，所思所想。

背后的原因其实非常多。这涉及到我对“搭子”的理解，对互联网世界话语权的认识，对当今网络人群的见识。

最近几天一直在写日记，终于在昨天又搭建起这个博客。

其实我的一些想法在中间也陆陆续续在 Github 的 issue 区记录过。

前段时间又觉得，今天这样，明天那样，十年之后不知道什么样。既然以后可能对今日之事理所当然，那么为什么不在今天这个当下就记录下当局人的所思所想？

今晚就先写到这里吧，后面再修改。

似乎是时候重启博客

Mon, 09 Dec 2024 01:12:53 +0800

翻找记录，博客已经写了不止一次，最近看到互联网，所思所想。

还是再写起来吧。

但初心是再一次地新。