首页
Go语言101
Go自定义泛型101
Go细节与小技巧101
Go程序优化101
Go测验101
Go如何做101
Go编程实战101
Go聚合101
Go 101 博客
Go 101 应用和库

内存块

Go是一门支持自动内存管理的语言，比如自动内存开辟和自动垃圾回收。 所以Go程序员在编程时无须进行各种纷繁的内存管理操作。 这不仅给Go程序员提供了很多便利和节省了很多开发时间，而且也帮助Go程序员避免了很多因为疏忽大意而造成的bug。

在Go编程中，尽管我们无须知道底层的自动内存管理是如何实现的，但是知道自动内存管理实现中的一些概念和事实对我们写出高质量的Go代码是非常有帮助的。

本文将解释和列出标准编译器和运行时中内存块开辟和垃圾回收实现相关的一些概念和事实。 内存管理的其它方面，比如内存申请和内存释放，将不会在本文中探讨。

内存块（memory block）

一个内存块是一段在运行时刻承载着若干值部的连续内存片段。 不同的内存块的大小可能不同，因它们所承载的值部的尺寸而定。 一个内存块同时可能承载着不同Go值的若干值部，但是一个值部在内存中绝不会跨内存块存储，无论此值部的尺寸有多大。

一个内存块可能承载若干值部的原因有很多，这里仅列出一部分：

一个值引用着承载着它的值部的内存块

我们已经知道，一个值部可能引用着另一个值部。这里，我们将引用的定义扩展一下。 我们可以说一个内存块被它承载着的各个值部所引用着。 所以，当一个值部v被另一个值部引用着时，此另一个值部也（间接地）引用着承载着值部v的内存块。

什么时候需要开辟内存块？

在Go中，在下列场合（不限于）将发生开辟内存块的操作：

内存块将被开辟在何处？

对每一个使用标准编译器编译的Go程序，在运行时刻，每一个协程将维护一个栈（stack）。 一个栈是一个预申请的内存段，它做为一个内存池供某些内存块从中开辟。 在Go官方工具链1.19版本之前，一个栈的初始尺寸总是2KiB。 从1.19版本开始，栈的初始尺寸是自适应的。 每个栈的尺寸在协程运行的时候将按照需要增长和收缩。 栈的最小尺寸为2KiB。

（注意：Go运行时维护着一个协程栈的最大尺寸限制，此限制为全局的。 如果一个协程在增长它的栈的时候超过了此限制，整个程序将崩溃。 对于目前的官方标准Go官方工具链1.22版本，此最大限制的默认值在64位系统上为1GB，在32位系统上为250MB。 我们可以在运行时刻调用runtime/debug标准库包中的SetMaxStack来修改此值。 另外请注意，当前的官方标准编译器实现中，实际上允许的协程栈的最大尺寸为不超过最大尺寸限制的2的幂。 所以对于默认设置，实际上允许的协程栈的最大尺寸在64位系统上为512MiB，在32位系统上为128MiB。）

内存块可以被开辟在栈上。开辟在一个协程维护的栈上的内存块只能在此协程内部被使用（引用）。 其它协程是无法访问到这些内存块的。 一个协程可以无需使用任何数据同步技术而使用开辟在它的栈上的内存块上的值部。

堆（heap）是一个虚拟的概念。每个程序只有一个堆。 一般地，如果一个内存块没有开辟在任何一个栈上，则我们说它开辟在了堆上。 开辟在堆上的内存块可以被多个协程并发地访问。 在需要的时候，对承载在它们之上的值部的访问需要做同步。

如果编译器觉察到一个内存块在运行时将会被多个协程访问，或者不能轻松地断定此内存块是否只会被一个协程访问，则此内存块将会被开辟在堆上。 也就是说，编译器将采取保守但安全的策略，使得某些可以安全地被开辟在栈上的内存块也有可能会被开辟在堆上。

事实上，栈对于Go程序来说并非必要。Go程序中所有的内存块都可以开辟在堆上。 支持栈只是为了让Go程序的运行效率更高。

如果一个内存块被开辟在某处（堆上或某个栈上），则我们也可以说承载在此内存块上的各个值部也开辟在此处。

如果一个局部声明的变量的某些值部被开辟在堆上，则我们说这些值部以及此局部变量逃逸到了堆上。 我们可以运行Go官方工具链中提供的go build -gcflags -m命令来查看代码中哪些局部值的值部在运行时刻会逃逸到堆上。 如上所述，目前官方Go标准编译器中的逃逸分析器并不十分完美，因此某些可以安全地开辟在栈上的值也可能会逃逸到了堆上。

在运行时刻，每一个仍在被使用中的逃逸到堆上的值部肯定被至少一个开辟在栈上的值部所引用着。 如果一个逃逸到堆上的值是一个被声明为T类型的局部变量，则在运行时，一个*T类型的隐式指针将被创建在栈上。 此指针存储着此T类型的局部变量的在堆上的地址，从而形成了一个从栈到堆的引用关系。 另外，编译器还将所有对此局部变量的使用替换为对此指针的解引用。 此*T值可能从今后的某一时刻不再被使用从而使得此引用关系不再存在。 此引用关系在下面介绍的垃圾回收过程中发挥着重要的作用。

类似地，我们可以认为每个包级变量（常称全局变量）都被开辟在了堆上，并且它被一个开辟在一个全局内存区上的隐式指针所引用着。 事实上，此指针引用着此包级变量的直接部分，此直接部分又引用着其它的值（部）。

一个开辟在堆上的内存块可能同时被开辟在若干不同栈上的值部所引用着。

一些事实：

使用内置new函数开辟的内存可能开辟在堆上，也可能开辟在栈上。这是与C++不同的一点。

当一个协程的栈的大小（因为栈增长或者收缩而）改变时，一个新的内存段将申请给此栈使用。 原先已经开辟在老的内存段上的内存块将很有可能被转移到新的内存段上，或者说这些内存块的地址将改变。 相应地，引用着这些开辟在此栈上的内存块的指针（它们同样开辟在此栈上）中存储的地址也将得到刷新。 下面是一个展示开辟在栈上的值的地址改变的例子。 
package main

// 下面这行是为了防止f函数的调用被内联。
//go:noinline
func f(i int) byte {
	var a [1<<20]byte // 使栈增长
	return a[i]
}

func main(){
	var x int
	println(&x)
	f(100)
	println(&x)
}

我们可以看到，上例打引出的两个地址不一样（如果使用官方标准编译器1.22版本编译之）。

一个内存块在什么条件下可以被回收？

为包级变量的直接部分开辟的内存块永远不会被回收。

每个协程的栈将在此协程退出之时被整体回收，此栈上开辟的各个内存块没必要被一个一个单独回收。 栈内存池并不由垃圾回收器回收。

对一个开在堆上的内存块，当它不再被任何开辟在协程栈的仍被使用中的，以及全局内存区上的，值部所（直接或者间接）地引用着，则此内存块可以被安全地垃圾回收了。 我们称这样的内存块为不再被使用的内存块。开辟在堆上的不再被使用的内存块将在以后某个时刻被垃圾回收器回收掉。

下面是一个展示了一些内存块在何时可以被垃圾回收的例子。 
package main

var p *int

func main() {
	done := make(chan bool)
	// done通道将被使用在主协程和下面将要
	// 创建的新协程中，所以它将被开辟在堆上。

	go func() {
		x, y, z := 123, 456, 789
		_ = z  // z可以被安全地开辟在栈上。
		p = &x // 因为x和y都会将曾经被包级指针p所引用过，
		p = &y // 因此，它们都将开辟在堆上。

		// 到这里，x已经不再被任何其它值所引用。或者说承载
		// 它的内存块已经不再被使用。此内存块可以被回收了。

		p = nil
		// 到这里，y已经不再被任何其它值所引用。
		// 承载它的内存块可以被回收了。

		done <- true
	}()

	<-done
	// 到这里，done已经不再被任何其它值所引用。一个
	// 聪明的编译器将认为承载它的内存块可以被回收了。

	// ...
}

有时，聪明的编译器可能会做出一些出人意料的（但正确的）的优化。 比如在下面这个例子中，切片bs的底层间接值部在bs仍在使用之前就已经被标准编译器发觉已经不再被使用了。 
package main

import "fmt"

func main() {
	// 假设此切片的长度很大，以至于它的元素
	// 将被开辟在堆上。
	bs := make([]byte, 1 << 31)

	// 一个聪明的编译器将觉察到bs的底层元素
	// 部分已经不会再被使用，而正确地认为bs的
	// 底层元素部分在此刻可以被安全地回收了。

	fmt.Println(len(bs))
}

关于切片值的内部实现结构，请参考值部一文。

顺便说一下，有时候出于种种原因，我们希望确保上例中的bs切片的底层间接值部不要在fmt.Println调用之前被垃圾回收。 这时，我们可以使用一个runtime.KeepAlive函数调用以便让垃圾回收器知晓在此调用之前切片bs和它所引用着的值部仍在被使用中。

一个例子： 
package main

import "fmt"
import "runtime"

func main() {
	bs := make([]int, 1000000)

	fmt.Println(len(bs))
	runtime.KeepAlive(&bs)
	// 对于这个特定的例子，也可以调用
	// runtime.KeepAlive(bs)。
}

如何判断一个堆内存块是否仍在被使用？

目前的官方Go标准运行时（1.22版本）使用一个并发三色（tri-color）标记清扫（mark-sweep）算法来实现垃圾回收。 这里仅会对此算法的原理做一个大致的描述。一个具体实现可能和此大致描述会有很多细节上的差别。

一个垃圾回收过程分为两个阶段：标记阶段和清扫阶段。

在标记阶段，垃圾回收器（实际上是一组协程）使用三色算法来分析哪些（开辟在堆上的）内存块已经不再使用了。

（注意这里在算法中使用三色而不是两色的原因是此标记过程是并发的。在标记的过程中，很多其它普通用户协程也正在运行中。 在此标记过程中对指针的写入需要一些额外的开销，欲更深入了解此点，请以“write barrier golang”为关键字自行搜索以深入了解。 简而言之，当在某个用户协程中，一个已经标记为黑色的内存块在标记过程中被修改而使其新引用着的一个仍标记为白色的内存块时，此白色内存块需要被标记为灰色，否则此白色内存块有可能将被认为是垃圾而回收掉；除此之外的情况不做特殊处理。）

在清扫阶段，仍被标记为白色的内存块将被认为不再使用而被回收掉。

一个不再被使用的内存块被回收后可能并不会立即释放给操作系统，这样Go运行时可以将其重新分配给其它值部使用。 不用担心，官方Go运行时的实现比大多数主流的Java运行时要消耗少得多的内存。

此垃圾回收算法不会移动内存块来整理内存碎片。

不再被使用的内存块将在什么时候被回收？

垃圾回收过程将消耗相当的CPU资源和一些内存资源。所以垃圾回收过程并非总在运行。 一个新的垃圾回收过程将在程序运行中的某些实时指标达到某些条件时才会被触发。 这些条件怎么定义的是一个垃圾回收调度问题。

官方标准运行时（runtime）的垃圾回收调度实现仍在随着版本递增而在不断地改善中。 所以很难精确地描述此实现并同时保证描述的长期有效性。这里，我仅仅列出一些相关的参考文献：
目录↡

Go101.org网站内容包括Go编程各种相关知识（比如Go基础、Go优化、Go细节、Go实战、Go测验、Go工具等）。后续将不断有新的内容加入。敬请收藏关注期待。

本丛书微信公众号（联系方式一）名称为"Go 101"。二维码在网站首页。此公众号将时不时地发表一些Go语言相关的原创短文。各位如果感兴趣，可以搜索关注一下。

《Go语言101》系列丛书项目目前托管在Github上（联系方式二）。欢迎各位在此项目中通过提交bug和PR的方式来改进完善《Go语言101》丛书中的各篇文章。我们可以在项目目录下运行go run .来浏览和确认各种改动。

本书的twitter帐号为@Golang_101（联系方式三）。玩推的Go友可以适当关注。

你或许对本书作者老貘开发的一些App感兴趣。

The English version of this book is here.
赞赏
（《Go语言101》系列丛书由老貘从2016年7月开始编写。目前此系列丛书仍在不断改进和增容中。你的赞赏是本系列丛书和此Go101.org网站不断增容和维护的动力。）
目录：