本文翻译自《Visualizing memory management in Golang》。

在这个由多部分组成的系列文章中，我旨在揭示内存管理背后的概念，并对某些现代编程语言的内存管理机制做更深入的探究。我希望该系列文章可以使您对这些语言在内存管理方面正在发生的事情能有所了解。

在本章中，我们将研究Go编程语言（Golang）的内存管理。和C/C++、Rust等一样，Go是一种静态类型的编译型语言。因此，Go不需要VM，Go应用程序二进制文件中嵌入了一个小型运行时(Go runtime)，可以处理诸如垃圾收集(GC)，调度和并发之类的语言功能。

如果您还没有阅读本系列的第一部分，请先阅读它，因为在那篇文章中我解释了栈(stack)和堆(heap)内存之间的区别，这对于理解本文很有用。

这篇文章基于Go 1.13的默认官方实现，有些概念细节可能会在Go的未来版本中发生变化

Go内部内存结构

首先，让我们看看Go内部的内存结构是什么样子的。

Go运行时将Goroutines（G）调度到逻辑处理器（P）上执行。每个P都有一台逻辑机器（M）。在这篇文章中，我们将使用P、M和G。如果您不熟悉Go调度程序，请先阅读《Go调度程序：Ms，Ps和Gs》。

每个Go程序进程都由操作系统（OS）分配了一些虚拟内存，这是该进程可以访问的全部内存。在这个虚拟内存中实际正在使用的内存称为Resident Set（驻留内存)。该空间由内部内存结构管理，如下所示：

这是一个简化的视图，基于Go使用的内部对象。实际上，Go将内存划分和分组为页(page)，就像这篇文章描述的那样。

这与我们在前几章中看到的JVM和V8的内存结构完全不同。如您所见，这里没有分代内存。这样做的主要原因是TCMalloc（线程缓存Malloc），Go自己的内存分配器正是基于该模型实现的。

让我们看看Go独特的内存构造是什么样子的：

页堆page heap（mheap）

这里是Go存储动态数据（在编译时无法计算大小的任何数据）的地方。它是最大的内存块，也是进行垃圾收集（GC）的地方。

驻留内存(resident set)被划分为每个大小为8KB的页，并由一个全局mheap对象管理。

大对象（大小> 32kb的对象）直接从mheap分配。这些大对象申请请求是以获取中央锁(central lock)为代价的，因此在任何给定时间点只能满足一个P的请求。

mheap通过将页归类为不同结构进行管理的：

• mspan：mspan是mheap中管理的内存页的最基本结构。这是一个双向链接列表，其中包含起始页面的地址，span size class和span中的页面数量。像TCMalloc一样，Go将内存页按大小分为67个不同类别，大小从8字节到32KB，如下图所示

每个span存在两个，一个span用于带指针的对象（scan class），一个用于无指针的对象（noscan class）。这在GC期间有帮助，因为noscan类查找活动对象时无需遍历span。

• mcentral：mcentral将相同大小级别的span归类在一起。每个mcentral包含两个mspanList：

  • empty：双向span链表，包括没有空闲对象的span或缓存mcache中的span。当此处的span被释放时，它将被移至non-empty span链表。
  • non-empty：有空闲对象的span双向链表。当从mcentral请求新的span，mcentral将从该链表中获取span并将其移入empty span链表。

如果mcentral没有可用的span，它将向mheap请求新页。

• arena：堆在已分配的虚拟内存中根据需要增长和缩小。当需要更多内存时，mheap从虚拟内存中以每块64MB（对于64位体系结构）为单位获取新内存， 这块内存被称为arena。这块内存也会被划分页并映射到span。

• mcache：这是一个非常有趣的构造。mcache是提供给P（逻辑处理器）的高速缓存，用于存储小对象（对象大小<= 32Kb）。尽管这类似于线程堆栈，但它是堆的一部分，用于动态数据。所有类大小的mcache包含scan和noscan类型mspan。Goroutine可以从mcache没有任何锁的情况下获取内存，因为一次P只能有一个锁G。因此，这更有效。mcache从mcentral需要时请求新的span。

栈

这是栈存储区，每个Goroutine（G）有一个栈。在这里存储了静态数据，包括函数栈帧，静态结构，原生类型值和指向动态结构的指针。这与分配给每个P的mcache不是一回事。

Go内存使用（栈与堆）

现在我们已经清楚了内存的组织方式，现在让我们看看程序执行时Go是如何使用Stack和Heap的。

我们使用下面的这个Go程序，代码没有针对正确性进行优化，因此可以忽略诸如不必要的中间变量之类的问题，因此，重点是可视化栈和堆内存的使用情况。

package main

import "fmt"

type Employee struct {
    name   string
    salary int
    sales  int
    bonus  int
}

const BONUS_PERCENTAGE = 10

func getBonusPercentage(salary int) int {
    percentage := (salary * BONUS_PERCENTAGE) / 100
    return percentage
}

func findEmployeeBonus(salary, noOfSales int) int {
    bonusPercentage := getBonusPercentage(salary)
    bonus := bonusPercentage * noOfSales
    return bonus
}

func main() {
    var john = Employee{"John", 5000, 5, 0}
    john.bonus = findEmployeeBonus(john.salary, john.sales)
    fmt.Println(john.bonus)
}

与许多垃圾回收语言相比，Go的一个主要区别是许多对象直接在程序栈上分配。Go编译器使用一种称为“逃逸分析”的过程来查找其生命周期在编译时已知的对象，并将它们分配在栈上，而不是在垃圾回收的堆内存中。在编译过程中，Go进行了逃逸分析，以确定哪些可以放入栈（静态数据），哪些需要放入堆（动态数据）。我们可以通过运行带有-gcflags '-m'标志的go build命令来查看分析的细节。对于上面的代码，它将输出如下内容：

❯ go build -gcflags '-m' gc.go
# command-line-arguments
temp/gc.go:14:6: can inline getBonusPercentage
temp/gc.go:19:6: can inline findEmployeeBonus
temp/gc.go:20:39: inlining call to getBonusPercentage
temp/gc.go:27:32: inlining call to findEmployeeBonus
temp/gc.go:27:32: inlining call to getBonusPercentage
temp/gc.go:28:13: inlining call to fmt.Println
temp/gc.go:28:18: john.bonus escapes to heap
temp/gc.go:28:13: io.Writer(os.Stdout) escapes to heap
temp/gc.go:28:13: main []interface {} literal does not escape
<autogenerated>:1: os.(*File).close .this does not escape

让我们将其可视化。单击下方图片下载幻灯片，然后翻阅幻灯片，以查看上述程序是如何执行的以及如何使用栈和堆存储器的：

正如你看到的：

• main函数被保存栈中的“main栈帧”中
• 每个函数调用都作为一个栈帧块被添加到栈中
• 包括参数和返回值在内的所有静态变量都保存在函数的栈帧块内
• 无论类型如何，所有静态值都直接存储在栈中。这也适用于全局范畴
• 所有动态类型都在堆上创建，并且被栈上的指针所引用。小于32Kb的对象由P的mcache分配。这同样适用于全局范畴
• 具有静态数据的结构体保留在栈上，直到在该位置将任何动态值添加到该结构中为止。该结构被移到堆上。
• 从当前函数调用的函数被推入堆顶部
• 当函数返回时，其栈帧将从栈中删除
• 一旦主过程(main)完成，堆上的对象将不再具有来自Stack的指针的引用，并成为孤立对象

您可以看到，栈是由操作系统自动管理的，而不是Go本身。因此，我们不必担心栈。另一方面，堆并不是由操作系统自动管理的，并且由于其具有最大的内存空间并保存动态数据，因此它可能会成倍增长，从而导致我们的程序随着时间耗尽内存。随着时间的流逝，它也变得支离破碎，使应用程序变慢。解决这些问题是垃圾收集的初衷。

Go内存管理

Go的内存管理包括在需要内存时自动分配内存，在不再需要内存时进行垃圾回收。这是由标准库完成的(译注：应该是运行时完成的)。与C/C++不同，开发人员不必处理它，并且Go进行的基础管理得到了高效的优化。

内存分配

许多采用垃圾收集的编程语言都使用分代内存结构来使收集高效，同时进行压缩以减少碎片。正如我们前面所看到的，Go在这里采用了不同的方法，Go在构造内存方面有很大的不同。Go使用线程本地缓存(thread local cache)来加速小对象分配，并维护着scan/noscan的span来加速GC。这种结构以及整个过程避免了碎片，从而在GC期间无需做紧缩处理。让我们看看这种分配是如何发生的。

Go根据对象的大小决定对象的分配过程，分为三类：

微小对象(Tiny)（size <16B）：使用mcache的微小分配器分配大小小于16个字节的对象。这是高效的，并且在单个16字节块上可完成多个微小分配。

小对象（尺寸16B〜32KB）：大小在16个字节和32k字节之间的对象被分配在G运行所在的P的mcache的对应的mspan size class上。

在微小型和小型对象分配中，如果mspan的列表为空，分配器将从mheap获取大量的页面用于mspan。如果mheap为空或没有足够大的页面满足分配请求，那么它将从操作系统中分配一组新的页（至少1MB）。

大对象（大小> 32KB）：大于32 KB的对象直接分配在mheap的相应大小类上(size class)。如果mheap为空或没有足够大的页面满足分配请求，则它将从操作系统中分配一组新的页（至少1MB）。

注意：您可以在此处找到以幻灯片形式记录的GIF图像

垃圾收集(GC)

现在我们知道Go如何分配内存了，让我们再看看它是如何自动回收堆内存的，这对于应用程序的性能非常重要。当程序尝试在堆上分配的内存大于可用内存时，我们会遇到内存不足的错误(out of memory)。不当的堆内存管理也可能导致内存泄漏。

Go通过垃圾回收机制管理堆内存。简单来说，它释放了孤儿对象(orphan object)使用的内存，所谓孤儿对象是指那些不再被栈直接或间接（通过另一个对象中的引用）引用的对象，从而为创建新对象的分配腾出了空间。

从Go 1.12版本开始，Go使用了非分代的、并发的、基于三色标记和清除的垃圾回收器。收集过程大致如下所示，由于版本之间的差异，我不想做细节的描述。但是，如果您对此感兴趣，那么我推荐这个很棒的系列文章。

当完成一定百分比（GC百分比）的堆分配，GC过程就开始了。收集器将在不同工作阶段执行不同的工作：

• 标记设置（mark setup, stw）：GC启动时，收集器将打开写屏障(write barrier)，以便可以在下一个并发阶段维护数据完整性。此步骤需要非常小的暂停(stw)，因此每个正在运行的Goroutine都会暂停以启用此功能，然后继续。

• 标记（并发执行的）：打开写屏障后，实际的标记过程将并行启动，这个过程将使用可用CPU能力的25%。对应的P将保留，直到该标记过程完成。这个过程是使用专用的Goroutines完成的。在这个过程中，GC标记了堆中的活动对象(被任何活动的Goroutine的栈中引用的）。当采集花费更长的时间时，该过程可以从应用程序中征用活动的Goroutine来辅助标记过程。这称为Mark Assist。

• 标记终止（stw）：标记一旦完成，每个活动的Goroutine都会暂停，写入屏障将关闭，清理任务将开始执行。GC还会在此处计算下一个GC目标。完成此操作后，保留的P的会释放回应用程序。

• 清除（并发）：当完成收集并尝试分配后，清除过程开始将未标记为活动的对象回收。清除的内存量与分配的内存量是同步的(即回收后的内存马上可以被再分配了)。

让我们在一个Goroutine中看看这个过程。为了简洁起见，将对象的数量保持较小。单击下面图片，可下载幻灯片，然后翻阅幻灯片查看该过程：

• 我们以一个Goroutine为例，实际过程是对所有活动Goroutine都进行的。首先打开写屏障。
• 标记过程选择GC root并将其着色为黑色，并以深度优先的树状方式遍历该该根节点里面的指针，将遇到的每个对象都标记为灰色
• 当它到达noscan span中的某个对象或某个对象不再有指针时，它完成了这个根节点的标记操作并选取下一个GC root对象
• 当扫描完所有GC root节点之后，它将选取灰色对象，并以类似方式继续遍历其指针
• 如果在打开写屏障时，指向对象的指针发生任何变化，则该对象将变为灰色，以便GC对其进行重新扫描
• 当不再有灰色对象留下时，标记过程完成，并且写屏障被关闭
• 当分配开始时(因为写屏障关闭了)，清除过程也会同步进行

我们看到这里有一些停止世界(stop)的过程，但是通常这个过程非常快，在大多数情况下可以忽略不计。对象的着色在span的gcmarkBits属性中进行。

结论

这篇文章为您提供了Go内存结构和内存管理的概述。这里不是全面详尽的说明，有许多更高级的概念，实现细节在各个版本之间都在不断变化。但是对于大多数Go开发人员来说，这些信息就已经足够了，我希望它能帮助您编写出更好的、性能更高的应用程序，牢记这些，将有助于您避免下一个内存泄漏问题。

参考文献

• blog.learngoprogramming.com https://blog.learngoprogramming.com/a-visual-guide-to-golang-memory-allocator-from-ground-up-e132258453ed
• www.ardanlabs.com https://www.ardanlabs.com/blog/2018/12/garbage-collection-in-go-part1-semantics.html
• povilasv.me https://povilasv.me/go-memory-management/
• medium.com/a-journey-with-go https://medium.com/a-journey-with-go/go-memory-management-and-allocation-a7396d430f44
• medium.com/a-journey-with-go https://medium.com/a-journey-with-go/go-how-does-the-garbage-collector-mark-the-memory-72cfc12c6976
• hub.packtpub.com https://hub.packtpub.com/implementing-memory-management-with-golang-garbage-collector/
• making.pusher.com https://making.pusher.com/golangs-real-time-gc-in-theory-and-practice/
• segment.com/blog https://segment.com/blog/allocation-efficiency-in-high-performance-go-services/
• go101.org https://go101.org/article/memory-block.html

我的网课“Kubernetes实战：高可用集群搭建、配置、运维与应用”在慕课网上线了，感谢小伙伴们学习支持！

我爱发短信：企业级短信平台定制开发专家 https://tonybai.com/
smspush : 可部署在企业内部的定制化短信平台，三网覆盖，不惧大并发接入，可定制扩展； 短信内容你来定，不再受约束, 接口丰富，支持长短信，签名可选。

著名云主机服务厂商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

微信赞赏：

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

可能是得益于2020年2月26日Go 1.14的发布，在2020年3月份的TIOBE编程语言排行榜上，Go重新进入TOP 10，而去年同期Go仅排行在第18位。虽然Go语言以及其他主流语言在榜单上的“上蹿下跳”让这个榜单的权威性饱受质疑:)，但Go在这样的一个时间节点能进入TOP 10，对于Gopher和Go社区来说，总还是一个不错的结果。并且在一定层度上说明：Go在努力耕耘十年后，已经在世界主流编程语言之林中牢牢占据了自己的一个位置。

Go自从宣布Go1 Compatible后，直到这次的Go 1.14发布，Go的语法和核心库都没有做出不兼容的变化。这让很多其他主流语言的拥趸们觉得Go很“无趣”。但这种承诺恰恰是Go团队背后努力付出的结果，因此Go的每个发布版本都值得广大gopher尊重，每个发布版本都是Go团队能拿出的最好版本。

下面我们就来解读一下Go 1.14的变化，看看这个新版本中有哪些值得我们重点关注的变化。

一. 语言规范

和其他主流语言相比，Go语言的语法规范的变化那是极其少的（广大Gopher们已经习惯了这个节奏:)），偶尔发布一个变化，那自然是要引起广大Gopher严重关注的:)。不过事先说明：只要Go版本依然是1.x，那么这个规范变化也是backward-compitable的。

Go 1.14新增的语法变化是：嵌入接口的方法集可重叠。这个变化背后的朴素思想是这样的。看下面代码(来自这里)：

type I interface { f(); String() string }
type J interface { g(); String() string }

type IJ interface { I; J }  ----- (1)
type IJ interface { f(); g(); String() string }  ---- (2)

代码中已知定义的I和J两个接口的方法集中都包含有String() string这个方法。在这样的情况下，我们如果想定义一个方法集合为Union(I, J)的新接口IJ，我们在Go 1.13及之前的版本中只能使用第(2)种方式，即只能在新接口IJ中重新书写一遍所有的方法原型，而无法像第(1)种方式那样使用嵌入接口的简洁方式进行。

Go 1.14通过支持嵌入接口的方法集可重叠解决了这个问题：

// go1.14-examples/overlapping_interface.go
package foo

type I interface {
    f()
    String() string
}
type J interface {
    g()
    String() string
}

type IJ interface {
    I
    J
}

在go 1.13.6上运行：

$go build overlapping_interface.go
# command-line-arguments
./overlapping_interface.go:14:2: duplicate method String

但在go 1.14上运行：

$go build overlapping_interface.go

// 一切ok，无报错

不过对overlapping interface的支持仅限于接口定义中，如果你要在struct定义中嵌入interface，比如像下面这样：

// go1.14-examples/overlapping_interface1.go
package main

type I interface {
    f()
    String() string
}

type implOfI struct{}

func (implOfI) f() {}
func (implOfI) String() string {
    return "implOfI"
}

type J interface {
    g()
    String() string
}

type implOfJ struct{}

func (implOfJ) g() {}
func (implOfJ) String() string {
    return "implOfJ"
}

type Foo struct {
    I
    J
}

func main() {
    f := Foo{
        I: implOfI{},
        J: implOfJ{},
    }
    println(f.String())
}

虽然Go编译器没有直接指出结构体Foo中嵌入的两个接口I和J存在方法的重叠，但在使用Foo结构体时，下面的编译器错误肯定还是会给出的：

$ go run overlapping_interface1.go
# command-line-arguments
./overlapping_interface1.go:37:11: ambiguous selector f.String

对于结构体中嵌入的接口的方法集是否存在overlap，go编译器似乎并没有严格做“实时”检查，这个检查被延迟到为结构体实例选择method的执行者环节了，就像上面例子那样。如果我们此时让Foo结构体 override一个String方法，那么即便I和J的方法集存在overlap也是无关紧要的，因为编译器不会再模棱两可，可以正确的为Foo实例选出究竟执行哪个String方法：

// go1.14-examples/overlapping_interface2.go

.... ....

func (Foo) String() string {
        return "Foo"
}

func main() {
        f := Foo{
                I: implOfI{},
                J: implOfJ{},
        }
        println(f.String())
}

运行该代码：

$go run overlapping_interface2.go
Foo

二. Go运行时

1. 支持异步抢占式调度

在《Goroutine调度实例简要分析》一文中，我曾提到过这样一个例子：

// go1.14-examples/preemption_scheduler.go
package main

import (
    "fmt"
    "runtime"
    "time"
)

func deadloop() {
    for {
    }
}

func main() {
    runtime.GOMAXPROCS(1)
    go deadloop()
    for {
        time.Sleep(time.Second * 1)
        fmt.Println("I got scheduled!")
    }
}

在只有一个P的情况下，上面的代码中deadloop所在goroutine将持续占据该P，使得main goroutine中的代码得不到调度(GOMAXPROCS=1的情况下)，因此我们无法看到I got scheduled!字样输出。这是因为Go 1.13及以前的版本的抢占是”协作式“的，只在有函数调用的地方才能插入“抢占”代码(埋点)，而deadloop没有给编译器插入抢占代码的机会。这会导致GC在等待所有goroutine停止时等待时间过长，从而导致GC延迟；甚至在一些特殊情况下，导致在STW（stop the world）时死锁。

Go 1.14采用了基于系统信号的异步抢占调度，这样上面的deadloop所在的goroutine也可以被抢占了：

// 使用Go 1.14版本编译器运行上述代码

$go run preemption_scheduler.go
I got scheduled!
I got scheduled!
I got scheduled!

不过由于系统信号可能在代码执行到任意地方发生，在Go runtime能cover到的地方，Go runtime自然会处理好这些系统信号。但是如果你是通过syscall包或golang.org/x/sys/unix在Unix/Linux/Mac上直接进行系统调用，那么一旦在系统调用执行过程中进程收到系统中断信号，这些系统调用就会失败，并以EINTR错误返回，尤其是低速系统调用，包括：读写特定类型文件(管道、终端设备、网络设备)、进程间通信等。在这样的情况下，我们就需要自己处理EINTR错误。一个最常见的错误处理方式就是重试。对于可重入的系统调用来说，在收到EINTR信号后的重试是安全的。如果你没有自己调用syscall包，那么异步抢占调度对你已有的代码几乎无影响。

Go 1.14的异步抢占调度在windows/arm, darwin/arm, js/wasm, and plan9/*上依然尚未支持，Go团队计划在Go 1.15中解决掉这些问题。

2. defer性能得以继续优化

在Go 1.13中，defer性能得到理论上30%的提升。我们还用那个例子来看看go 1.14与go 1.13版本相比defer性能又有多少提升，同时再看看使用defer和不使用defer的对比：

// go1.14-examples/defer_benchmark_test.go
package defer_test

import "testing"

func sum(max int) int {
    total := 0
    for i := 0; i < max; i++ {
        total += i
    }

    return total
}

func foo() {
    defer func() {
        sum(10)
    }()

    sum(100)
}

func Bar() {
    sum(100)
    sum(10)
}

func BenchmarkDefer(b *testing.B) {
    for i := 0; i < b.N; i++ {
        foo()
    }
}
func BenchmarkWithoutDefer(b *testing.B) {
    for i := 0; i < b.N; i++ {
        Bar()
    }
}

我们分别用Go 1.13和Go 1.14运行上面的基准测试代码：

Go 1.13:

$go test -bench . defer_benchmark_test.go
goos: darwin
goarch: amd64
BenchmarkDefer-8              17873574            66.7 ns/op
BenchmarkWithoutDefer-8       26935401            43.7 ns/op
PASS
ok      command-line-arguments    2.491s

Go 1.14:

$go test -bench . defer_benchmark_test.go
goos: darwin
goarch: amd64
BenchmarkDefer-8              26179819            45.1 ns/op
BenchmarkWithoutDefer-8       26116602            43.5 ns/op
PASS
ok      command-line-arguments    2.418s

我们看到，Go 1.14的defer性能照比Go 1.13还有大幅提升，并且已经与不使用defer的性能相差无几了，这也是Go官方鼓励大家在性能敏感的代码执行路径上也大胆使用defer的原因。

3. internal timer的重新实现

鉴于go timer长期以来性能不能令人满意，Go 1.14几乎重新实现了runtime层的timer。其实现思路遵循了Dmitry Vyukov几年前提出的实现逻辑：将timer分配到每个P上，降低锁竞争；去掉timer thread，减少上下文切换开销；使用netpoll的timeout实现timer机制。

// $GOROOT/src/runtime/time.go

type timer struct {
        // If this timer is on a heap, which P's heap it is on.
        // puintptr rather than *p to match uintptr in the versions
        // of this struct defined in other packages.
        pp puintptr

}

// addtimer adds a timer to the current P.
// This should only be called with a newly created timer.
// That avoids the risk of changing the when field of a timer in some P's heap,
// which could cause the heap to become unsorted.

func addtimer(t *timer) {
        // when must never be negative; otherwise runtimer will overflow
        // during its delta calculation and never expire other runtime timers.
        if t.when < 0 {
                t.when = maxWhen
        }
        if t.status != timerNoStatus {
                badTimer()
        }
        t.status = timerWaiting

        addInitializedTimer(t)
}

// addInitializedTimer adds an initialized timer to the current P.
func addInitializedTimer(t *timer) {
        when := t.when

        pp := getg().m.p.ptr()
        lock(&pp.timersLock)
        ok := cleantimers(pp) && doaddtimer(pp, t)
        unlock(&pp.timersLock)
        if !ok {
                badTimer()
        }

        wakeNetPoller(when)
}
... ...

这样你的程序中如果大量使用time.After、time.Tick或者在处理网络连接时大量使用SetDeadline，使用Go 1.14编译后，你的应用将得到timer性能的自然提升。

三. Go module已经production ready了

Go 1.14中带来的关于go module的最大惊喜就是Go module已经production ready了，这意味着关于go module的运作机制，go tool的各种命令和其参数形式、行为特征已趋稳定了。笔者从Go 1.11引入go module以来就一直关注和使用Go module，尤其是Go 1.13中增加go module proxy的支持，使得中国大陆的gopher再也不用为获取类似golang.org/x/xxx路径下的module而苦恼了。

Go 1.14中go module的主要变动如下：

a) module-aware模式下对vendor的处理：如果go.mod中go version是go 1.14及以上，且当前repo顶层目录下有vendor目录，那么go工具链将默认使用vendor(即-mod=vendor)中的package，而不是module cache中的($GOPATH/pkg/mod下)。同时在这种模式下，go 工具会校验vendor/modules.txt与go.mod文件，它们需要保持同步，否则报错。

在上述前提下，如要非要使用module cache构建，则需要为go工具链显式传入-mod=mod ，比如：go build -mod=mod ./...。

b) 增加GOINSECURE，可以不再要求非得以https获取module，或者即便使用https，也不再对server证书进行校验。

c) 在module-aware模式下，如果没有建立go.mod或go工具链无法找到go.mod，那么你必须显式传入要处理的go源文件列表，否则go tools将需要你明确go.mod。比如：在一个没有go.mod的目录下，要编译一个hello.go，我们需要使用go build hello.go(hello.go需要显式放在命令后面），如果你执行go build .就会得到类似如下错误信息：

$go build .
go: cannot find main module, but found .git/config in /Users/tonybai
    to create a module there, run:
    cd .. && go mod init

也就是说在没有go.mod的情况下，go工具链的功能是受限的。

d) go module支持subversion仓库了，不过subversion使用应该很“小众”了。

要系统全面的了解go module的当前行为机制，建议还是通读一遍Go command手册中关于module的说明以及官方go module wiki。

四. 编译器

Go 1.14 go编译器在-race和-msan的情况下，默认会执行-d=checkptr，即对unsafe.Pointer的使用进行合法性检查，主要检查两项内容：

• 当将unsafe.Pointer转型为*T时，T的内存对齐系数不能高于原地址的

比如下面代码：

// go1.14-examples/compiler_checkptr1.go
package main

import (
    "fmt"
    "unsafe"
)

func main() {
    var byteArray = [10]byte{'a', 'b', 'c'}
    var p *int64 = (*int64)(unsafe.Pointer(&byteArray[1]))
    fmt.Println(*p)
}

以-race运行上述代码：

$go run -race compiler_checkptr1.go
fatal error: checkptr: unsafe pointer conversion

goroutine 1 [running]:
runtime.throw(0x11646fd, 0x23)
    /Users/tonybai/.bin/go1.14/src/runtime/panic.go:1112 +0x72 fp=0xc00004cee8 sp=0xc00004ceb8 pc=0x106d152
runtime.checkptrAlignment(0xc00004cf5f, 0x1136880, 0x1)
    /Users/tonybai/.bin/go1.14/src/runtime/checkptr.go:13 +0xd0 fp=0xc00004cf18 sp=0xc00004cee8 pc=0x1043b70
main.main()
    /Users/tonybai/go/src/github.com/bigwhite/experiments/go1.14-examples/compiler_checkptr1.go:10 +0x70 fp=0xc00004cf88 sp=0xc00004cf18 pc=0x11283b0
runtime.main()
    /Users/tonybai/.bin/go1.14/src/runtime/proc.go:203 +0x212 fp=0xc00004cfe0 sp=0xc00004cf88 pc=0x106f7a2
runtime.goexit()
    /Users/tonybai/.bin/go1.14/src/runtime/asm_amd64.s:1373 +0x1 fp=0xc00004cfe8 sp=0xc00004cfe0 pc=0x109b801
exit status 2

checkptr检测到：转换后的int64类型的内存对齐系数严格程度要高于转化前的原地址(一个byte变量的地址)。int64对齐系数为8，而一个byte变量地址对齐系数仅为1。

• 做完指针算术后，转换后的unsafe.Pointer仍应指向原先Go堆对象

compiler_checkptr2.go
package main

import (
    "unsafe"
)

func main() {
    var n = 5
    b := make([]byte, n)
    end := unsafe.Pointer(uintptr(unsafe.Pointer(&b[0])) + uintptr(n+10))
    _ = end
}

运行上述代码：

$go run  -race compiler_checkptr2.go
fatal error: checkptr: unsafe pointer arithmetic

goroutine 1 [running]:
runtime.throw(0x10b618b, 0x23)
    /Users/tonybai/.bin/go1.14/src/runtime/panic.go:1112 +0x72 fp=0xc00003e720 sp=0xc00003e6f0 pc=0x1067192
runtime.checkptrArithmetic(0xc0000180b7, 0xc00003e770, 0x1, 0x1)
    /Users/tonybai/.bin/go1.14/src/runtime/checkptr.go:41 +0xb5 fp=0xc00003e750 sp=0xc00003e720 pc=0x1043055
main.main()
    /Users/tonybai/go/src/github.com/bigwhite/experiments/go1.14-examples/compiler_checkptr2.go:10 +0x8d fp=0xc00003e788 sp=0xc00003e750 pc=0x1096ced
runtime.main()
    /Users/tonybai/.bin/go1.14/src/runtime/proc.go:203 +0x212 fp=0xc00003e7e0 sp=0xc00003e788 pc=0x10697e2
runtime.goexit()
    /Users/tonybai/.bin/go1.14/src/runtime/asm_amd64.s:1373 +0x1 fp=0xc00003e7e8 sp=0xc00003e7e0 pc=0x1092581
exit status 2

checkptr检测到转换后的unsafe.Pointer已经超出原先heap object: b的范围了，于是报错。

不过目前Go标准库依然尚未能完全通过checkptr的检查，因为有些库代码显然违反了unsafe.Pointer的使用规则。

Go 1.13引入了新的Escape Analysis，Go 1.14中我们可以通过-m=2查看详细的逃逸分析过程日志，比如：

$go run  -gcflags '-m=2' compiler_checkptr2.go
# command-line-arguments
./compiler_checkptr2.go:7:6: can inline main as: func() { var n int; n = 5; b := make([]byte, n); end := unsafe.Pointer(uintptr(unsafe.Pointer(&b[0])) + uintptr(n + 100)); _ = end }
./compiler_checkptr2.go:9:11: make([]byte, n) escapes to heap:
./compiler_checkptr2.go:9:11:   flow: {heap} = &{storage for make([]byte, n)}:
./compiler_checkptr2.go:9:11:     from make([]byte, n) (non-constant size) at ./compiler_checkptr2.go:9:11
./compiler_checkptr2.go:9:11: make([]byte, n) escapes to heap

五. 标准库

每个Go版本，变化最多的就是标准库，这里我们挑一个可能影响后续我们编写单元测试行为方式的变化说说，那就是testing包的T和B类型都增加了自己的Cleanup方法。我们通过代码来看一下Cleanup方法的作用：

// go1.14-examples/testing_cleanup_test.go
package main

import "testing"

func TestCase1(t *testing.T) {

    t.Run("A=1", func(t *testing.T) {
        t.Logf("subtest1 in testcase1")

    })
    t.Run("A=2", func(t *testing.T) {
        t.Logf("subtest2 in testcase1")
    })
    t.Cleanup(func() {
        t.Logf("cleanup1 in testcase1")
    })
    t.Cleanup(func() {
        t.Logf("cleanup2 in testcase1")
    })
}

func TestCase2(t *testing.T) {
    t.Cleanup(func() {
        t.Logf("cleanup1 in testcase2")
    })
    t.Cleanup(func() {
        t.Logf("cleanup2 in testcase2")
    })
}

运行上面测试：

$go test -v testing_cleanup_test.go
=== RUN   TestCase1
=== RUN   TestCase1/A=1
    TestCase1/A=1: testing_cleanup_test.go:8: subtest1 in testcase1
=== RUN   TestCase1/A=2
    TestCase1/A=2: testing_cleanup_test.go:12: subtest2 in testcase1
    TestCase1: testing_cleanup_test.go:18: cleanup2 in testcase1
    TestCase1: testing_cleanup_test.go:15: cleanup1 in testcase1
--- PASS: TestCase1 (0.00s)
    --- PASS: TestCase1/A=1 (0.00s)
    --- PASS: TestCase1/A=2 (0.00s)
=== RUN   TestCase2
    TestCase2: testing_cleanup_test.go:27: cleanup2 in testcase2
    TestCase2: testing_cleanup_test.go:24: cleanup1 in testcase2
--- PASS: TestCase2 (0.00s)
PASS
ok      command-line-arguments    0.005s

我们看到：

• Cleanup方法运行于所有测试以及其子测试完成之后。

• Cleanup方法类似于defer，先注册的cleanup函数后执行（比如上面例子中各个case的cleanup1和cleanup2）。

在拥有Cleanup方法前，我们经常像下面这样做：

// go1.14-examples/old_testing_cleanup_test.go
package main

import "testing"

func setup(t *testing.T) func() {
    t.Logf("setup before test")
    return func() {
        t.Logf("teardown/cleanup after test")
    }
}

func TestCase1(t *testing.T) {
    f := setup(t)
    defer f()
    t.Logf("test the testcase")
}

运行上面测试：

$go test -v old_testing_cleanup_test.go
=== RUN   TestCase1
    TestCase1: old_testing_cleanup_test.go:6: setup before test
    TestCase1: old_testing_cleanup_test.go:15: test the testcase
    TestCase1: old_testing_cleanup_test.go:8: teardown/cleanup after test
--- PASS: TestCase1 (0.00s)
PASS
ok      command-line-arguments    0.005s

有了Cleanup方法后，我们就不需要再像上面那样单独编写一个返回cleanup函数的setup函数了。

此次Go 1.14还将对unicode标准的支持从unicode 11 升级到 unicode 12 ，共增加了554个新字符。

六. 其他

超强的可移植性是Go的一个知名标签，在新平台支持方面，Go向来是“急先锋”。Go 1.14为64bit RISC-V提供了在linux上的实验性支持(GOOS=linux, GOARCH=riscv64)。

rust语言已经通过cargo-fuzz从工具层面为fuzz test提供了基础支持。Go 1.14也在这方面做出了努力，并且Go已经在向将fuzz test变成Go test的一等公民而努力。

七. 小结

Go 1.14的详细变更说明在这里可以查看。整个版本的milestone对应的issue集合在这里。

不过目前Go 1.14在特定版本linux内核上会出现crash的问题，当然这个问题源于这些内核的一个已知bug。在这个issue中有关于这个问题的详细说明，涉及到的Linux内核版本包括：5.2.x, 5.3.0-5.3.14, 5.4.0-5.4.1。
本篇博客涉及的代码在这里可以下载。

我的网课“Kubernetes实战：高可用集群搭建、配置、运维与应用”在慕课网上线了，感谢小伙伴们学习支持！

我爱发短信：企业级短信平台定制开发专家 https://tonybai.com/
smspush : 可部署在企业内部的定制化短信平台，三网覆盖，不惧大并发接入，可定制扩展； 短信内容你来定，不再受约束, 接口丰富，支持长短信，签名可选。

著名云主机服务厂商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

微信赞赏：

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