学习过C语言的都知道，在C栈区域会存放函数的参数、局部变量等，而这些局部变量的地址是不能返回的，除非是局部静态变量地址，字符串常量地址或者动态分配的地址，因为程序调用完函数后，局部变量会随着此函数的栈帧一起被释放。而对于程序员主动申请的内存则存储在堆上，需要使用malloc等函数进行申请，同时也需要使用free等函数释放，由程序员进行管理，而申请内存后如果没有释放，就有可能造成内存泄漏。

但是在Go中，程序员根本无需感知数据是在栈（Go栈）上，还是在堆上，因为编译器会帮你承担这一切，将内存分配到栈或者堆上。在编译器优化中，逃逸分析是用来决定指针动态作用域的方法。Go语言的编译器使用逃逸分析决定哪些变量应该分配在栈上，哪些变量应该分配在堆上，包括使用new、make和字面量等方式隐式分配的内存，Go语言逃逸分析遵循以下两个不变性：

1. 指向栈对象的指针不能存在于堆中；
2. 指向栈对象的指针不能在栈对象回收后存活；

逃逸分析是在编译阶段进行的，可以通过go build -gcflags="-m -m -l"命令查到逃逸分析的结果，最多可以提供4个-m, m 越多则表示分析的程度越详细，一般情况下我们可以采用两个-m分析。使用-l禁用掉内联优化，只关注逃逸优化即可。

1. 几种逃逸分析

1.1 函数返回局部变量的指针

package main

func Add(x, y int) *int {
   res := 0
   res = x + y
   return &res
}

func main() {
   Add(1, 2)
}

逃逸分析结果如下：

$ go build -gcflags="-m -m -l" ./main.go
# command-line-arguments
./main.go:4:2: res escapes to heap:
./main.go:4:2:   flow: ~r2 = &res:
./main.go:4:2:     from &res (address-of) at ./main.go:6:9
./main.go:4:2:     from return &res (return) at ./main.go:6:2
./main.go:4:2: moved to heap: res
note: module requires Go 1.18

分析结果很明显，函数返回的局部变量是一个指针变量，当函数Add执行结束后，对应的栈帧就会被销毁，引用返回到函数之外，如果在外部解引用这个地址，就会导致程序访问非法内存，所以编译器会经过逃逸分析后在堆上分配内存。

1.2 interface(any)类型逃逸

package main

import (
   "fmt"
)

func main() {
   str := "hello world"
   fmt.Printf("%v\n", str)
}

逃逸分析如下：

$ go build -gcflags="-m -m -l" ./main.go
# command-line-arguments
./main.go:9:13: str escapes to heap:
./main.go:9:13:   flow: {storage for ... argument} = &{storage for str}:
./main.go:9:13:     from str (spill) at ./main.go:9:13
./main.go:9:13:     from ... argument (slice-literal-element) at ./main.go:9:12
./main.go:9:13:   flow: {heap} = {storage for ... argument}:
./main.go:9:13:     from ... argument (spill) at ./main.go:9:12
./main.go:9:13:     from fmt.Printf("%v\n", ... argument...) (call parameter) at ./main.go:9:12
./main.go:9:12: ... argument does not escape
./main.go:9:13: str escapes to heap

通过这个分析你可能会认为str escapes to heap表示这个str逃逸到了堆，但是却没有上一节中返回值中明确写上moved to heap: res，那实际上str是否真的逃逸到了堆上呢？

escapes to heap vs moved to heap

我们可以写如下代码试试：

package main

import "fmt"

func main() {
   str := "hello world"
   str1 := "nihao!"
   fmt.Printf("%s\n", str)
   println(&str)
   println(&str1)
}

其逃逸分析和上面的没有区别：

$ go build -gcflags="-m -m -l" ./main.go
# command-line-arguments
./main.go:8:13: str escapes to heap:
./main.go:8:13:   flow: {storage for ... argument} = &{storage for str}:
./main.go:8:13:     from str (spill) at ./main.go:8:13
./main.go:8:13:     from ... argument (slice-literal-element) at ./main.go:8:12
./main.go:8:13:   flow: {heap} = {storage for ... argument}:
./main.go:8:13:     from ... argument (spill) at ./main.go:8:12
./main.go:8:13:     from fmt.Printf("%s\n", ... argument...) (call parameter) at ./main.go:8:12
./main.go:8:12: ... argument does not escape
./main.go:8:13: str escapes to heap
note: module requires Go 1.18

但是，str1和str二者的地址却是明显相邻的，那是怎么回事呢？

$ go run main.go
hello world
0xc00009af50
0xc00009af40

如果我们将上述代码的第8行fmt.Printf("%s\n", str)改为fmt.Printf("%p\n", &str)，则逃逸分析如下，发现多了一行moved to heap: str：

$ go build -gcflags="-m -m -l" ./main.go
# command-line-arguments
./main.go:6:2: str escapes to heap:
./main.go:6:2:   flow: {storage for ... argument} = &str:
./main.go:6:2:     from &str (address-of) at ./main.go:8:21
./main.go:6:2:     from &str (interface-converted) at ./main.go:8:21
./main.go:6:2:     from ... argument (slice-literal-element) at ./main.go:8:12
./main.go:6:2:   flow: {heap} = {storage for ... argument}:
./main.go:6:2:     from ... argument (spill) at ./main.go:8:12
./main.go:6:2:     from fmt.Printf("%p\n", ... argument...) (call parameter) at ./main.go:8:12
./main.go:6:2: moved to heap: str
./main.go:8:12: ... argument does not escape
note: module requires Go 1.18

再看运行结果，发现看起来str的地址看起来像逃逸到了堆，毕竟和str1的地址明显不同：

$ go run main.go
0xc00010a210
0xc00010a210
0xc000106f50

参考如下解释：

When the escape analysis says “b escapes to heap”, it means that the values in b are written to the heap. So anything referenced by b must be in the heap also. b itself need not be.

翻译过来大意是：当逃逸分析输出“b escapes to heap”时，意思是指存储在b中的值逃逸到堆上了，即任何被b引用的对象必须分配在堆上，而b自身则不需要；如果b自身也逃逸到堆上，那么逃逸分析会输出“&b escapes to heap”。

由于字符串本身是存储在只读存储区，我们使用切片更能表现以上的特性。

切片指针和底层数组无逃逸

package main

import (
   "reflect"
   "unsafe"
)

func main() {
   var i int
   i = 10
   println("&i", &i)
   b := []int{1, 2, 3, 4, 5}
   println("&b", &b) // b这个对象的地址
   println("b", unsafe.Pointer((*reflect.SliceHeader)(unsafe.Pointer(&b)).Data)) // b的底层数组地址
}


逃逸分析是：

$ go build -gcflags="-m -m -l" ./main.go
# command-line-arguments
./main.go:12:12: []int{...} does not escape
note: module requires Go 1.18

打印结果：

$ go run main.go
&i 0xc00009af20
&b 0xc00009af58
b 0xc00009af28


可以看到，以上分析无逃逸，且&i b &b地址连续，可以明显看到都在栈中。

切片底层数组逃逸

我们新增一个fmt包的打印：

package main

import (
   "fmt"
   "reflect"
   "unsafe"
)

func main() {
   var i int
   i = 10
   println("&i", &i)
   b := []int{1, 2, 3, 4, 5}
   println("&b", &b) // b这个对象的地址
   println("b", unsafe.Pointer((*reflect.SliceHeader)(unsafe.Pointer(&b)).Data)) // b的底层数组地址
   fmt.Println(b) // 多加了这行
}

逃逸分析如下：

$ go build -gcflags="-m -m -l" ./main.go
# command-line-arguments
./main.go:16:13: b escapes to heap:
./main.go:16:13:   flow: {storage for ... argument} = &{storage for b}:
./main.go:16:13:     from b (spill) at ./main.go:16:13
./main.go:16:13:     from ... argument (slice-literal-element) at ./main.go:16:13
./main.go:16:13:   flow: {heap} = {storage for ... argument}:
./main.go:16:13:     from ... argument (spill) at ./main.go:16:13
./main.go:16:13:     from fmt.Println(... argument...) (call parameter) at ./main.go:16:13
./main.go:13:12: []int{...} escapes to heap:
./main.go:13:12:   flow: b = &{storage for []int{...}}:
./main.go:13:12:     from []int{...} (spill) at ./main.go:13:12
./main.go:13:12:     from b := []int{...} (assign) at ./main.go:13:4
./main.go:13:12:   flow: {storage for b} = b:
./main.go:13:12:     from b (interface-converted) at ./main.go:16:13
./main.go:13:12: []int{...} escapes to heap
./main.go:16:13: ... argument does not escape
./main.go:16:13: b escapes to heap
note: module requires Go 1.18

可以发现，出现了b escapes to heap，然后查看打印：

$ go run main.go
&i 0xc000106f38
&b 0xc000106f58
b 0xc000120030
[1 2 3 4 5]

可以发现，b的底层数组发生了逃逸，但是b本身还是在栈中。

切片指针和底层数组都发生逃逸

package main

import (
   "fmt"
   "reflect"
   "unsafe"
)

func main() {
   var i int
   i = 10
   println("&i", &i)
   b := []int{1, 2, 3, 4, 5}
   println("&b", &b) // b这个对象的地址
   println("b", unsafe.Pointer((*reflect.SliceHeader)(unsafe.Pointer(&b)).Data)) // b的底层数组地址
   fmt.Println(&b) // 修改这行
}

如上，将fmt.Println(b)改为fmt.Println(&b)，逃逸分析如下：

$ go build -gcflags="-m -m -l" ./main.go
# command-line-arguments
./main.go:13:2: b escapes to heap:
./main.go:13:2:   flow: {storage for ... argument} = &b:
./main.go:13:2:     from &b (address-of) at ./main.go:16:14
./main.go:13:2:     from &b (interface-converted) at ./main.go:16:14
./main.go:13:2:     from ... argument (slice-literal-element) at ./main.go:16:13
./main.go:13:2:   flow: {heap} = {storage for ... argument}:
./main.go:13:2:     from ... argument (spill) at ./main.go:16:13
./main.go:13:2:     from fmt.Println(... argument...) (call parameter) at ./main.go:16:13
./main.go:13:12: []int{...} escapes to heap:
./main.go:13:12:   flow: b = &{storage for []int{...}}:
./main.go:13:12:     from []int{...} (spill) at ./main.go:13:12
./main.go:13:12:     from b := []int{...} (assign) at ./main.go:13:4
./main.go:13:2: moved to heap: b
./main.go:13:12: []int{...} escapes to heap
./main.go:16:13: ... argument does not escape
note: module requires Go 1.18

发现多了moved to heap: b这行，然后看地址打印：

$ go run main.go
&i 0xc00006af48
&b 0xc00000c030
b 0xc00001a150
&[1 2 3 4 5]

发现不仅底层数组发生了逃逸，连b这个对象本身也发生了逃逸。

所以可以总结下来就是：

• escapes to heap：表示这个对象里面的指针对象逃逸到堆中；
• moved to heap：表示对象本身逃逸到堆中，根据指向栈对象的指针不能存在于堆中这一准则，该对象里面的指针对象特必然逃逸到堆中。

1.3 申请栈空间过大

package main

import (
   "reflect"
   "unsafe"
)

func main() {
   var i int
   i = 10
   println("&i", &i)

   b := make([]int, 0)
   println("&b", &b) // b这个对象的地址
   println("b", unsafe.Pointer((*reflect.SliceHeader)(unsafe.Pointer(&b)).Data))

   b1 := make([]byte, 65536)
   println("&b1", &b1) // b1这个对象的地址
   println("b1", unsafe.Pointer((*reflect.SliceHeader)(unsafe.Pointer(&b1)).Data))

   var a [1024*1024*10]byte
   _ = a
}

可以发现逃逸分析显示没有发生逃逸：

$ go build -gcflags="-m -m -l" ./main.go
# command-line-arguments
./main.go:13:11: make([]int, 0) does not escape
./main.go:17:12: make([]byte, 65536) does not escape
note: module requires Go 1.18

如果将切片和数组的长度都增加1，则会发生逃逸。
逃逸分析：

$ go build -gcflags="-m -m -l" ./main.go
# command-line-arguments
./main.go:21:6: a escapes to heap:
./main.go:21:6:   flow: {heap} = &a:
./main.go:21:6:     from a (too large for stack) at ./main.go:21:6
./main.go:17:12: make([]byte, 65537) escapes to heap:
./main.go:17:12:   flow: {heap} = &{storage for make([]byte, 65537)}:
./main.go:17:12:     from make([]byte, 65537) (too large for stack) at ./main.go:17:12
./main.go:21:6: moved to heap: a
./main.go:13:11: make([]int, 0) does not escape
./main.go:17:12: make([]byte, 65537) escapes to heap
note: module requires Go 1.18

可以发现切片类型的逃逸阈值是65536 = 64KB，数组类型的逃逸阈值是1024*1024*10 = 10MB，超过这个数值就会发生逃逸。

1.4 闭包逃逸

package main

func intSeq() func() int {
   i := 0
   return func() int {
      i++
      return i
   }
}

func main() {
    a := intSeq()
    println(a())
    println(a())
    println(a())
    println(a())
    println(a())
    println(a())
}

逃逸分析如下，可以发现闭包中的局部变量i发生了逃逸。

$ go build -gcflags="-m -m -l" ./main.go
# command-line-arguments
./main.go:4:2: intSeq capturing by ref: i (addr=false assign=true width=8)
./main.go:5:9: func literal escapes to heap:
./main.go:5:9:   flow: ~r0 = &{storage for func literal}:
./main.go:5:9:     from func literal (spill) at ./main.go:5:9
./main.go:5:9:     from return func literal (return) at ./main.go:5:2
./main.go:4:2: i escapes to heap:
./main.go:4:2:   flow: {storage for func literal} = &i:
./main.go:4:2:     from i (captured by a closure) at ./main.go:6:3
./main.go:4:2:     from i (reference) at ./main.go:6:3
./main.go:4:2: moved to heap: i
./main.go:5:9: func literal escapes to heap
note: module requires Go 1.18

因为函数也是一个指针类型，所以匿名函数当作返回值时也发生了逃逸，在匿名函数中使用外部变量i，这个变量i会一直存在直到a被销毁，所以i变量逃逸到了堆上。

2. 总结

逃逸到堆上的内存可能会加大GC压力，所以在一些简单的场景下，我们可以避免内存逃逸，使得变量更多地分配在栈上，可以提升程序的性能。比如：

• 不要盲目地使用指针传参，特别是参数对象很小时，虽然可以减小复制大小，但是可能会造成内存逃逸到堆上，反而降低了代码的效率；
• 多根据代码具体分析，根据逃逸分析结果做一些优化，提高性能。

1. Go内存分配设计原理

Go内存分配器的设计思想来源于TCMalloc，全称是Thread-Caching Malloc，核心思想是把内存分为多级管理，利用缓存的思想提升内存使用效率，降低锁的粒度。

图片来自链接，侵删！

如上图所示，是Go的内存管理模型示意图，在堆内存管理上分为三个内存级别：

• 线程缓存（MCache）：作为线程独立的内存池，与线程的第一交互内存，访问无需加锁；
• 中心缓存（MCentral）：作为线程缓存的下一级，是多个线程共享的，所以访问时需要加锁；
• 页堆（MHeap）：中心缓存的下一级，在遇到32KB以上的对象时，会直接选择页堆分配大内存，而当页堆内存不够时，则会通过系统调用向系统申请内存。

1.1 内存管理基本单元mspan

//go:notinheap
type mspan struct {
   next *mspan     // next span in list, or nil if none
   prev *mspan     // previous span in list, or nil if none
   list *mSpanList // For debugging. TODO: Remove.

   startAddr uintptr // address of first byte of span aka s.base()
   npages    uintptr // number of pages in span
   
   
   freeindex uintptr

   allocBits  *gcBits
   gcmarkBits *gcBits
   allocCache uint64
   ...
}

runtime.mspan是Go内存管理的基本单元，其结构体中包含的next和prev指针，分别指向前后的runtime.mspan，所以其串联后的结构是一个双向链表。

而startAddr表示此mspan的起始地址，npages表示管理的页数，每页大小8KB，这个页不是操作系统的内存页，一般是操作系统内存页的整数倍。

其它字段：

• freeindex — 扫描页中空闲对象的初始索引；
• allocBits 和 gcmarkBits — 分别用于标记内存的占用和回收情况；
• allocCache — allocBits 的补码，可以用于快速查找内存中未被使用的内存；

注意使用//go:notinheap标记次结构体mspan为非堆上类型，保证此类型对象不会逃逸到堆上。

图示：

跨度类

在mspan中有一个字段spanclass，称为跨度类，是对mspan大小级别的划分，每个mspan能够存放指定范围大小的对象，32KB以内的小对象在Go中，会对应不同大小的内存刻度Size Class，Size Class和Object Size是一一对应的，前者指序号 0、1、2、3，后者指具体对象大小 0B、8B、16B、24B

//go:notinheap
type mspan struct {
   ...
   spanclass   spanClass     // size class and noscan (uint8)
   ...
}

Go 语言的内存管理模块中一共包含 67 种跨度类，每一个跨度类都会存储特定大小的对象并且包含特定数量的页数以及对象，所有的数据都会被预先计算好并存储在runtime.class_to_size和runtime.class_to_allocnpages等变量中：

上表展示了对象大小从 8B 到 32KB，总共 67 种跨度类的大小、存储的对象数以及浪费的内存空间，以表中的第四个跨度类为例，跨度类为 5 的runtime.mspan中对象的大小上限为 48 字节、管理 1 个页、最多可以存储 170 个对象。因为内存需要按照页进行管理，所以在尾部会浪费 32 字节的内存，当页中存储的对象都是 33 字节时，最多会浪费 31.52% 的资源：

((48−33)∗170+32)/8192=0.31518((48−33)∗170+32)/8192=0.31518((48−33)∗170+32)/8192=0.31518

除了上述 67 个跨度类之外，运行时中还包含 ID 为 0 的特殊跨度类，它能够管理大于 32KB 的特殊对象。

1.2 线程缓存（mcache）

runtime.mcache是Go语言中的线程缓存，它会与线程上的处理器1:1绑定，用于缓存用户程序申请的微小对象。每一个线程缓存都持有numSpanClasses个（68∗268*268∗2）个mspan，存储在mcache的alloc字段中。

其图示如下：

图片来源于链接，侵删！

1.3 中心缓存（mcentral）

每个中心缓存都会管理某个跨度类的内存管理单元，它会同时持有两个runtime.spanSet，分别存储包含空闲对象和不包含空闲对象的内存管理单元，访问中心缓存中的内存管理单元需要使用互斥锁。

//go:notinheap
type mcentral struct {
   spanclass spanClass
   partial [2]spanSet // list of spans with a free object
   full    [2]spanSet // list of spans with no free objects
}

如图上所示，是 runtime.mcentral 中的 spanSet 的内存结构，index 字段是一个uint64类型数字的地址，该uint64的数字按32位分为前后两半部分head和tail，向spanSet中插入和获取mspan有其提供的push和pop函数，以push函数为例，会根据index的head，对spanSetBlock数据块包含的mspan的个数512取商，得到spanSetBlock数据块所在的地址，然后head对512取余，得到要插入的mspan在该spanSetBlock数据块的具体地址。之所以是512，因为spanSet指向的spanSetBlock数据块是一个包含512个mspan的集合。

由全部spanClass规格的runtime.mcentral共同组成的缓存结构如下：

1.4 页堆（mheap）

//go:notinheap
type mheap struct {
   ...
   arenas [1 << arenaL1Bits]*[1 << arenaL2Bits]*heapArena
   ...
   central [numSpanClasses]struct {
      mcentral mcentral
      pad      [cpu.CacheLinePadSize - unsafe.Sizeof(mcentral{})%cpu.CacheLinePadSize]byte
   }
   ...
}

runtime.mheap是内存分配的核心结构体，其最重要的两个字段如上。

在Go中其被作为全局变量mheap_存储：

var mheap_ mheap

页堆中包含一个长度为numSpanClasses个（68∗268*268∗2）个的runtime.mcentral数组，其中 68 个为跨度类需要 scan 的中心缓存，另外的 68 个是 noscan （没有指针，无需扫描）的中心缓存。

arenas是heapArena的二维数组的集合。如下：

2. 内存分配/释放流程

堆上所有的对象内存分配都会通过runtime.newobject进行分配，运行时根据对象大小将它们分为微对象、小对象和大对象：

• 微对象（0, 16B）：先使用微型分配器，再依次尝试线程缓存、中心缓存和堆分配内存；多个小于16B的无指针微对象的内存分配请求，会合并向Tiny微对象空间申请，微对象的 16B 内存空间从 spanClass 为 4 或 5（无GC扫描）的mspan中获取。
• 小对象[16B, 32KB]：先向mcache申请，mcache内存空间不够时，向mcentral申请，mcentral不够，则向页堆mheap申请，再不够就向操作系统申请。
• 大对象(32KB, +∞)：大对象直接向页堆mheap申请。

对于内存的释放，遵循逐级释放的策略。当ThreadCache的缓存充足或者过多时，则会将内存退还给CentralCache。当CentralCache内存过多或者充足，则将低命中内存块退还PageHeap。

1. 系统栈和Go栈

1.1 系统线程栈

如果我们在Linux中执行 pthread_create 系统调用，进程会启动一个新的线程，这个栈大小一般为系统的默认栈大小。

对于栈上的内存，程序员无法直接操作，由系统统一管理，一般的函数参数、局部变量（C语言）会存储在栈上。

1.2 Go栈

Go语言在用户空间实现了一套runtime的管理系统，其中就包括了对内存的管理，Go的内存也区分堆和栈，但是需要注意的是，Go栈内存其实是从系统堆中分配的内存，因为同样运行在用户态，Go的运行时也没有权限去直接操纵系统栈。

Go语言使用用户态协程goroutine作为执行的上下文，其使用的默认栈大小比线程栈高的多，其栈空间和栈结构也在早期几个版本中发生过一些变化：

1. v1.0 ~ v1.1 — 最小栈内存空间为 4KB；
2. v1.2 — 将最小栈内存提升到了 8KB；
3. v1.3 — 使用连续栈替换之前版本的分段栈；
4. v1.4 — 将最小栈内存降低到了 2KB；

2. 栈操作

在前面的《Golang调度器》系列我们也讲过，Go语言中的执行栈由runtime.stack，该结构体中只包含两段字段，分别表示栈的顶部和底部，每个栈结构体都在[lo, hi)的范围内：

type stack struct {
	lo uintptr
	hi uintptr
}

栈的结构虽然非常简单，但是想要理解 Goroutine 栈的实现原理，还是需要我们从编译期间和运行时两个阶段入手：

1. 为了防止栈空间不足，编译器会在编译阶段会通过cmd/internal/obj/x86.stacksplit在调用函数前插入runtime.morestack或者runtime.morestack_noctxt函数；
2. 运行时创建新的 Goroutine 时会在runtime.malg中调用runtime.stackalloc申请新的栈内存，并在编译器插入的runtime.morestack中检查栈空间是否充足；

当然，可以在函数头加上//go:nosplit跳过栈溢出检查。

2.1 栈初始化

栈空间运行时中包含两个重要的全局变量，分别是stackpool和stackLarge，这两个变量分别表示全局的栈缓存和大栈缓存，前者可以分配小于 32KB 的内存，后者用来分配大于 32KB 的栈空间：

var stackpool [_NumStackOrders]struct {
   item stackpoolItem
   _    [cpu.CacheLinePadSize - unsafe.Sizeof(stackpoolItem{})%cpu.CacheLinePadSize]byte
}

//go:notinheap
type stackpoolItem struct {
   mu   mutex
   span mSpanList
}

// Global pool of large stack spans.
var stackLarge struct {
   lock mutex
   free [heapAddrBits - pageShift]mSpanList // free lists by log_2(s.npages)
}

2.2 栈分配

我们在这里会按照栈的大小分两部分介绍运行时对栈空间的分配。在 Linux 上，_FixedStack = 2048、_NumStackOrders = 4、_StackCacheSize = 32768，也就是如果申请的栈空间小于 32KB，我们会在全局栈缓存池或者线程的栈缓存中初始化内存：

如果申请的内存空间过大，运行时会查看runtime.stackLarge中是否有剩余的空间，如果不存在剩余空间，它会从堆上申请新的内存。

2.3 栈扩容

在之前我们就提过，编译器会在cmd/internal/obj/x86.stacksplit中为函数调用插入runtime.morestack运行时检查，它会在几乎所有的函数调用之前检查当前 Goroutine 的栈内存是否充足，如果当前栈需要扩容，我们会保存一些栈的相关信息并调用runtime.newstack创建新的栈。

在此期间可能触发抢占。

接下来就是分配新的栈内存和栈拷贝，这里就不详细描述了。

2.4 栈缩容

runtime.shrinkstack栈缩容时调用的函数，该函数的实现原理非常简单，其中大部分都是检查是否满足缩容前置条件的代码，核心逻辑只有以下这几行：

func shrinkstack(gp *g) {
	...
	oldsize := gp.stack.hi - gp.stack.lo
	newsize := oldsize / 2
	if newsize < _FixedStack {
		return
	}
	avail := gp.stack.hi - gp.stack.lo
	if used := gp.stack.hi - gp.sched.sp + _StackLimit; used >= avail/4 {
		return
	}

	copystack(gp, newsize)
}

如果要触发栈的缩容，新栈的大小会是原始栈的一半，不过如果新栈的大小低于程序的最低限制2KB，那么缩容的过程就会停止。

运行时只会在栈内存使用不足1/4时进行缩容，缩容也会调用扩容时使用的runtime.copystack开辟新的栈空间。