本文永久链接 – https://tonybai.com/2023/06/13/understand-go-gc-overhead-behind-the-convenience

注：本文部分摘录自GopherChina 2023前的《Go高级工程师训练营》课程。

1. 简介

当今，移动互联网和人工智能的快(越)速(来)发(越)展(卷)，对编程语言的高效性和便利性提出了更高的要求。Go作为一门高效、简洁、易于学习的编程语言，受到了越来越多开发者的青睐。

Go语言的垃圾回收机制（Garbage Collection，简称 GC）是其重要的运行机制之一，它可以帮助开发人员避免手动管理内存的复杂性和错误，为开发者带来开发上的便利，使开发者可以更专注于业务逻辑的实现。然而，GC的便利性背后也带来了一定的系统开销，作为成熟的Go开发者，我们需要了解GC带来的开销和优化方法，以帮助我们更好的了解和使用Go语言。

了解Go GC的原理是了解GC开销的前提条件，我们首先来简要看看Go GC的原理。

2. Go GC的简明原理

Go语言的垃圾回收器采用了并发三色标记清除算法（Concurrent Tri-Color Mark-And-Sweep），尽可能减少STW(stop the world)时间，以降低吞吐为代价换取低延迟，实现了高效的垃圾回收。

标记清除算法的基本原理是，垃圾回收器将所有的存活对象标记为“活”的，未被标记的对象则被认为是垃圾。经典的标记清除算法通常分为两个阶段：

• 标记阶段：垃圾回收器从根对象开始，遍历所有可达对象，并将它们标记为“活”的。
• 清除阶段：垃圾回收器从堆的起始地址开始遍历，将未被标记的对象清除，回收内存。

Go语言的垃圾回收器采用了三色标记法(Tri-Color Marking)，将堆上的内存对象分为三种颜色：

• 白色：未被标记为“活”的对象，是潜在的垃圾，后续可能会被GC回收。
• 灰色：待扫描的对象，当扫描某个灰色对象时，GC会将其标记为黑色，然后将该对象指向的所有对象都标记为灰色，待后续标记。
• 黑色：被标记为“活”的对象，在这轮GC中不会被回收。

垃圾回收器开始工作时不存在黑色对象，垃圾回收器会将根对象标记为灰色，并从根对象(通常是栈对象和全局对象)开始遍历。垃圾回收器会将灰色对象标记为黑色，并将该对象指向的对象标记为灰色。垃圾回收器重复这个过程，直到所有可达对象都被标记为黑色。最后，垃圾回收器清除所有未被标记为黑色的对象，即清除所有白色对象。

前面提到过，Go语言的GC采用了并发标记的技术，以减少GC对系统性能的影响。并发标记指的是在GC运行时程序仍然可以继续运行，而不必停止程序的执行。为了避免程序修改对象时对标记的影响，GC会利用混合写屏障技术，在对象被修改时进行特殊标记(若程序修改黑色对象(已被扫描完毕，不会再扫描)，使之指向白色对象时，写屏障技术会将白色对象标记为灰色，避免白色对象被释放导致黑色对象出现悬挂指针的情况)。写屏障技术可以有效避免并发标记阶段的错误标记，但也会带来一定的性能开销。

3. GC的开销

从上面的Go GC原理来看，GC在带来便利的同时，开销是不可避免的。

3.1 GC开销的主要来源

GC开销的主要来源包括以下几个：

• STW时间

Go诞生初期，GC的实现不是很成熟，STW时间很长，这让很对想使用Go在生产上作为一番的开发人员打了“退堂鼓”。Go 1.5版本自举后，GC的STW时间大幅下降，又经过几个版本的打磨后，STW时间已经被Go降低到很短了，通常情况下都在1毫秒以内，甚至可以到几十微秒，STW时间的大幅缩短让Go真正走进了生产环境。

不过再短的STW对于程序执行来说也是开销，因为STW期间，所有属于业务逻辑的代码都无法向前推进(make progress)。

那么一个GC周期究竟会做几次STW呢？这里借用“Go语言原本”中的一个表格：

这个表格描述了Go垃圾回收器主要包含的五个阶段，我们看到虽然采用了并发三色标记和清除，但在一次GC周期内，还是要有2次STW，一次是结束标记，关闭写屏障，另一次是为下一个周期的并发标记做准备，开启写屏障。

STW时间依然是GC开销的主要来源之一。减少STW时间对于优化GC的性能依然至关重要，尤其是任意场景下都要保证尽可能短暂的STW，但这是Go core团队的任务。

• 标记与清除阶段的负荷

在标记与清除阶段，GC需要遍历堆内存中的所有对象，并进行标记和清除，这也是十分消耗cpu的工作。

• 标记辅助

GC的并发标记并非只是由特定(dedicated) goroutine去完成的，为了保证GC标记清扫的速度不低于业务goroutine分配内存的速度，保证程序不因消耗内存过快过大而被OS OOM(Out Of Memory) Killed，GC引入标记辅助技术，即让每个业务goroutine都有机会参与到GC标记工作中来！并且，这种标记辅助采用的是一种补偿机制，即该业务goroutine分配的内存越多，它要辅助标记的内存就越多。一旦某个业务goroutine被“拉壮丁”执行标记辅助工作，那么该goroutine的业务执行就会暂停，业务逻辑也就无法向前推进。

• 堆内存的释放

当Go GC回收了堆内存之后，如果堆的大小变得比之前小了，那么垃圾回收器会向操作系统归还多余的内存空间。在Linux等操作系统中，操作系统会将这些内存页标记为“未使用”，但是这些内存页并不会立即返回给操作系统，而是留给程序使用，以便程序将来再次申请内存时可以直接使用已经分配的内存页，从而减少内存分配的时间和开销。当程序没有使用这些内存页一段时间后，操作系统会将这些内存页回收，并将它们标记为“可用”，并在需要时重新分配给程序。这个过程是由操作系统的虚拟内存管理机制来完成的，具体的开销取决于操作系统的实现和硬件的性能等因素。

3.2 度量GC的开销

由于标记辅助技术的存在，单纯地从每个GC cycle的执行时间以及GC间隔时间来度量GC开销似乎就不那么准确了，更为直观的反映GC开销的是GC消耗cpu的占比。

不过目前上没有特别好的工具可以特别直观且直接告诉你当前Go程序执行时GC CPU占用率。我们可以通过pprof工具或类似Pyroscope这样的持续profiling的图形化工具来间接查看GC的cpu占用。

比如：通过Pyroscope提供的火焰图，查看runtime.gcBgMarkWorker(runtime后台专用的用于GC标记阶段的goroutine执行的函数)和runtime.gcAssistAlloc(标记辅助时调用的函数)的cpu消耗时间。

更为完整的Go runtime metrics指标，可以查看metrics包的文档。

注：GODEBUG=gctrace=1可以输出关于每个GC周期的详细信息，关于详细信息中各个字段的解读可以参见这里。更高级的选手还可以使用Go execution tracer工具来剖析GC的开销。

GC的CPU开销占比通常在25%以下，一旦超过这个负荷比例，就要考虑做调优了，Go保证GC cpu占用不会超过50%。

4. 优化GC的开销

优化GC的开销是提高系统性能和响应速度的重要手段。

前面我们分析了Go GC开销的主要来源。下面就针对每种来源说说优化开销的可能性与手段。

4.1 缩短STW时间

我们知道一旦GC STW后，所有业务逻辑都将暂停，这期间的CPU由GC 100%占用，降低STW时间是降低gc cpu占比的好方法。不过STW的算法是Go核心团队把控的，降低每个GC周期的STW时间也是Go核心团队的不二职责。从用户层面是很难影响到单次STW时间的。

不过，我们可以通过减少GC次数来间接减少STW次数，从而降低GC CPU占比。当然减少GC次数对后面的所有优化手段都有效，这是一个总开关。

那么如何减少GC次数呢？我们先来了解GC的触发时机。Go GC触发时机大体分为三种：

• 手动触发：调用runtime.GC()
• 常规触发：Target heap memory = Live heap + (Live heap + GC roots) * GOGC / 100
• sysmon后台周期性强制触发GC

我们看到，这三种触发时机我们能干预的只有常规触发，而常规触发的公式中，可以调整的只有GOGC这个参数(等价于debug.SetGCPercent())。GOGC默认值为100，也就是说当新分配heap内存的数量是上一周期的活跃heap内存的一倍的时候，触发GC：

如果我们将GOGC改为200，那么GC的触发间隔将增加，频度会下降，CPU开销会降低(6.4%->3.8%)，如下图：

不过这是以整个程序的内存开销增大为代价的(40MB -> 60MB)，并且对一般开发者而言，GOGC的值改起来确有风险，稍有不慎可能就会触发OMM killed。之前uber曾发表一篇文章，讲述了uber是如何通过在线自动调整GOGC参数来大幅降低CPU资源开销的，可以一看。

当然除了GOGC这一个唯一可调参数外，Go社区在降低GC频率方面也有自己的小妙招，比如之前经常使用的ballast(压舱石)技术。其原理就是在程序初始化时先分配一块大内存：

func main() {

    // Create a large heap allocation of 10 GiB
    ballast := make([]byte, 10<<30)

    // Application execution continues
    // ...
    runtime.KeepAlive(ballast) // make sure the ballast won't be collected
}

这块内存仅体现在VSZ中，即该程序进程的虚拟内存中，但并不占用程序进程的常驻内存(RSS)中。但一旦分配，Go GC就会将其算作是一个“活”堆内存对象，在计算下一次GC时就会将其作为上述公式中的live heap考量。如果ballast为10GB，那么GC就会在程序每新分配10GB内存时才会被触发。

注：RSS是这个进程目前在主内存（RAM）中拥有多少内存。VSZ是该进程总共有多少虚拟内存。

Go 1.19版本引入了Soft memory limit，这个方案在runtime/debug包中添加了一个名为SetMemoryLimit的函数以及GOMEMLIMIT环境变量，通过他们任意一个都可以设定Go应用的Memory limit。

一旦设定了Memory limit，当Go堆大小达到“Memory limit减去非堆内存后的值”时，一轮GC会被触发。即便你手动关闭了GC(GOGC=off)，GC亦会被触发。 不过soft memory limit不保证不会出现oom-killed。并且如果一个Go应用的live heap object超过了soft memory limit但还尚未被kill，那么此时GC可能会被频繁触发，将大量消耗cpu资源：

但为了保证在这种情况下业务依然能继续进行，soft memory limit方案保证GC最多只会使用50%的CPU算力，以保证业务处理依然能够得到cpu资源。

那么多大的值是合理的soft memory limit值呢？在Go服务独占容器资源时，一个好的经验法则是留下额外的5-10%的空间。uber在其博客中设定的limit为资源上限的70%，也是一个不错的经验值。

Memory Limit被看作是Go官方的ballast替代方案，但还是不有所不同的。Memory limit只是规定了一个上限，如果未到memory limit，Go的常规GC还是会照例执行的。GOGC=off+ soft Memory limit下的行为特征与ballast更类似，不过将GC关掉的风险还是很大的，要三思而后行。

Go GC没有采用分代机制，每次都是FullGC，减少GC次数确是降低GC CPU开销的良方。不过除此之外，我们还有一个优化GC开销的方法，我们继续看。

4.2 减少堆内存的分配和释放

GC开销大的根源在于heap object多，Go的每轮GC都是FullGC，每轮都要将所有heap object标记(mark)一遍，即便大多数heap object都是长期alive的，因此，一个直观的降低GC开销的方法就是减少heap object的数量，即减少alloc。

沿着这样的思路，我们可以很直接的想出如下两种手段：

• 把小对象聚合到一个结构体中，然后做一次分配即可

这样不仅利于减少分配次数，还有利于减少堆内存碎片，提高堆内存的利用率。如果整个结构体中没有指针对象，那么结构体的分配与释放将更加高效，具体原因可参见我的《Go GC如何检测内存对象中是否包含指针》一文。

• 重用

Go GC开销优化的一个典型手段就是内存空间重用，即建立一个池子，需要的时候从池中申请，用完后再放回池子里，供其他goroutine重用。这个过程不再有分配与释放。

Go中最典型的重用的例子就是sync.Pool的使用，不过sync.Pool并非完全不做释放操作，它是在一定程度上提高了重用的比例罢了。

5. 小结

Go GC的自动内存管理减少了内存泄漏和悬挂指针等问题。然而，GC给开发者带来便利的同时，开销也是不可避免的，它会对系统的性能和响应速度产生影响。Go开发者需要了解这些开销。

在本文中，我们介绍了GC的基本原理、GC的开销及其主要来源，并提供了优化GC开销的一些方法。

然而，要想有效地利用 GC，开发者需要了解其内部机制和算法，并根据实际情况进行调优。

除了通过GC参数降低GC频率外，在实际编码过程中，开发者还应该尽可能地减少对象的分配以降低Go每轮FullGC扫描对象的数量。

GC的优化是一项长期的工作。开发者应该不断地监控系统的性能和行为，并根据需要进行调整和优化，以确保系统的性能和响应速度始终保持在最佳状态。

6. 参考资料

• A Guide to the Go Garbage Collector – https://go.dev/doc/gc-guide
• Go GC的过去、现在与未来 – https://golang.design/under-the-hood/zh-cn/part2runtime/ch08gc/history/
• Go memory ballast: How I learned to stop worrying and love the heap – https://blog.twitch.tv/en/2019/04/10/go-memory-ballast-how-i-learnt-to-stop-worrying-and-love-the-heap/

“Gopher部落”知识星球旨在打造一个精品Go学习和进阶社群！高品质首发Go技术文章，“三天”首发阅读权，每年两期Go语言发展现状分析，每天提前1小时阅读到新鲜的Gopher日报，网课、技术专栏、图书内容前瞻，六小时内必答保证等满足你关于Go语言生态的所有需求！2023年，Gopher部落将进一步聚焦于如何编写雅、地道、可读、可测试的Go代码，关注代码质量并深入理解Go核心技术，并继续加强与星友的互动。欢迎大家加入！

著名云主机服务厂商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
• 微博2：https://weibo.com/u/6484441286
• 博客：tonybai.com
• github: https://github.com/bigwhite

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

本文永久链接 – https://tonybai.com/2023/04/16/understanding-unsafe-assume-no-moving-gc

1. 背景

在之前的《Go与神经网络：张量计算》一文中，不知道大家是否发现了，所有例子代码执行时，前面都加了一个环境变量ASSUME_NO_MOVING_GC_UNSAFE_RISK_IT_WITH，就像下面这样：

$ASSUME_NO_MOVING_GC_UNSAFE_RISK_IT_WITH=go1.20 go run tensor.go

这是怎么回事儿呢？如果不加上这个环境变量会发生什么呢？我们来试试：

// https://github.com/bigwhite/experiments/blob/master/go-and-nn/tensor-operations/tensor.go

$go run tensor.go
panic: Something in this program imports go4.org/unsafe/assume-no-moving-gc to declare that it assumes a non-moving garbage collector, but your version of go4.org/unsafe/assume-no-moving-gc hasn't been updated to assert that it's safe against the go1.20 runtime. If you want to risk it, run with environment variable ASSUME_NO_MOVING_GC_UNSAFE_RISK_IT_WITH=go1.20 set. Notably, if go1.20 adds a moving garbage collector, this program is unsafe to use.

goroutine 1 [running]:
go4.org/unsafe/assume-no-moving-gc.init.0()
    /Users/tonybai/Go/pkg/mod/go4.org/unsafe/assume-no-moving-gc@v0.0.0-20220617031537-928513b29760/untested.go:25 +0x1ba
exit status 2

我们看到，程序panic了！我们看到panic的错误信息提到了go4.org/unsafe/assume-no-moving-gc这个包，显然是这个包在“作祟”，那么assume-no-moving-gc这个包究竟是做什么的呢？究竟有何功用？为何gorgonia.org/tensor会依赖这个包？这超出了《Go与神经网络：张量计算》那篇文章的范畴，所以我并未提及。在这篇文章中，我就和大家一起来理解一下unsafe-assume-no-moving-gc这个包。

2. unsafe-assume-no-moving-gc究竟是什么包？

unsafe-assume-no-moving-gc这个包的canonical import path是go4.org/unsafe/assume-no-moving-gc，显然它是go4.org这个组织开源的包。我们看看go4.org的主页(如下图)：

这个站点主页非常“简陋”，最大的价值在于解释了go4的来历：gopher的谐音。go4.org开源了一些Go包，这个在其官方github站点可以看到：

项目不多，Star数也不多，但随便翻看一个项目的contributor，我们能看到前Googler、前Go核心团队成员、net/http包的设计者Brad Fitzpatrick(bradfitz)以及Go runtime的核心贡献者Josh Bleecher Snyder(josharian)。现在这两人似乎都在初创公司tailscale任职，做基于wireguard协议的远程安全控制平台(简单理解就是VPN平台)。tailscale汇集了一撮Go语言的原核心开发，go4.org就是他们开源的一些misc go包。而unsafe-assume-no-moving-gc这个包就是其中之一。

那么这个包究竟是做什么的呢？我们接着往下看。

3. unsafe-assume-no-moving-gc的工作原理

unsafe-assume-no-moving-gc是一个非常简单的包：

$tree unsafe-assume-no-moving-gc -F
unsafe-assume-no-moving-gc
├── LICENSE
├── README.md
├── assume-no-moving-gc.go
├── assume-no-moving-gc_test.go
├── go.mod
└── untested.go

0 directories, 6 files

除了test源文件外，它的源文件只有两个assume-no-moving-gc.go和untested.go。打开这两个源文件，你会发现这个包甚至都没有提供任何API。那这个包究竟是做什么用的呢？下面是这个包的README：

大致的理解就是如果你的代码中使用了Go中的unsafe tip，那么你的程序可以正常工作的前提是Go运行时垃圾回收器不是一个带迁移机制的回收器(collector)。

所谓带迁移机制的collector，即在GC回收时可能将某些heap object挪到其他内存地址上。你的程序如果导入unsafe-assume-no-moving-gc这个包，就可以在Go GC支持迁移机制时以“程序启动崩溃”的行为提醒你。

我们来看一个例子：

// main.go
package main

import (
    "fmt"

    _ "go4.org/unsafe/assume-no-moving-gc"
)

func main() {
    fmt.Println("unsafe-assume-no-moving-gc demo")
}

go mod tidy后，使用Go 1.20版本运行该源文件：

$go mod tidy
go: finding module for package go4.org/unsafe/assume-no-moving-gc
go: downloading go4.org/unsafe/assume-no-moving-gc v0.0.0-20230221090011-e4bae7ad2296
go: downloading go4.org v0.0.0-20230225012048-214862532bf5

$go run main.go
unsafe-assume-no-moving-gc demo

由于目前最新Go 1.20.x版本的GC并非带迁移机制的GC，因此使用Go 1.20跑上面程序不会导致panic。

我们将unsafe-assume-no-moving-gc包回退到以前的版本，比如：v0.0.0-20230221090011-e4bae7ad2296，然后再run一遍main.go：

$go get go4.org/unsafe/assume-no-moving-gc@v0.0.0-20201222180813-1025295fd063
go: downgraded go4.org/unsafe/assume-no-moving-gc v0.0.0-20230221090011-e4bae7ad2296 => v0.0.0-20201222180813-1025295fd063

$go run main.go
panic: Something in this program imports go4.org/unsafe/assume-no-moving-gc to declare that it assumes a non-moving garbage collector, but your version of go4.org/unsafe/assume-no-moving-gc hasn't been updated to assert that it's safe against the go1.20 runtime. If you want to risk it, run with environment variable ASSUME_NO_MOVING_GC_UNSAFE_RISK_IT_WITH=go1.20 set. Notably, if go1.20 adds a moving garbage collector, this program is unsafe to use.

goroutine 1 [running]:
go4.org/unsafe/assume-no-moving-gc.init.0()
    /Users/tonybai/Go/pkg/mod/go4.org/unsafe/assume-no-moving-gc@v0.0.0-20201222180813-1025295fd063/untested.go:24 +0x1ba
exit status 2

从输出的panic error信息中，我们看到go4.org/unsafe/assume-no-moving-gc尚未被升级到可以信任go 1.20版本的版本，因此以Go 1.20运行该程序可能有风险。如果你能确认不会存在问题，可以用ASSUME_NO_MOVING_GC_UNSAFE_RISK_IT_WITH=go1.20这个环境变量来避免panic，比如下面这个输出：

$ASSUME_NO_MOVING_GC_UNSAFE_RISK_IT_WITH=go1.20 go run main.go
unsafe-assume-no-moving-gc demo

那么unsafe-assume-no-moving-gc包是怎么做到上述“检测”的呢？其诀窍就在untested.go这个源文件中。我们下载go4.org/unsafe/assume-no-moving-gc源码，并将其“回退”到1025295fd063这个commit时刻：

$git checkout 1025295fd063
Note: checking out '1025295fd063'.

... ...

HEAD is now at 1025295 flesh out package doc

查看untested.go：

// Copyright 2020 Brad Fitzpatrick. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.

// +build go1.18

package assume_no_moving_gc

import (
    "os"
    "runtime"
    "strings"
)

func init() {
    dots := strings.SplitN(runtime.Version(), ".", 3)
    v := runtime.Version()
    if len(dots) >= 2 {
        v = dots[0] + "." + dots[1]
    }
    if os.Getenv(env) == v {
        return
    }
    panic("Something in this program imports go4.org/unsafe/assume-no-moving-gc to declare that it assumes a non-moving garbage collector, but your version of go4.org/unsafe/assume-no-moving-gc hasn't been updated to assert that it's safe against the " + v + " runtime. If you want to risk it, run with environment variable " + env + "=" + v + " set. Notably, if " + v + " adds a moving garbage collector, this program is unsafe to use.")
}

这个文件有两个特点：

• 使用了build constraint：// +build go1.18，这意味着在你使用Go 1.18及更高版本时，该源文件才会参与编译。
• 包含了init函数，你的代码在导入assume_no_moving_gc包时，该init函数会执行，产生“副作用”。

注：关于build constraint的用法，参见go help buildconstraint。

这样，我们使用go 1.20版本运行上面main.go时，由于go 1.20版本大于go 1.18版本，untested.go将被编译且其中的init函数将被执行，如果env这个常量(“ASSUME_NO_MOVING_GC_UNSAFE_RISK_IT_WITH”)所对应的环境变量没有设置，那么init函数将走到panic，从而导致程序退出并输出panic信息。

现在我们将assume_no_moving_gc包的版本切换回最新版本，最新版本的untested.go中的build constraint如下：

  //go:build go1.21
  // +build go1.21

这意味着你使用Go 1.21或以上版本时，untested.go文件才会被编译，如果我们使用go 1.20版本运行main.go，我们便不会“触发”untested.go中init函数的副作用，于是main.go得以正常运行。

注：截至go 1.20版本，Go GC依然不会挪动heap object。

在理解unsafe-assume-no-moving-gc包之前，我就该包的功用“咨询”了ChatGPT，ChatGPT的回答如下：

可以看出，ChatGPT基本上是一本正经地“胡说八道”。

4. 小结

unsafe-assume-no-moving-gc只针对GC对heap object的迁移，而不会保证栈地址的迁移，我们知道，Go中栈地址是会变的，因为goroutine的初始栈才2KB，一旦超出这个范围，Go runtime就会对栈进行扩展，即分配一个更大的地址范围作为goroutine的栈，然后将原栈上的变量迁移到新栈中，这样原先栈上变量的地址就都会发生变化。

不过，如果你的Go源码中采用了unsafe tips，依赖了heap object的地址，那么这里建议你导入unsafe-assume-no-moving-gc包。但要注意，随着go最新版本的发布，你要及时更新依赖的unsafe-assume-no-moving-gc的版本。否则当用户使用最新版本go时，依赖你的包的程序就会以panic来提醒。

“Gopher部落”知识星球旨在打造一个精品Go学习和进阶社群！高品质首发Go技术文章，“三天”首发阅读权，每年两期Go语言发展现状分析，每天提前1小时阅读到新鲜的Gopher日报，网课、技术专栏、图书内容前瞻，六小时内必答保证等满足你关于Go语言生态的所有需求！2023年，Gopher部落将进一步聚焦于如何编写雅、地道、可读、可测试的Go代码，关注代码质量并深入理解Go核心技术，并继续加强与星友的互动。欢迎大家加入！

著名云主机服务厂商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
• 微博2：https://weibo.com/u/6484441286
• 博客：tonybai.com
• github: https://github.com/bigwhite

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