本文永久链接 – https://tonybai.com/2021/05/24/understand-go-escape-analysis-by-example

翻看了一下自己的Go文章归档，发现自己从未专门写过有关Go逃逸分析（escape analysis）的文章。关于Go变量的逃逸分析，大多数Gopher其实并不用关心，甚至可以无视。但是如果你将Go应用于性能敏感的领域，要完全压榨出Go应用的性能，那么理解Go逃逸分析就大有裨益了。在本文，我们就一起来理解一下Go的逃逸分析。

1. 逃逸分析（escape analysis）要解决的问题

C/C++语言出身的程序员对堆内存（heap）和栈内存（stack）都有着“泾渭分明”的理解。在操作系统演化出现进程虚拟内存地址（virtual memory address）的概念后，如下图所示，应用程序的虚拟内存地址空间就被划分为堆内存区（如图中的heap）和栈内存区（如图中的stack）：

在x86平台linux操作系统下，如上图，一般将栈内存区放在高地址，栈向下延伸；而堆内存去放在低地址，堆向上延伸，这样做的好处就是便于堆和栈可动态共享那段内存区域。

这是否意味着所有分配在堆内存区域的内存对象地址一定比分配在栈内存区域的内存对象地址要小呢？在C/C++中是这样的，但是在Go语言中，这是不一定的，因为go堆内存所使用的内存页(page)与goroutine的栈所使用的内存页是交织在一起的。

无论是栈内存还是堆内存，对于应用而言都是合法可用的内存地址空间。之所以将其区分开，是因为应用程序的内存分配和管理的需要。

栈内存上的对象的存储空间是自动分配和销毁的，无需开发人员或编程语言运行时过多参与，比如下面的这段C代码（用C代码更能体现栈内存与堆内存的差别）：

// github.com/bigwhite/experiments/blob/master/go-escape-analysis/c/cstack.c

#include <stdio.h>

void bar() {
    int e = 31;
    int f = 32;
    printf("e = %d\n", e);
    printf("f = %d\n", f);
}

void foo() {
    int c = 21;
    int d = 22;
    printf("c = %d\n", c);
    printf("d = %d\n", d);
}

int main() {
    int a = 11;
    int b = 12;
    printf("a = %d\n", a);
    printf("b = %d\n", b);
    foo();
    bar();
}

上面这段c程序算上main函数共有三个函数，每个函数中都有两个整型变量，C编译器自动为这些变量在栈内存上分配空间，我们无需考虑它什么时候被创建以及何时被销毁，我们只需在特定的作用域（其所在函数内部）使用它即可，而无需担心其内存地址不合法，因此这些被分配在栈内存上的变量也被称为“自动变量”。但是如果将其地址返回到函数的外部，那么函数外部的代码通过解引用而访问这些变量时便会出错，如下面示例：

// github.com/bigwhite/experiments/blob/master/go-escape-analysis/c/cstack_coredump.c

#include <stdio.h>

int *foo() {
    int c = 11;
    return &c;
}

int main() {
    int *p = foo();
    printf("the return value of foo = %d\n", *p);
}

如代码所示，在上面这个例子中，我们将foo函数内的自动变量c的地址通过函数返回值返回给foo函数的调用者（main）了，这样当我们在main函数中引用该地址输出该变量值的时候，我们就会收到异常，比如在ubuntu上运行上述程序，我们会得到如下结果（在macos上运行，gcc会给出相同的警告，但程序运行不会dump core）：

# gcc cstack_dumpcore.c
cstack_dumpcore.c: In function ‘foo’:
cstack_dumpcore.c:5:12: warning: function returns address of local variable [-Wreturn-local-addr]
     return &c;
            ^~
# ./a.out
Segmentation fault (core dumped)

这样一来我们就需要一种内存对象，可以在全局（跨函数间）合法使用，这就是堆内存对象。但是和位于栈上的内存对象由程序自行创建销毁不同，堆内存对象需要通过专用API手工分配和释放，在C中对应的分配和释放方法就是malloc和free：

// github.com/bigwhite/experiments/blob/master/go-escape-analysis/c/cheap.c

#include <stdio.h>
#include <stdlib.h>

int *foo() {
    int *c = malloc(sizeof(int));
    *c = 12;
    return c;
}

int main() {
    int *p = foo();
    printf("the return value of foo = %d\n", *p);
    free(p);
}

在这个示例中我们使用malloc在foo函数中分配了一个堆内存对象，并将该对象返回给main函数，main函数使用完该对象后调用了free函数手工释放了该堆内存块。

显然和自动变量相比，堆内存对象的生命周期管理将会给开发人员带来很大的心智负担。为了降低这方面的心智负担，带有GC（垃圾回收）的编程语言出现了，比如Java、Go等。这些带有GC的编程语言会对位于堆上的对象进行自动管理。当某个对象不可达时（即没有其对象引用它时），它将会被回收并被重用。

但GC的出现虽然降低了开发人员在内存管理方面的心智负担，但GC不是免费的，它给程序带来的性能损耗是不可忽视的，尤其是当堆内存上有大量待扫描的堆内存对象时，将会给GC带来过大的压力，从而使得GC占用更多本应用于处理业务逻辑的计算和存储资源。于是人们开始想方法尽量减少在堆上的内存分配，可以在栈上分配的变量尽量留在栈上。

逃逸分析（escape analysis）就是在程序编译阶段根据程序代码中的数据流，对代码中哪些变量需要在栈上分配，哪些变量需要在堆上分配进行静态分析的方法。一个理想的逃逸分析算法自然是能将那些人们认为需要分配在栈上的变量尽可能保留在栈上，尽可能少的“逃逸”到堆上的算法。但这太过理想，各种语言都有自己的特殊情况，各种语言的逃逸算法的精确度实际都会受到这方面的影响。

2. Go语言的逃逸分析

Go从诞生那天起，逃逸分析就始终伴随其左右。正如上面说到的逃逸分析的目标，Go编译器使用逃逸分析来决定哪些变量应该在goroutine的栈上分配，哪些变量应该在堆上分配。

截至目前，Go一共有两个版本的逃逸分析实现，分水岭在Go 1.13版本。Go 1.13版本之前是Go逃逸分析的第一版实现，位于Go源码的src/cmd/compile/internal/gc/esc.go中（以go 1.12.7版本为例），代码规模2400多行；Go 1.13版本中加入了由Matthew Dempsky重写的第二版逃逸分析，并默认开启，可以通过-gcflags=”-m -newescape=false”恢复到使用第一版逃逸分析。之所以重写，主要是考虑第一版代码的可读性和可维护性问题，新版代码主要位于Go项目源码的src/cmd/compile/internal/gc/escape.go中，它将逃逸分析代码从上一版的2400多行缩减为1600多行，并作了更为完整文档和注释。但注意的是新版代码在算法精确性上并没有质的变化。

但即便如此，经过了这么多年的“修修补补”，Dmitry Vyukov 2015年提出的那些“Go Escape Analysis Flaws”多数已经fix了。Go项目中内置了对逃逸分析的详尽的测试代码（位于Go项目下的test/escape*.go文件中）。

在新版逃逸分析实现的注释中（$GOROOT/src/cmd/compile/internal/gc/escape.go），我们可以大致了解逃逸分析的实现原理。注释中的原理说明中提到了算法基于的两个不变性：

1. 指向栈对象的指针不能存储在堆中（pointers to stack objects cannot be stored in the heap）；
2. 指向栈对象的指针不能超过该栈对象的存活期（即指针不能在栈对象被销毁后依旧存活）（pointers to a stack object cannot outlive that object）。

源码注释中也给出Go逃逸分析的大致原理和过程。Go逃逸分析的输入是Go编译器解析了Go源文件后所获得的整个程序的抽象语法树（Abstract syntax tree，AST）：

源码解析后得到的代码AST的Node切片为xtop：

// $GOROOT/src/cmd/compile/internal/gc/go.go
var xtop []*Node

在Main函数中，xtop被传入逃逸分析的入口函数escapes：

// $GOROOT/src/cmd/compile/internal/gc/main.go

// Main parses flags and Go source files specified in the command-line
// arguments, type-checks the parsed Go package, compiles functions to machine
// code, and finally writes the compiled package definition to disk.
func Main(archInit func(*Arch)) {
    ... ...
    // Phase 6: Escape analysis.
    // Required for moving heap allocations onto stack,
    // which in turn is required by the closure implementation,
    // which stores the addresses of stack variables into the closure.
    // If the closure does not escape, it needs to be on the stack
    // or else the stack copier will not update it.
    // Large values are also moved off stack in escape analysis;
    // because large values may contain pointers, it must happen early.
    timings.Start("fe", "escapes")
    escapes(xtop)
    ... ...
}

下面是escapes函数的实现：

// $GOROOT/src/cmd/compile/internal/gc/esc.go
func escapes(all []*Node) {
    visitBottomUp(all, escapeFuncs)
}

// $GOROOT/src/cmd/compile/internal/gc/scc.go
// 强连接node - 一个数据结构
func visitBottomUp(list []*Node, analyze func(list []*Node, recursive bool)) {
    var v bottomUpVisitor
    v.analyze = analyze
    v.nodeID = make(map[*Node]uint32)
    for _, n := range list {
        if n.Op == ODCLFUNC && !n.Func.IsHiddenClosure() {
            v.visit(n)
        }
    }
}

// $GOROOT/src/cmd/compile/internal/gc/escape.go

// escapeFuncs performs escape analysis on a minimal batch of
// functions.
func escapeFuncs(fns []*Node, recursive bool) {
    for _, fn := range fns {
        if fn.Op != ODCLFUNC {
            Fatalf("unexpected node: %v", fn)
        }
    }

    var e Escape
    e.heapLoc.escapes = true

    // Construct data-flow graph from syntax trees.
    for _, fn := range fns {
        e.initFunc(fn)
    }
    for _, fn := range fns {
        e.walkFunc(fn)
    }
    e.curfn = nil

    e.walkAll()
    e.finish(fns)
}

根据注释，escapes的大致原理是(直译)：

• 首先，构建一个有向加权图，其中顶点(称为”location”，由gc.EscLocation表示)代表由语句和表达式分配的变量，而边(gc.EscEdge)代表变量之间的赋值(权重代表寻址/取地址次数)。
• 接下来，遍历(visitBottomUp)该有向加权图，在图中寻找可能违反上述两个不变量条件的赋值路径。 违反上述不变量的赋值路径。如果一个变量v的地址是储存在堆或其他可能会超过它的存活期的地方，那么v就会被标记为需要在堆上分配。
• 为了支持函数间的分析，算法还记录了从每个函数的参数到堆的数据流以及到其结果的数据流。算法将这些信息称为“参数标签(parameter tag)”。这些标签信息在静态调用时使用，以改善对函数参数的逃逸分析。

当然即便看到这，你可能依旧一头雾水，没关系，这里不是讲解逃逸分析原理，如果想了解原理，那就请认真阅读那2400多行代码。

注：有一点需要明确，那就是静态逃逸分析也无法确定的对象会被放置在堆上，后续精确的GC会处理这些对象，这样最大程度保证了代码的安全性。

3. Go逃逸分析的示例

Go工具链提供了查看逃逸分析过程的方法，我们可以通过在-gcflags中使用-m来让Go编译器输出逃逸分析的过程，下面是一些典型的示例。

1) 简单原生类型变量的逃逸分析

我们来看一个原生整型变量的逃逸分析过程，下面是示例的代码：

// github.com/bigwhite/experiments/blob/master/go-escape-analysis/go/int.go
     1  package main
     2
     3  import "testing"
     4
     5  func foo() {
     6      a := 11
     7      p := new(int)
     8      *p = 12
     9      println("addr of a is", &a)
    10      println("addr that p point to is", p)
    11  }
    12
    13  func bar() (*int, *int) {
    14      m := 21
    15      n := 22
    16      println("addr of m is", &m)
    17      println("addr of n is", &n)
    18      return &m, &n
    19  }
    20
    21  func main() {
    22      println(int(testing.AllocsPerRun(1, foo)))
    23      println(int(testing.AllocsPerRun(1, func() {
    24          bar()
    25      })))
    26  }

我们通过-gcflags “-m -l”来执行逃逸分析，之所以传入-l是为了关闭inline，屏蔽掉inline对这个过程以及最终代码生成的影响：

// go 1.16版本 on MacOS
$go build -gcflags "-m -l" int.go
# command-line-arguments
./int.go:7:10: new(int) does not escape
./int.go:14:2: moved to heap: m
./int.go:15:2: moved to heap: n
./int.go:23:38: func literal does not escape

逃逸分析的结果与我们手工分析的一致：函数bar中的m、n逃逸到heap(对应上面输出的有moved to heap: xx字样的行)，这两个变量将在heap上被分配存储空间。而函数foo中的a以及指针p指向的内存块都在栈上分配（即便我们是调用的new创建的int对象，Go中new出来的对象可不一定分配在堆上，逃逸分析的输出日志中还专门提及new(int)没有逃逸）。我们执行一下该示例（执行时同样传入-l关闭inline）：

$go run -gcflags "-l" int.go
addr of a is 0xc000074860
addr that p point to is 0xc000074868
addr of a is 0xc000074860
addr that p point to is 0xc000074868
0
addr of m is 0xc0000160e0
addr of n is 0xc0000160e8
addr of m is 0xc0000160f0
addr of n is 0xc0000160f8
2

首先，我们看到未逃逸的a和p指向的内存块的地址区域在0xc000074860~0xc000074868；而逃逸的m和n被分配到了堆内存空间，从输出的结果来看在0xc0000160e0~0xc0000160e8。我们可以明显看到这是两块不同的内存地址空间；另外通过testing包的AllocsPerRun的输出，我们同样印证了函数bar中执行了两次堆内存分配动作。

我们再来看看这个代码对应的汇编代码：

$go tool compile -S int.go |grep new
    0x002c 00044 (int.go:14)    CALL    runtime.newobject(SB)
    0x004d 00077 (int.go:15)    CALL    runtime.newobject(SB)
    rel 45+4 t=8 runtime.newobject+0
    rel 78+4 t=8 runtime.newobject+0

我们看到在对应源码的14和15行，汇编调用了runtime.newobject在堆上执行了内存分配动作，这恰是逃逸的m和n声明的位置。从下面newobject代码的实现我们也能看到，它实际上在gc管理的内存上执行了malloc动作：

// $GOROOT/src/runtime/malloc.go

// implementation of new builtin
// compiler (both frontend and SSA backend) knows the signature
// of this function
func newobject(typ *_type) unsafe.Pointer {
    return mallocgc(typ.size, typ, true)
}

2) 切片变量自身和切片元素的逃逸分析

了解过切片实现原理的gopher都知道，切片变量实质上是一个三元组：

//$GOROOT/src/runtime/slice.go

type slice struct {
    array unsafe.Pointer
    len   int
    cap   int
}

其中这个三元组的第一个字段array指向的是切片底层真正存储元素的指针。这样当为一个切片变量分配内存时，便既要考虑切片本身(即上面的slice结构体)在哪里分配，也要考虑切片元素的存储在哪里分配。我们看下面示例：

// github.com/bigwhite/experiments/blob/master/go-escape-analysis/go/slice.go

     1  package main
     2
     3  import (
     4      "reflect"
     5      "unsafe"
     6  )
     7
     8  func noEscapeSliceWithDataInHeap() {
     9      var sl []int
    10      println("addr of local(noescape, data in heap) slice = ", &sl)
    11      printSliceHeader(&sl)
    12      sl = append(sl, 1)
    13      println("append 1")
    14      printSliceHeader(&sl)
    15      println("append 2")
    16      sl = append(sl, 2)
    17      printSliceHeader(&sl)
    18      println("append 3")
    19      sl = append(sl, 3)
    20      printSliceHeader(&sl)
    21      println("append 4")
    22      sl = append(sl, 4)
    23      printSliceHeader(&sl)
    24  }
    25
    26  func noEscapeSliceWithDataInStack() {
    27      var sl = make([]int, 0,      28      println("addr of local(noescape, data in stack) slice = ", &sl)
    29      printSliceHeader(&sl)
    30      sl = append(sl, 1)
    31      println("append 1")
    32      printSliceHeader(&sl)
    33      sl = append(sl, 2)
    34      println("append 2")
    35      printSliceHeader(&sl)
    36  }
    37
    38  func escapeSlice() *[]int {
    39      var sl = make([]int, 0,      40      println("addr of local(escape) slice = ", &sl)
    41      printSliceHeader(&sl)
    42      sl = append(sl, 1)
    43      println("append 1")
    44      printSliceHeader(&sl)
    45      sl = append(sl, 2)
    46      println("append 2")
    47      printSliceHeader(&sl)
    48      return &sl
    49  }
    50
    51  func printSliceHeader(p *[]int) {
    52      ph := (*reflect.SliceHeader)(unsafe.Pointer(p))
    53      println("slice data =", unsafe.Pointer(ph.Data))
    54  }
    55
    56  func main() {
    57      noEscapeSliceWithDataInHeap()
    58      noEscapeSliceWithDataInStack()
    59      escapeSlice()
    60  }

对上述示例运行逃逸分析：

$go build -gcflags "-m -l" slice.go
# command-line-arguments
./slice.go:51:23: p does not escape
./slice.go:27:15: make([]int, 0,  does not escape
./slice.go:39:6: moved to heap: sl
./slice.go:39:15: make([]int, 0,  escapes to heap

我们从输出的信息中看到：

• 位于39行的escapeSlice函数中的sl逃逸到堆上了；
• 位于39行的escapeSlice函数中的切片sl的元素也逃逸到堆上了；
• 位于27行的切片sl的元素没有逃逸。

由于很难看到三个函数中各个切片的元素是否逃逸，我们通过运行该示例来看一下：

$go run -gcflags " -l" slice.go
addr of local(noescape, data in heap) slice =  0xc00006af48
slice data = 0x0
append 1
slice data = 0xc0000160c0
append 2
slice data = 0xc0000160d0
append 3
slice data = 0xc0000140c0
append 4
slice data = 0xc0000140c0

addr of local(noescape, data in stack) slice =  0xc00006af48
slice data = 0xc00006af08
append 1
slice data = 0xc00006af08
append 2
slice data = 0xc00006af08

addr of local(escape) slice =  0xc00000c030
slice data = 0xc00001a100
append 1
slice data = 0xc00001a100
append 2
slice data = 0xc00001a100

注：我们利用reflect包的SliceHeader输出切片三元组中的代表底层数组地址的字段，这里是slice data。

我们看到：

• 第一个函数noEscapeWithDataInHeap声明了一个空slice，并在后面使用append向切片附加元素。从输出结果来看，slice自身是分配在栈上的，但是运行时在动态扩展切片时，选择了将其元素存储在heap上；
• 第二个函数noEscapeWithDataInStack直接初始化了一个包含8个元素存储空间的切片，切片自身没有逃逸，并且在附加(append)的元素个数小于等于8个的时候，元素直接使用了为其分配的栈空间；但如果附加的元素超过8个，那么运行时会在堆上分配一个更大的空间并将原栈上的8个元素复制过去，后续该切片的元素就都存储在了堆上。这也是为什么强烈建议在创建 slice 时带上预估的cap参数的原因，不仅减少了堆内存的频繁分配，在切片变量未逃逸的情况下，在cap容量之下，所有元素都分配在栈上，这将提升运行性能。
• 第三个函数escapeSlice则是切片变量自身以及其元素的存储都在堆上。

3) fmt.Printf系列函数让变量逃逸到堆(heap)上了？

很多人在go项目的issue中反馈fmt.Printf系列函数让变量逃逸到堆上了，情况真的是这样么？我们通过下面示例来看一下：

// github.com/bigwhite/experiments/blob/master/go-escape-analysis/go/printf1.go
     1  package main
     2
     3  import "fmt"
     4
     5  func foo() {
     6      var a int = 66666666
     7      var b int = 77
     8      fmt.Printf("a = %d\n", a)
     9      println("addr of a in foo =", &a)
    10      println("addr of b in foo =", &b)
    11  }
    12
    13  func main() {
    14      foo()
    15  }

注：println和print两个预定义函数并没有像fmt.Printf系列函数的“副作用”，不会影响变量的逃逸性。所以这里使用println来输出变量的实际分配内存地址。

对上面的代码运行逃逸分析：

$go build -gcflags "-m -l" printf1.go
# command-line-arguments
./printf1.go:8:12: ... argument does not escape
./printf1.go:8:13: a escapes to heap

我们看到逃逸分析输出第8行的变量“a escapes to heap”，不过这个“逃逸”有些奇怪，因为按照之前的经验，如果某个变量真实逃逸了，那么逃逸分析会在其声明的那行输出：“moved to heap: xx”字样。而上面这个输出既不是在变量声明的那一行，也没有输出“moved to heap: a”字样，变量a真的逃逸了么？我们运行一下上面示例，看看变量a的地址究竟是在堆上还是栈上：

$go run -gcflags "-l" printf1.go
a = 66666666
addr of a in foo = 0xc000092f50
addr of b in foo = 0xc000092f48

我们看到变量a的地址与未逃逸的变量b的地址都在同一个栈空间，变量a并未逃逸！如果你反编译为汇编，你肯定也看不到runtime.newobject的调用。

那么“./printf1.go:8:13: a escapes to heap”这句的含义究竟是什么呢？显然逃逸分析在这一行是对进入fmt.Printf的数据流的分析，我们修改一下go标准库源码，然后build -a重新编译一下printf1.go，看看在fmt.Printf内部变量的分布情况：

// $GOROOT/src/fmt/print.go

func Printf(format string, a ...interface{}) (n int, err error) {
    // 添加下面四行代码
    for i := 0; i < len(a); i++ {
        println(a[i])
        println(&a[i])
    }
    return Fprintf(os.Stdout, format, a...)
}

重新编译printf1.go并运行编译后的可执行文件(为了避免)：

$go build -a -gcflags "-l" printf1.go
$./printf1
(0x10af200,0xc0000160c8)
0xc00006cf58
a = 66666666
addr of a in foo = 0xc00006cf50
addr of b in foo = 0xc00006cf48

我们看到fmt.Printf的实参a在传入后被装箱到一个interface{}类型的形参变量中，而这个形参变量自身则是被分配在栈上的（0xc00006cf58），而通过println输出的该interface{}类型形参变量的类型部分和值部分分别指向0x10af200和0xc0000160c8。显然值部分是在堆内存上分配的。那么“./printf1.go:8:13: a escapes to heap”是否指的是装箱后的值部分在堆上分配呢？这里也不确定。

我们再来看一个例子来对比一下：

// github.com/bigwhite/experiments/blob/master/go-escape-analysis/go/printf2.go
     1  package main
     2
     3  import "fmt"
     4
     5  func foo() {
     6      var a int = 66666666
     7      var b int = 77
     8      fmt.Printf("addr of a in bar = %p\n", &a)
     9      println("addr of a in bar =", &a)
    10      println("addr of b in bar =", &b)
    11  }
    12
    13  func main() {
    14      foo()
    15  }

在printf2.go这个例子中，与printf1.go不同的是我们在foo函数中使用fmt.Printf输出的是变量a的地址：&a。我们运行一下新版逃逸分析：

// go 1.16

$go build -gcflags "-m -l" printf2.go
# command-line-arguments
./printf2.go:6:6: moved to heap: a
./printf2.go:8:12: ... argument does not escape

我们看到位于第6行声明的变量a居然真的逃逸到了堆上。我们运行一下printf2.go：

$go build -a -gcflags "-l" printf2.go
$./printf2
(0x10ab4a0,0xc0000160c8)
0xc00006cf58
addr of a in bar = 0xc0000160c8
addr of a in bar = 0xc0000160c8
addr of b in bar = 0xc00006cf48

我们看到变量a的地址果然与位于栈上的变量b相差很大，应该就是在堆上，那么这样看那些在go项目中提issue的gopher所言不虚。变量a的地址以实参的形式传入fmt.Printf后被装箱到一个interface{}形参变量中，而从结果来看，fmt.Printf真的要求装箱的形参变量的值部分要在堆上分配，但根据逃逸分析不变性，堆上的对象不能存储一个栈上的地址，而这次存储的是a的地址，于是将a判定为逃逸，于是a自身也就被分配到了堆上(0xc0000160c8)。

我们用go 1.12.7运行一下老版的逃逸分析：

// go 1.12.7
$go build -gcflags "-m -l" printf2.go
# command-line-arguments
./printf2.go:8:40: &a escapes to heap
./printf2.go:8:40: &a escapes to heap
./printf2.go:6:6: moved to heap: a
./printf2.go:8:12: foo ... argument does not escape
./printf2.go:9:32: foo &a does not escape
./printf2.go:10:32: foo &b does not escape

老版的逃逸分析给出了更详细的输出，比如：“&a escapes to heap”，其所指想必就是&a被装箱到堆内存上；而println输出&a则无需&a被装箱。但此后对变量a的最终判定为逃逸。

Go核心团队成员Keith Randall对逃逸分析输出的日志给过一个解释，大致意思是：当逃逸分析输出“b escapes to heap”时，意思是指存储在b中的值逃逸到堆上了(当b为指针变量时才有意义），即任何被b引用的对象必须分配在堆上，而b自身则不需要；如果b自身也逃逸到堆上，那么逃逸分析会输出“&b escapes to heap”。

这个问题目前已经没有fix，其核心问题在8618这个issue中。

5. 手动强制避免逃逸

对于printf2.go中的例子，我们确定一定以及肯定：a不需要逃逸。但若使用fmt.Printf，我们无法阻拦a的逃逸。那是否有一种方法可以干扰逃逸分析，使逃逸分析认为需要在堆上分配的内存对象而我们确定认为不需要逃逸的对象避免逃逸呢？在Go运行时代码中，我们发现了一个函数：

// $GOROOT/src/runtime/stubs.go
func noescape(p unsafe.Pointer) unsafe.Pointer {
    x := uintptr(p)
    return unsafe.Pointer(x ^ 0) // 任何数值与0的异或都是原数
}

并且在Go标准库和运行时实现中，该函数得到大量使用。该函数的实现逻辑使得我们传入的指针值与其返回的指针值是一样的。该函数只是通过uintptr做了一次转换，而这次转换将指针转换成了数值，这“切断”了逃逸分析的数据流跟踪，导致传入的指针避免逃逸。

我们看一下下面例子：

// github.com/bigwhite/experiments/blob/master/go-escape-analysis/go/printf3.go
package main

import (
    "fmt"
    "unsafe"
)

func noescape(p unsafe.Pointer) unsafe.Pointer {
    x := uintptr(p)
    return unsafe.Pointer(x ^ 0)
}

func foo() {
    var a int = 66666666
    var b int = 77
    fmt.Printf("addr of a in bar = %p\n", (*int)(noescape(unsafe.Pointer(&a))))
    println("addr of a in bar =", &a)
    println("addr of b in bar =", &b)
}

func main() {
    foo()
}

对该代码实施统一分析：

$go build -gcflags "-m -l" printf3.go

# command-line-arguments
./printf3.go:8:15: p does not escape
./printf3.go:16:12: ... argument does not escape

我们看到a这次没有逃逸。运行一下编译后的可执行文件：

$./printf3
(0x10ab4c0,0xc00009af50)
0xc00009af58
addr of a in bar = 0xc00009af50
addr of a in bar = 0xc00009af50
addr of b in bar = 0xc00009af48

我们看到a没有像printf2.go那样被放在堆上，这次和b一样都是在栈上分配的。并且在fmt.Printf执行的过程中a的栈地址始终是有效的。

曾有一篇通过逃逸分析优化性能的论文《Escape from Escape Analysis of Golang》使用的就是上述noescape函数的思路，有兴趣的童鞋可以自行下载阅读。

6. 小结

通过这篇文章，我们了解到了逃逸分析要解决的问题、Go逃逸分析的现状与简单原理、一些Go逃逸分析的实例以及对逃逸分析输出日志的说明。最后，我们给出一个强制避开逃逸分析的方案，但要谨慎使用。

日常go开发过程，绝大多数情况无需考虑逃逸分析，除非性能敏感的领域。在这些领域，对系统执行热点路径做一次逃逸分析以及相应的优化，可能回带来程序性能的一定提升。

本文涉及的源码可以在这里下载：https://github.com/bigwhite/experiments/blob/master/go-escape-analysis

“Gopher部落”知识星球正式转正（从试运营星球变成了正式星球）！“gopher部落”旨在打造一个精品Go学习和进阶社群！高品质首发Go技术文章，“三天”首发阅读权，每年两期Go语言发展现状分析，每天提前1小时阅读到新鲜的Gopher日报，网课、技术专栏、图书内容前瞻，六小时内必答保证等满足你关于Go语言生态的所有需求！部落目前虽小，但持续力很强。在2021年上半年，部落将策划两个专题系列分享，并且是部落独享哦：

• Go技术书籍的书摘和读书体会系列
• Go与eBPF系列

欢迎大家加入！

Go技术专栏“改善Go语⾔编程质量的50个有效实践”正在慕课网火热热销中！本专栏主要满足广大gopher关于Go语言进阶的需求，围绕如何写出地道且高质量Go代码给出50条有效实践建议，上线后收到一致好评！欢迎大家订阅！

我的网课“Kubernetes实战：高可用集群搭建、配置、运维与应用”在慕课网热卖中，欢迎小伙伴们订阅学习！

我爱发短信：企业级短信平台定制开发专家 https://tonybai.com/。smspush : 可部署在企业内部的定制化短信平台，三网覆盖，不惧大并发接入，可定制扩展； 短信内容你来定，不再受约束, 接口丰富，支持长短信，签名可选。2020年4月8日，中国三大电信运营商联合发布《5G消息白皮书》，51短信平台也会全新升级到“51商用消息平台”，全面支持5G RCS消息。

著名云主机服务厂商DigitalOcean发布最新的主机计划，入门级Droplet配置升级为：1 core CPU、1G内存、25G高速SSD，价格5$/月。有使用DigitalOcean需求的朋友，可以打开这个链接地址：https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式：

• 微博：https://weibo.com/bigwhite20xx
• 微信公众号：iamtonybai
• 博客：tonybai.com
• github: https://github.com/bigwhite
• “Gopher部落”知识星球：https://public.zsxq.com/groups/51284458844544

微信赞赏：

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

辛丑牛年初七开工大吉的日子(2021.2.18)，Go核心开发团队为中国Gopher们献上了大礼 – Go 1.16版本正式发布了！国内Gopher可以在Go中国官网上下载到Go 1.16在各个平台的安装包：

2020年双12，Go 1.16进入freeze状态，即不再接受新feature，仅fix bug、编写文档和接受安全更新等，那时我曾写过一篇名为《Go 1.16新功能特性不完全前瞻》的文章。当时Go 1.16的发布说明尚处于早期草稿阶段，要了解Go 1.16功能特性都有哪些变化，只能结合当时的release note以及从Go 1.16里程碑中的issue列表中挖掘。

如今Go 1.16版本正式发布了，和当时相比，Go 1.16又有哪些变化呢？在这篇文章中，我们就来一起详细分析一下Go 1.16中那些值得关注的重要变化！

一. 语言规范

如果你是Go语言新手，想必你一定很期待一个大版本的发布会带来许多让人激动人心的语言特性。但是Go语言在这方面肯定会让你“失望”的。伴随着Go 1.0版本一起发布的Go1兼容性承诺给Go语言的规范加了一个“框框”，从Go 1.0到Go 1.15版本，Go语言对语言规范的变更屈指可数，因此资深Gopher在阅读Go版本的release notes时总是很自然的略过这一章节，因为这一章节通常都是如下面这样的描述：

这就是Go的设计哲学：简单！绝不轻易向语言中添加新语法元素增加语言的复杂性。除非是那些社区呼声很高并且是Go核心团队认可的。我们也可以将Go从1.0到Go 1.16这段时间称为“Go憋大招”的阶段，因为就在Go团队发布1.16版本之前不久，Go泛型提案正式被Go核心团队接受(Accepted)：

这意味着什么呢？这意味着在2022年2月份(Go 1.18)，Gopher们将迎来Go有史以来最大一次语言语法变更并且这种变更依然是符合Go1兼容性承诺的，这将避免Go社区出现Python3给Python社区带去的那种“割裂”。不过就像《“能力越大，责任越大” – Go语言之父详解将于Go 1.18发布的Go泛型》一文中Go语言之父Robert Griesemer所说的那样：泛型引入了抽象，但滥用抽象而没有解决实际问题将带来不必要的复杂性，请三思而后行! 离泛型的落地还有一年时间，就让我们耐心等待吧！

二. Go对各平台/OS支持的变更

Go语言具有良好的可移植性，对各主流平台和OS的支持十分全面和及时，Go官博曾发布过一篇文章，简要列出了自Go1以来对各主流平台和OS的支持情况：

• Go1（2012年3月）支持原始系统(译注：上面提到的两种操作系统和三种架构)以及64位和32位x86上的FreeBSD、NetBSD和OpenBSD，以及32位x86上的Plan9。
• Go 1.3（2014年6月）增加了对64位x86上Solaris的支持。
• Go 1.4（2014年12月）增加了对32位ARM上Android和64位x86上Plan9的支持。
• Go 1.5（2015年8月）增加了对64位ARM和64位PowerPC上的Linux以及32位和64位ARM上的iOS的支持。
• Go 1.6（2016年2月）增加了对64位MIPS上的Linux，以及32位x86上的Android的支持。它还增加了32位ARM上的Linux官方二进制下载，主要用于RaspberryPi系统。
• Go 1.7（2016年8月）增加了对的z系统（S390x）上Linux和32位x86上Plan9的支持。
• Go 1.8（2017年2月）增加了对32位MIPS上Linux的支持，并且它增加了64位PowerPC和z系统上Linux的官方二进制下载。
• Go 1.9（2017年8月）增加了对64位ARM上Linux的官方二进制下载。
• Go 1.12（2018年2月）增加了对32位ARM上Windows10 IoT Core的支持，如RaspberryPi3。它还增加了对64位PowerPC上AIX的支持。
• Go 1.14（2019年2月）增加了对64位RISC-V上Linux的支持。

Go 1.7版本中新增的go tool dist list命令还可以帮助我们快速了解各个版本究竟支持哪些平台以及OS的组合。下面是Go 1.16版本该命令的输出：

$go tool dist list
aix/ppc64
android/386
android/amd64
android/arm
android/arm64
darwin/amd64
darwin/arm64
dragonfly/amd64
freebsd/386
freebsd/amd64
freebsd/arm
freebsd/arm64
illumos/amd64
ios/amd64
ios/arm64
js/wasm
linux/386
linux/amd64
linux/arm
linux/arm64
linux/mips
linux/mips64
linux/mips64le
linux/mipsle
linux/ppc64
linux/ppc64le
linux/riscv64
linux/s390x
netbsd/386
netbsd/amd64
netbsd/arm
netbsd/arm64
openbsd/386
openbsd/amd64
openbsd/arm
openbsd/arm64
openbsd/mips64
plan9/386
plan9/amd64
plan9/arm
solaris/amd64
windows/386
windows/amd64
windows/arm

通常我不太会过多关注每次Go版本发布时关于可移植性方面的内容，这次将可移植性单独作为章节主要是因为Go 1.16发布之前的Apple M1芯片事件！

苹果公司再次放弃Intel x86芯片而改用自造的基于Arm64的M1芯片引发业界激烈争论。但现实是搭载Arm64 M1芯片的苹果笔记本已经大量上市，对于编程语言开发团队来说，能做的只有尽快支持这一平台。因此，Go团队给出了在Go 1.16版本中增加对Mac M1的原生支持。

在Go 1.16版本之前，Go也支持darwin/arm64的组合，但那更多是为了构建在iOS上运行的Go应用(利用gomobile)。

Go 1.16做了进一步的细分：将darwin/arm64组合改为apple M1专用；而构建在iOS上运行的Go应用则使用ios/arm64。同时，Go 1.16还增加了ios/amd64组合用于支持在MacOS(amd64)上运行的iOS模拟器中运行Go应用。

另外还值得一提的是在OpenBSD上，Go应用的系统调用需要通过libc发起，而不能再绕过libc而直接使用汇编指令了，这是出于对未来OpenBSD的一些兼容性要求考虑才做出的决定。

三. Go module-aware模式成为默认！

在泛型落地前，Go module依旧是这些年Go语言改进的重点(虽不是语言规范特性)。在Go 1.16版本中，Go module-aware模式成为了默认模式(另一种则是传统的gopath模式)。module-aware模式成为默认意味着什么呢？意味着GO111MODULE的值默认为on了。

自从Go 1.11加入go module，不同go版本在GO111MODULE为不同值的情况下开启的构建模式几经变化，上一次go module-aware模式的行为有较大变更还是在Go 1.13版本中。这里将Go 1.13版本之前、Go 1.13版本以及Go 1.16版本在GO111MODULE为不同值的情况下的行为做一下对比，这样我们可以更好的理解go 1.16中module-aware模式下的行为特性，下面我们就来做一下比对：

我们看到在Go 1.16模式下，依然可以回归到gopath模式。但Go核心团队已经决定拒绝“继续保留GOPATH mode”的提案，并计划在Go 1.17版本中彻底取消gopath mode，仅保留go module-aware mode：

虽然目前仍有项目没有转换到go module下，但根据调查，大多数项目已经选择拥抱go module并完成了转换工作，因此笔者认为即便Go 1.17真的取消了GOPATH mode，对整个Go社区的影响也不会太大了。

Go 1.16中，go module机制还有其他几个变化，这里逐一来看一下：

1. go build/run命令不再自动更新go.mod和go.sum了

为了能更清晰看出Go 1.16与之前版本的差异，我们准备了一个小程序：

// github.com/bigwhite/experiments/blob/master/go1.16-examples/go-modules/helloworld/go.mod
module github.com/bigwhite/helloworld

go 1.16

// github.com/bigwhite/experiments/blob/master/go1.16-examples/go-modules/helloworld/helloworld.go
package main

import "github.com/sirupsen/logrus"

func main() {
    logrus.Println("Hello, World")
}

我们使用go 1.15版本构建一下该程序：

$go build
go: finding module for package github.com/sirupsen/logrus
go: downloading github.com/sirupsen/logrus v1.8.0
go: found github.com/sirupsen/logrus in github.com/sirupsen/logrus v1.8.0

$cat go.mod
module github.com/bigwhite/helloworld

go 1.16

require github.com/sirupsen/logrus v1.8.0

$cat go.sum
github.com/davecgh/go-spew v1.1.1/go.mod h1:J7Y8YcW2NihsgmVo/mv3lAwl/skON4iLHjSsI+c5H38=
github.com/magefile/mage v1.10.0/go.mod h1:z5UZb/iS3GoOSn0JgWuiw7dxlurVYTu+/jHXqQg881A=
github.com/pmezard/go-difflib v1.0.0/go.mod h1:iKH77koFhYxTK1pcRnkKkqfTogsbg7gZNVY4sRDYZ/4=
github.com/sirupsen/logrus v1.8.0 h1:nfhvjKcUMhBMVqbKHJlk5RPrrfYr/NMo3692g0dwfWU=
github.com/sirupsen/logrus v1.8.0/go.mod h1:4GuYW9TZmE769R5STWrRakJc4UqQ3+QQ95fyz7ENv1A=
github.com/stretchr/testify v1.2.2/go.mod h1:a8OnRcib4nhh0OaRAV+Yts87kKdq0PP7pXfy6kDkUVs=
golang.org/x/sys v0.0.0-20191026070338-33540a1f6037 h1:YyJpGZS1sBuBCzLAR1VEpK193GlqGZbnPFnPV/5Rsb4=
golang.org/x/sys v0.0.0-20191026070338-33540a1f6037/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=

在Go 1.15版本中，go build会自动分析源码中的依赖，如果go.mod中没有对该依赖的require，则会自动添加require，同时会将go.sum中将相关包(特定版本)的校验信息写入。

我们将上述helloworld恢复到初始状态，再用go 1.16来build一次：

$go build
helloworld.go:3:8: no required module provides package github.com/sirupsen/logrus; to add it:
    go get github.com/sirupsen/logrus

我们看到go build没有成功，而是给出错误：go.mod中没有对logrus的require，并给出添加对logrus的require的方法(go get github.com/sirupsen/logrus)。

我们就按照go build给出的提示执行go get：

$go get github.com/sirupsen/logrus
go: downloading github.com/magefile/mage v1.10.0
go get: added github.com/sirupsen/logrus v1.8.0

$cat go.mod
module github.com/bigwhite/helloworld

go 1.16

require github.com/sirupsen/logrus v1.8.0 // indirect

$cat go.sum
github.com/davecgh/go-spew v1.1.1/go.mod h1:J7Y8YcW2NihsgmVo/mv3lAwl/skON4iLHjSsI+c5H38=
github.com/magefile/mage v1.10.0 h1:3HiXzCUY12kh9bIuyXShaVe529fJfyqoVM42o/uom2g=
github.com/magefile/mage v1.10.0/go.mod h1:z5UZb/iS3GoOSn0JgWuiw7dxlurVYTu+/jHXqQg881A=
github.com/pmezard/go-difflib v1.0.0/go.mod h1:iKH77koFhYxTK1pcRnkKkqfTogsbg7gZNVY4sRDYZ/4=
github.com/sirupsen/logrus v1.8.0 h1:nfhvjKcUMhBMVqbKHJlk5RPrrfYr/NMo3692g0dwfWU=
github.com/sirupsen/logrus v1.8.0/go.mod h1:4GuYW9TZmE769R5STWrRakJc4UqQ3+QQ95fyz7ENv1A=
github.com/stretchr/testify v1.2.2/go.mod h1:a8OnRcib4nhh0OaRAV+Yts87kKdq0PP7pXfy6kDkUVs=
golang.org/x/sys v0.0.0-20191026070338-33540a1f6037 h1:YyJpGZS1sBuBCzLAR1VEpK193GlqGZbnPFnPV/5Rsb4=
golang.org/x/sys v0.0.0-20191026070338-33540a1f6037/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=

$go build
//ok

我们看到go build并不会向go 1.15及之前版本那样做出有“副作用”的动作：自动修改go.mod和go.sum，而是提示开发人员显式通过go get来添加缺少的包/module，即便是依赖包major版本升级亦是如此。

从自动更新go.mod，到通过提供-mod=readonly选项来避免自动更新go.mod，再到Go 1.16的禁止自动更新go.mod，笔者认为这个变化是Go不喜“隐式转型”的一种延续，即尽量不支持任何可能让开发者产生疑惑或surprise的隐式行为（就像隐式转型），取而代之的是要用一种显式的方式去完成(就像必须显式转型那样)。

我们也看到在go 1.16中，添加或更新go.mod中的依赖，只有显式使用go get。go mod tidy依旧会执行对go.mod的清理，即也可以修改go.mod。

2. 推荐使用go install安装Go可执行文件

在gopath mode下，go install基本“隐身”了，它能做的事情基本都被go get“越俎代庖”了。在go module时代初期，go install更是没有了地位。但Go团队现在想逐步恢复go install的角色：安装Go可执行文件！在Go 1.16中，当go install后面的包携带特定版本号时，go install将忽略当前go.mod中的依赖信息而直接编译安装可执行文件：

// go install回将gopls v0.6.5安装到GOBIN下
$go install golang.org/x/tools/gopls@v0.6.5

并且后续，Go团队会让go get将专注于分析依赖，并获取go包/module，更新go.mod/go.sum，而不再具有安装可执行Go程序的行为能力，这样go get和go install就会各司其职，Gopher们也不会再被两者的重叠行为所迷惑了。现在如果不想go get编译安装，可使用go get -d。

3. 作废module的特定版本

在《如何作废一个已发布的Go module版本，我来告诉你！》一文中，我曾详细探讨了Go引入module后如何作废一个已发布的go module版本。当时已经知晓Go 1.16会在go.mod中增加retract指示符，因此也给出了在Go 1.16下retract一个module版本的原理和例子(基于当时的go tip)。

Go 1.16正式版在工具的输出提示方面做了进一步的优化，让开发人员体验更为友好。我们还是以一个简单的例子来看看在Go 1.16中作废一个module版本的过程吧。

在我的bitbucket账户下有一个名为m2的Go module(https://bitbucket.org/bigwhite/m2/)，当前它的版本为v1.0.0：

// bitbucket.org/bigwhite/m2
$cat go.mod
module bitbucket.org/bigwhite/m2

go 1.15

$cat m2.go
package m2

import "fmt"

func M2() {
    fmt.Println("This is m2.M2 - v1.0.0")
}

我们在本地建立一个m2的消费者：

// github.com/bigwhite/experiments/blob/master/go1.16-examples/go-modules/retract

$cat go.mod
module github.com/bigwhite/retractdemo

go 1.16

$cat main.go
package main

import "bitbucket.org/bigwhite/m2"

func main() {
    m2.M2()
}

运行这个消费者：

$go run main.go
main.go:3:8: no required module provides package bitbucket.org/bigwhite/m2; to add it:
    go get bitbucket.org/bigwhite/m2

由于上面提到的原因，go run不会隐式修改go.mod，因此我们需要手工go get m2：

$go get bitbucket.org/bigwhite/m2
go: downloading bitbucket.org/bigwhite/m2 v1.0.0
go get: added bitbucket.org/bigwhite/m2 v1.0.0

再来运行消费者，我们将看到以下运行成功的结果：

$go run main.go
This is m2.M2 - v1.0.0

现在m2的作者对m2打了小补丁，版本升级到了v1.0.1。这时消费者通过go list命令可以看到m2的最新版本(前提：go proxy server上已经cache了最新的v1.0.1)：

$go list -m -u all
github.com/bigwhite/retractdemo
bitbucket.org/bigwhite/m2 v1.0.0 [v1.0.1]

消费者可以通过go get将对m2的依赖升级到最新的v1.0.1：

$go get bitbucket.org/bigwhite/m2@v1.0.1

go get: upgraded bitbucket.org/bigwhite/m2 v1.0.0 => v1.0.1
$go run main.go
This is m2.M2 - v1.0.1

m2作者收到issue，有人指出v1.0.1版本有安全漏洞，m2作者确认了该漏洞，但此时v1.0.1版已经发布并被缓存到各大go proxy server上，已经无法撤回。m2作者便想到了Go 1.16中引入的retract指示符，于是它在m2的go.mod用retract指示符做了如下更新：

$cat go.mod
module bitbucket.org/bigwhite/m2

// 存在安全漏洞
retract v1.0.1

go 1.15

并将此次更新作为v1.0.2发布了出去！

之后，当消费者使用go list查看m2是否有最新更新时，便会看到retract提示：(前提：go proxy server上已经cache了最新的v1.0.2)

$go list -m -u all
github.com/bigwhite/retractdemo
bitbucket.org/bigwhite/m2 v1.0.1 (retracted) [v1.0.2]

执行go get会收到带有更详尽信息的retract提示和问题解决建议：

$go get .
go: warning: bitbucket.org/bigwhite/m2@v1.0.1: retracted by module author: 存在安全漏洞
go: to switch to the latest unretracted version, run:
    go get bitbucket.org/bigwhite/m2@latest

于是消费者按照提示执行go get bitbucket.org/bigwhite/m2@latest：

$go get bitbucket.org/bigwhite/m2@latest
go get: upgraded bitbucket.org/bigwhite/m2 v1.0.1 => v1.0.2

$cat go.mod
module github.com/bigwhite/retractdemo

go 1.16

require bitbucket.org/bigwhite/m2 v1.0.2

$go run main.go
This is m2.M2 - v1.0.2

到此，retract的使命终于完成了！

4. 引入GOVCS环境变量，控制module源码获取所使用的版本控制工具

出于安全考虑，Go 1.16引入GOVCS环境变量，用于在go命令直接从代码托管站点获取源码时对所使用的版本控制工具进行约束，如果是从go proxy server获取源码，那么GOVCS将不起作用，因为go工具与go proxy server之间使用的是GOPROXY协议。

GOVCS的默认值为public:git|hg,private:all，即对所有公共module允许采用git或hg获取源码，而对私有module则不限制版本控制工具的使用。

如果要允许使用所有工具，可像下面这样设置GOVCS：

GOVCS=*:all

如果要禁止使用任何版本控制工具去直接获取源码（不通过go proxy），那么可以像下面这样设置GOVCS:

GOVCS=*:off

5. 有关go module的文档更新

自打Go 1.14版本宣布go module生产可用后，Go核心团队在说服和帮助Go社区全面拥抱go module的方面不可谓不努力。在文档方面亦是如此，最初有关go module的文档仅局限于go build命令相关以及有关go module的wiki。随着go module日益成熟，go.mod格式的日益稳定，Go团队在1.16版本中还将go module相关文档升级到go reference的层次，与go language ref等并列：

我们看到有关go module的ref文档包括：

• Go Modules Reference https://tip.golang.org/ref/mod
• go.mod file reference https://tip.golang.org/doc/modules/gomod-ref

官方还编写了详细的Go module日常开发时的使用方法，包括：开发与发布module、module发布与版本管理工作流、升级major号等。

建议每个gopher都要将这些文档仔细阅读一遍，以更为深入了解和使用go module。

四. 编译器与运行时

1. runtime/metrics包

在《Go 1.16新功能特性不完全前瞻》一文中，我们提到过：Go 1.16 新增了runtime/metrics包，以替代runtime.ReadMemStats和debug.ReadGCStats输出runtime的各种度量数据，这个包更通用稳定，性能也更好。限于篇幅这里不展开，后续可能会以单独的文章讲解这个新包。

2. GODEBUG环境变量支持跟踪包init函数的消耗

GODEBUG=inittrace=1这个特性也保留在了Go 1.16正式版当中了。当GODEBUG环境变量包含inittrace=1时，Go运行时将会报告各个源代码文件中的init函数的执行时间和内存开辟消耗情况。我们用上面的helloworld示例(github.com/bigwhite/experiments/blob/master/go1.16-examples/go-modules/helloworld)来看看该特性的效果：

$go build
$GODEBUG=inittrace=1 ./helloworld
init internal/bytealg @0.006 ms, 0 ms clock, 0 bytes, 0 allocs
init runtime @0.037 ms, 0.031 ms clock, 0 bytes, 0 allocs
init errors @0.29 ms, 0.005 ms clock, 0 bytes, 0 allocs
init math @0.31 ms, 0 ms clock, 0 bytes, 0 allocs
init strconv @0.33 ms, 0.002 ms clock, 32 bytes, 2 allocs
init sync @0.35 ms, 0.003 ms clock, 16 bytes, 1 allocs
init unicode @0.37 ms, 0.10 ms clock, 24568 bytes, 30 allocs
init reflect @0.49 ms, 0.002 ms clock, 0 bytes, 0 allocs
init io @0.51 ms, 0.003 ms clock, 144 bytes, 9 allocs
init internal/oserror @0.53 ms, 0 ms clock, 80 bytes, 5 allocs
init syscall @0.55 ms, 0.010 ms clock, 752 bytes, 2 allocs
init time @0.58 ms, 0.010 ms clock, 384 bytes, 8 allocs
init path @0.60 ms, 0 ms clock, 16 bytes, 1 allocs
init io/fs @0.62 ms, 0.002 ms clock, 16 bytes, 1 allocs
init internal/poll @0.63 ms, 0.001 ms clock, 64 bytes, 4 allocs
init os @0.65 ms, 0.089 ms clock, 4472 bytes, 20 allocs
init fmt @0.77 ms, 0.006 ms clock, 32 bytes, 2 allocs
init bytes @0.84 ms, 0.004 ms clock, 48 bytes, 3 allocs
init context @0.87 ms, 0 ms clock, 128 bytes, 4 allocs
init encoding/binary @0.89 ms, 0.002 ms clock, 16 bytes, 1 allocs
init encoding/base64 @0.90 ms, 0.015 ms clock, 1408 bytes, 4 allocs
init encoding/json @0.93 ms, 0.002 ms clock, 32 bytes, 2 allocs
init log @0.95 ms, 0 ms clock, 80 bytes, 1 allocs
init golang.org/x/sys/unix @0.96 ms, 0.002 ms clock, 48 bytes, 1 allocs
init bufio @0.98 ms, 0 ms clock, 176 bytes, 11 allocs
init github.com/sirupsen/logrus @0.99 ms, 0.009 ms clock, 312 bytes, 5 allocs
INFO[0000] Hello, World

以下面这行为例：

init fmt @0.77 ms, 0.006 ms clock, 32 bytes, 2 allocs

• 0.77ms表示的是自从程序启动后到fmt包init执行所过去的时间(以ms为单位)
• 0.006 ms clock表示fmt包init函数执行的时间(以ms为单位)
• 312 bytes表示fmt包init函数在heap上分配的内存大小；
• 5 allocs表示的是fmt包init函数在heap上执行内存分配操作的次数。

3. Go runtime默认使用MADV_DONTNEED

Go 1.15版本时，我们可以通过GODEBUG=madvdontneed=1让Go runtime使用MADV_DONTNEED替代MADV_FREE达到更积极的将不用的内存释放给OS的效果(如果使用MADV_FREE，只有OS内存压力很大时，才会真正回收内存)，这将使得通过top查看到的常驻系统内存(RSS或RES)指标更实时也更真实反映当前Go进程对os内存的实际占用情况(仅使用linux)。

在Go 1.16版本中，Go runtime将MADV_DONTNEED作为默认值了，我们可以用一个小例子来对比一下这种变化：

// github.com/bigwhite/experiments/blob/master/go1.16-examples/runtime/memalloc.go
package main

import "time"

func allocMem() []byte {
    b := make([]byte, 1024*1024*1) //1M
    return b
}

func main() {
    for i := 0; i < 100000; i++ {
        _ = allocMem()
        time.Sleep(500 * time.Millisecond)
    }
}

我们在linux上使用go 1.16版本编译该程序，考虑到优化和inline的作用，我们在编译时关闭优化和内联：

$go build -gcflags "-l -N" memalloc.go

接下来，我们分两次运行该程序，并使用top监控其RES指标值：

$./memalloc
$ top -p 9273
  PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND
 9273 root      20   0  704264   5840    856 S  0.0  0.3   0:00.03 memalloc
 9273 root      20   0  704264   3728    856 S  0.0  0.2   0:00.05 memalloc
 ... ...

$GODEBUG=madvdontneed=0 ./memalloc
$ top -p 9415

  PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND
 9415 root      20   0  704264   5624    856 S  0.0  0.3   0:00.03 memalloc
 9415 root      20   0  704264   5624    856 S  0.0  0.3   0:00.05 memalloc

我们看到默认运行的memalloc(开启MADV_DONTNEED)，RES很积极的变化，当上一次显示5840，下一秒内存就被归还给OS，RES变为3728。而关闭MADV_DONTNEED（GODEBUG=madvdontneed=0）的memalloc，OS就会很lazy的回收内存，RES一直显示5624这个值。

4. Go链接器的进一步进行现代化改造

新一代Go链接器的更新计划从Go 1.15版本开始，在Go 1.15版本链接器的性能、资源占用、最终二进制文件大小等方面都有了一定幅度的优化提升。Go 1.16版本延续了这一势头：相比于Go 1.15，官方宣称(在linux上)性能有20%-25%的提升，资源占用下降5%-15%。更为直观的是编译出的二进制文件的size，我实测了一下文件大小下降10%以上：

-rwxr-xr-x   1 tonybai  staff    22M  2 21 23:03 my-large-app-demo*
-rwxr-xr-x   1 tonybai  staff    25M  2 21 23:02 my-large-app-demo-go1.15*

并且和Go 1.15的链接器优化仅针对amd64平台和基于ELF格式的OS不同，这次的链接器优化已经扩展到所有平台和os组合上。

五. 标准库

1. io/fs包

Go 1.16标准库新增io/fs包，并定义了一个fs.File接口用于表示一个只读文件树(tree of file)的抽象。之所以要加入io/fs包并新增fs.File接口源于对嵌入静态资源文件(embed static asset)的实现需求。虽说实现embed功能特性是直接原因，但io/fs的加入也不是“临时起意”，早在很多年前的godoc实现时，对一个抽象的文件系统接口的需求就已经被提了出来并给出了实现：

最终这份实现以godoc工具的vfs包的形式一直长期存在着。虽然它的实现有些复杂，抽象程度不够，但却对io/fs包的设计有着重要的参考价值。同时也部分弥补了Rob Pike老爷子当年没有将os.File设计为interface的遗憾，Ian Lance Taylor 2013年提出的增加VFS层的想法也一并得以实现。

io/fs包的两个最重要的接口如下：

// $GOROOT/src/io/fs/fs.go

// An FS provides access to a hierarchical file system.
//
// The FS interface is the minimum implementation required of the file system.
// A file system may implement additional interfaces,
// such as ReadFileFS, to provide additional or optimized functionality.
type FS interface {
        // Open opens the named file.
        //
        // When Open returns an error, it should be of type *PathError
        // with the Op field set to "open", the Path field set to name,
        // and the Err field describing the problem.
        //
        // Open should reject attempts to open names that do not satisfy
        // ValidPath(name), returning a *PathError with Err set to
        // ErrInvalid or ErrNotExist.
        Open(name string) (File, error)
}

// A File provides access to a single file.
// The File interface is the minimum implementation required of the file.
// A file may implement additional interfaces, such as
// ReadDirFile, ReaderAt, or Seeker, to provide additional or optimized functionality.
type File interface {
        Stat() (FileInfo, error)
        Read([]byte) (int, error)
        Close() error
}

FS接口代表虚拟文件系统的最小抽象，File接口则是虚拟文件的最小抽象，我们可以基于这两个接口进行扩展以及对接现有的一些实现。io/fs包也给出了一些扩展FS的“样例”：

这两个接口的设计也是“Go秉持定义小接口惯例”的延续(更多关于这方面的内容，可以参考我的专栏文章《定义小接口是Go惯例》)。

io/fs包的加入也契合了Go社区对vfs的需求，在Go团队决定加入io/fs并提交实现后，社区做出了积极的反应，在github上我们能看到好多为各类对象提供针对io/fs.FS接口实现的项目：

io/fs.FS和File接口在后续Go演进过程中会像io.Writer和io.Reader一样成为Gopher们在操作类文件树时最爱的接口。

2. embed包

在《Go 1.16新功能特性不完全前瞻》一文中我们曾重点说了Go 1.16将支持在Go二进制文件中嵌入静态文件并给出了一个在webserver中嵌入文本文件的例子：

// github.com/bigwhite/experiments/blob/master/go1.16-examples/stdlib/embed/webserver/hello.txt
hello, go 1.16

// github.com/bigwhite/experiments/blob/master/go1.16-examples/stdlib/embed/webserver/main.go
package main

import (
         _  "embed"
    "net/http"
)

//go:embed hello.txt
var s string

func main() {
    http.Handle("/", http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        w.Write([]byte(s))
    }))
    http.ListenAndServe(":8080", nil)
}

我们看到在这个例子，通过//go:embed hello.txt，我们可以轻易地将hello.txt的内容存储在包级变量s中，而s将作为每个http request的应答返回给客户端。

在Go二进制文件中嵌入静态资源文件是Go核心团队对社区广泛需求的积极回应。在go 1.16以前，Go社区开源的类嵌入静态文件的项目不下十多个，在Russ Cox关于embed的设计草案中，他就列了十多个：

• github.com/jteeuwen/go-bindata(主流实现)
• github.com/alecthomas/gobundle
• github.com/GeertJohan/go.rice
• github.com/go-playground/statics
• github.com/gobuffalo/packr
• github.com/knadh/stuffbin
• github.com/mjibson/esc
• github.com/omeid/go-resources
• github.com/phogolabs/parcello
• github.com/pyros2097/go-embed
• github.com/rakyll/statik
• github.com/shurcooL/vfsgen
• github.com/UnnoTed/fileb0x
• github.com/wlbr/templify
• perkeep.org/pkg/fileembed

Go1.16原生支持嵌入并且给出一种开发者体验良好的实现方案，这对Go社区是一种极大的鼓励，也是Go团队重视社区声音的重要表现。

笔者认为embed机制是Go 1.16中玩法最多的一种机制，也是极具新玩法挖掘潜力的机制。在embed加入Go tip不久，很多Gopher就已经“脑洞大开”：

有通过embed嵌入版本号的：

// github.com/bigwhite/experiments/blob/master/go1.16-examples/stdlib/embed/version/main.go
package main

import (
    _ "embed"
    "fmt"
    "strings"
)

var (
    Version string = strings.TrimSpace(version)
    //go:embed version.txt
    version string
)

func main() {
    fmt.Printf("Version %q\n", Version)
}

// github.com/bigwhite/experiments/blob/master/go1.16-examples/stdlib/embed/version/version.txt
v1.0.1

有通过embed打印自身源码的：

// github.com/bigwhite/experiments/blob/master/go1.16-examples/stdlib/embed/printself/main.go
package main

import (
        _ "embed"
        "fmt"
)

//go:embed main.go
var src string

func main() {
        fmt.Print(src)
}

更是有将一个完整的、复杂的带有js支持的web站点直接嵌入到go二进制文件中的示例，鉴于篇幅，这里就不一一列举了。

Go擅长于Web服务，而embed机制的引入粗略来看，可以大大简化web服务中资源文件的部署，估计这也是之前社区青睐各种静态资源文件嵌入项目的原因。embed估计也会成为Go 1.16中最被gopher们喜爱的功能特性。

不过embed机制的实现目前有如下一些局限：

• 仅支持在包级变量前使用//go:embed指示符，还不支持在函数/方法内的局部变量上应用embed指示符（当然我们可以通过将包级变量赋值给局部变量来过渡一下）；
• 使用//go:embed指示符的包必须以空导入的方式导入embed包，二者是成对出现的，缺一不可；

3. net包的变化

在Go 1.16之前，我们检测在一个已关闭的网络上进行I/O操作或在I/O完成前网络被关闭的情况，只能通过匹配字符串”use of closed network connection”的方式来进行。之前的版本没有针对这个错误定义“哨兵错误变量”(更多关于哨兵错误变量的内容，可以参考我的专栏文章《别笑！这就是 Go 的错误处理哲学》)，Go 1.16增加了ErrClosed这个“哨兵错误变量”，我们可以通过errors.Is(err, net.ErrClosed)来检测是否是上述错误情况。

六. 小结

从Go 1.16版本变更的功能特性中，我看到了Go团队更加重视社区的声音，这也是Go团队一直持续努力的目标。在最新的Go proposal review meeting的结论中，我们还看到了这样的一个proposal被accept：

要知道这个proposal的提议是将在Go 1.18才会落地的泛型实现分支merge到Go项目master分支，也就是说在Go 1.17中就会包含“不会发布的”泛型部分实现，这在之前是不可能实现的(之前，新proposal必须有原型实现的分支，实现并经过社区测试与Go核心委员会评估后才会在特定版本merge到master分支)。虽说泛型的开发有其特殊情况，但能被accept，这恰证明了Go社区的声音在Go核心团队日益受到重视。

如果你还没有升级到Go 1.16，那么现在正是时候。

本文中涉及的代码可以在这里下载。https://github.com/bigwhite/experiments/tree/master/go1.16-examples

“Gopher部落”知识星球正式转正（从试运营星球变成了正式星球）！“gopher部落”旨在打造一个精品Go学习和进阶社群！高品质首发Go技术文章，“三天”首发阅读权，每年两期Go语言发展现状分析，每天提前1小时阅读到新鲜的Gopher日报，网课、技术专栏、图书内容前瞻，六小时内必答保证等满足你关于Go语言生态的所有需求！部落目前虽小，但持续力很强。在2021年上半年，部落将策划两个专题系列分享，并且是部落独享哦：

• Go技术书籍的书摘和读书体会系列
• Go与eBPF系列

考虑到部落尚处于推广期，这里仍然为大家准备了新人优惠券，虽然优惠幅度有所下降，但依然物超所值，早到早享哦！

Go技术专栏“改善Go语⾔编程质量的50个有效实践”正在慕课网火热热销中！本专栏主要满足广大gopher关于Go语言进阶的需求，围绕如何写出地道且高质量Go代码给出50条有效实践建议，上线后收到一致好评！欢迎大家订阅！目前该技术专栏正在新春促销！关注我的个人公众号“iamtonybai”，发送“go专栏活动”即可获取专栏专属优惠码，可在订阅专栏时抵扣20元哦(2021.2月末前有效)。

我的网课“Kubernetes实战：高可用集群搭建、配置、运维与应用”在慕课网热卖中，欢迎小伙伴们订阅学习！

我爱发短信：企业级短信平台定制开发专家 https://tonybai.com/。smspush : 可部署在企业内部的定制化短信平台，三网覆盖，不惧大并发接入，可定制扩展； 短信内容你来定，不再受约束, 接口丰富，支持长短信，签名可选。2020年4月8日，中国三大电信运营商联合发布《5G消息白皮书》，51短信平台也会全新升级到“51商用消息平台”，全面支持5G RCS消息。

著名云主机服务厂商DigitalOcean发布最新的主机计划，入门级Droplet配置升级为：1 core CPU、1G内存、25G高速SSD，价格5$/月。有使用DigitalOcean需求的朋友，可以打开这个链接地址：https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式：

• 微博：https://weibo.com/bigwhite20xx
• 微信公众号：iamtonybai
• 博客：tonybai.com
• github: https://github.com/bigwhite
• “Gopher部落”知识星球：https://public.zsxq.com/groups/51284458844544

微信赞赏：

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。