将多个小对象合并成一个大的对象

减少不必要的指针间接引用，多使用copy引用

例如使用bytes.Buffer代替*bytes.Buffer`，因为使用指针时，会分配2个对象来完成引用。

局部变量逃逸时，将其聚合起来

这一点理论跟1相同，核心在于减少object的分配，减少gc的压力。 例如，以下代码

1
2
3
4
5
6

for k, v := range m {
	k, v := k, v   // copy for capturing by the goroutine
	go func() {
		// use k and v
	}()
}

可以修改为:

1
2
3
4
5
6

for k, v := range m {
	x := struct{ k, v string }{k, v}   // copy for capturing by the goroutine
	go func() {
		// use x.k and x.v
	}()
}

修改后，逃逸的对象变为了x，将k，v2个对象减少为1个对象。

[]byte的预分配

当我们比较清楚的知道[]byte会到底使用多少字节，我们就可以采用一个数组来预分配这段内存。 例如:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

type X struct {
    buf      []byte
    bufArray [16]byte // Buf usually does not grow beyond 16 bytes.
}

func MakeX() *X {
    x := &X{}
    // Preinitialize buf with the backing array.
    x.buf = x.bufArray[:0]
    return x
}

尽可能使用字节数少的类型

当我们的一些const或者计数字段不需要太大的字节数时，我们通常可以将其声明为int8类型。

减少不必要的指针引用

当一个对象不包含任何指针（注意：strings，slices，maps 和chans包含隐含的指针），时，对gc的扫描影响很小。 比如，1GB byte 的slice事实上只包含有限的几个object，不会影响垃圾收集时间。 因此，我们可以尽可能的减少指针的引用。

使用sync.Pool来缓存常用的对象

注意

go1.9、go1.9.2之间的版本go tool pprof引入了一个BUG，会导致上面的内存分析命令失败。 下面给出一种修复办法：

1
2
3
4
5
6
7

cd $GOROOT/src/cmd/vendor/github.com/google
rm pprof
git clone <https://github.com/google/pprof.git> #确保在版本`e82ee9addc1b6c8e1d667ed6de0194241e1e03b5`之后
rm $GOROOT/pkg/darwin_amd64/cmd/vendor/github.com/google/pprof
cd $GOROOT/src/cmd/pprof
go build
mv pprof $GOROOT/pkg/tool/darwin_amd64/pprof

减少分配

确保你的 APIs 不会给调用方增加垃圾。

考虑这两个 Read 方法

1
2

func (r *Reader) Read() ([]byte, error)
func (r *Reader) Read(buf []byte) (int, error)

第一个 Read 方法不带参数，并将一些数据作为[]byte返回。 第二个采用[]byte缓冲区并返回读取的字节数。

第一个 Read 方法总是会分配一个缓冲区，这会给 GC 带来压力。 第二个填充传入的缓冲区。

strings vs []bytes

Go 语言中 string 是不可改变的，而 []byte 是可变的。

大多数程序喜欢使用 string，而大多数 IO 操作更喜欢使用 []byte。

尽可能避免 []byte 到 string 的转换，对于一个值来说，最好选定一种表示方式，要么是[]byte，要么是string。 通常情况下，如果你从网络或磁盘读取数据，将使用[]byte 表示。

[bytes][2] 包也有一些和 [strings][3] 包相同的操作函数—— Split， Compare， HasPrefix， Trim等。

实际上， strings 使用和 bytes 包相同的汇编原语。

使用 []byte 当做 map 的 key

使用 string 作为 map 的 key 是很常见的，但有时你拿到的是一个 []byte。

编译器为这种情况实现特定的优化：

1
2

var m map[string]string
v, ok := m[string(bytes)]

如上面这样写，编译器会避免将字节切片转换为字符串到 map 中查找，这是非常特定的细节，如果你像下面这样写，这个优化就会失效：

1
2

key := string(bytes)
val, ok := m[key]

优化字符串连接操作

Go 的字符串是不可变的。连接两个字符串就会生成第三个字符串。下面哪种写法是最快的呢？

1
2
3
4

s := request.ID
s += " " + client.Addr().String()
s += " " + time.Now().String()
r = s

1
2
3

var b bytes.Buffer
fmt.Fprintf(&b, "%s %v %v", request.ID, client.Addr(), time.Now())
r = b.String()

1

r = fmt.Sprintf("%s %v %v", request.ID, client.Addr(), time.Now())

1
2
3
4
5
6
7

b := make([]byte, 0, 40)
b = append(b, request.ID...)
b = append(b, ' ')
b = append(b, client.Addr().String()...)
b = append(b, ' ')
b = time.Now().AppendFormat(b, "2006-01-02 15:04:05.999999999 -0700 MST")
r = string(b)

1

% go test -bench=. ./examples/concat/

我的测试结果：

  • go 1.10.3
1
2
3
4
5
6
7
8

goos: darwin
goarch: amd64
pkg: test/benchmark
BenchmarkConcatenate-8           2000000               873 ns/op         272 B/op         10 allocs/op
BenchmarkFprintf-8               1000000              1509 ns/op         496 B/op         13 allocs/op
BenchmarkSprintf-8               1000000              1316 ns/op         304 B/op         11 allocs/op
BenchmarkStrconv-8               2000000               620 ns/op         165 B/op          5 allocs/op
PASS
  • go 1.11
1
2
3
4
5
6
7
8

goos: darwin
goarch: amd64
pkg: test/benchmark
BenchmarkConcatenate-8   	 1000000	      1027 ns/op	     271 B/op	      10 allocs/op
BenchmarkFprintf-8       	 1000000	      1707 ns/op	     496 B/op	      12 allocs/op
BenchmarkSprintf-8       	 1000000	      1412 ns/op	     304 B/op	      11 allocs/op
BenchmarkStrconv-8       	 2000000	       707 ns/op	     165 B/op	       5 allocs/op
PASS

所有的基准测试在1.11版本下都变慢了？

已知长度时，切片一次分配好

Append 操作虽然方便，但是有代价。

切片的增长在元素到达 1024 个之前一直是两倍左右地变化，在到达 1024 个之后之后大约是 25% 地增长。在我们 append 之后的容量是多少呢？

1
2
3
4
5
6
7
8
9

func main() {
        b := make([]int, 1024)
    	fmt.Println("len:", len(b), "cap:", cap(b))
        b = append(b, 99)
        fmt.Println("len:", len(b), "cap:", cap(b))
}
output:
len: 1024 cap: 1024
len: 1025 cap: 1280

如果你使用 append，你可能会复制大量数据并产生大量垃圾。

因此，我们在使用append操作的时候，最好是设置一个比较合理的cap值，即根据自己的应用场景预申请大小合适的空间，避免无谓的不断重新申请新空间，这样可以减少GC的压力。

由append导致的内存飙升和GC压力过大这个问题，需要特别注意一下。

如果事先知道片的长度，最好预先分配大小以避免复制，并确保目标的大小完全正确。

Before:

1
2
3
4
5

var s []string
for _, v := range fn() {
        s = append(s, v)
}
return s

After:

1
2
3
4
5
6

vals := fn()
s := make([]string, len(vals))
for i, v := range vals {
        s[i] = v
}
return s

Goroutines

使 Go 非常适合现代硬件的关键特性是 goroutines。goroutine 很容易使用，成本也很低，你可以认为它们几乎是没有成本的。

Go 运行时是为运行数以万计的 goroutines 所设计的，即使有上十万也在意料之中。

但是，每个 goroutine 确实消耗了 goroutine 栈的最小内存量，目前至少为 2k。

2048 * 1,000,000 goroutines == 2GB 内存，什么都不干的情况下。

这也许算多，也许不算多，同时取决于机器上其他耗费内存的应用。

要了解 goroutine 什么时候退出

虽然 goroutine 的启动和运行成本都很低，但它们的内存占用是有限的；你不可能创建无限数量的 goroutine。

每次在程序中使用go关键字启动 goroutine 时，你都必须知道这个 goroutine 将如何退出，以及何时退出。

如果你不知道，那这就是潜在的内存泄漏。

在你的设计中，一些 goroutine 可能会一直运行到程序退出。这样的 goroutine 不应该太多

永远不要在不知道该什么时候停止它的情况下启动一个 goroutine

实现此目的的一个好方法是利用如 [run.Group][4]， [workgroup.Group][5] 这类的东西。

Peter Bourgon has a great presentation on the design behing run.Group from GopherCon EU

Go 对一些请求使用高效的网络轮询

Go 运行时使用高效的操作系统轮询机制（kqueue，epoll，windows IOCP等）处理网络IO。 许多等待的 goroutine 将由一个操作系统线程提供服务。

但是，对于本地文件IO（channel 除外），Go 不实现任何 IO 轮询。每一个*os.File在运行时都消耗一个操作系统线程。

大量使用本地文件IO会导致程序产生数百或数千个线程；这可能会超过操作系统的最大值限制。

您的磁盘子系统可能处理不数百或数千个并发IO请求。

注意程序中的 IO 复杂度

如果你写的是服务端程序，那么其主要工作是复用网络连接客户端和存储在应用程序中的数据。

大多数服务端程序都是接受请求，进行一些处理，然后返回结果。这听起来很简单，但有的时候，这样做会让客户端在服务器上消耗大量（可能无限制）的资源。下面有一些注意事项：

  • 每个请求的IO操作数量；单个客户端请求生成多少个IO事件？ 如果使用缓存，则它可能平均为1，或者可能小于1。
  • 服务查询所需的读取量；它是固定的？N + 1的？还是线性的（读取整个表格以生成结果的最后一页）？

如果内存都不算快，那么相对来说，IO操作就太慢了，你应该不惜一切代价避免这样做。 最重要的是避免在请求的上下文中执行IO——不要让用户等待磁盘子系统写入磁盘，甚至连读取都不要做。

使用流式 IO 接口

尽可能避免将数据读入[]byte 并传递使用它。

根据请求的不同，你最终可能会将兆字节（或更多）的数据读入内存。这会给GC带来巨大的压力，并且会增加应用程序的平均延迟。

作为替代，最好使用io.Reader和io.Writer构建数据处理流，以限制每个请求使用的内存量。

如果你使用了大量的io.Copy，那么为了提高效率，请考虑实现io.ReaderFrom / io.WriterTo。 这些接口效率更高，并避免将内存复制到临时缓冲区。

超时，超时，还是超时

永远不要在不知道需要多长时间才能完成的情况下执行 IO 操作。

你要在使用SetDeadline，SetReadDeadline，SetWriteDeadline进行的每个网络请求上设置超时。

您要限制所使用的阻塞IO的数量。 使用 goroutine 池或带缓冲的 channel 作为信号量。

1
2
3
4
5
6
7

var semaphore = make(chan struct{}, 10)

func processRequest(work *Work) {
        semaphore <- struct{}{} // 持有信号量
        // 执行请求
        <-semaphore // 释放信号量
}

Defer 操作成本如何？

defer 是有成本的，因为它必须为其执行参数构造一个闭包去执行。

1

defer mu.Unlock()

相当于

1
2
3

defer func() {
	mu.Unlock()
}()

如果你用它干的事情很少，defer 的成本就会显得比较高。一个经典的例子是使用defer对 struct 或 map 进行mutex unlock 操作。 你可以在这些情况下避免使用defer

当然，这是为了提高性能而牺牲可读性和维护性的情况。

避免使用 Finalizers

终结器是一种将行为附加到即将被垃圾收集的对象的技术。

因此，终结器是非确定性的。

要运行 Finalizers，要保证任何东西都不会访问该对象。 如果你不小心在 map 中保留了对象的引用，则 Finalizers 无法执行。

Finalizers 作为 gc 的一部分运行，这意味着它们在运行时是不可预测的，并且它会与_减少 gc 时间_的目标相悖。

当你有一个非常大的堆块，并且已经优化过你的程序使之减少生成垃圾，Finalizers 可能才会很快结束。

最小化 cgo

cgo 允许 Go 程序调用 C 语言库。

C 代码和 Go 代码存在于两个不同的世界中，cgo 用来转换它们。

这种转换不是没有代价的，主要取决于它在代码中的位置，有时成本可能很高。

cgo 调用类似于阻塞IO，它们在操作期间消耗一个系统线程。

不要在一个 [tight loop][7] 中调用 C 代码。

实际上，避免使用 cgo

cgo 的开销很高。

为了获得最佳性能，我建议你在应用中避免使用cgo。

  • 如果C代码需要很长时间，那么 cgo 本身的开销就不那么重要了。
  • 如果你使用 cgo 来调用非常短的C函数，那么cgo本身的开销就会显得非常突出，那么最好的办法是在 Go 中重写该代码。（因为很短，重写也没什么成本。
  • 如果你就是要使用大量高开销成本的C代码在 tight loop 中调用，为什么使用 Go？（直接用 C 写就好了被。

始终使用最新版发布的 Go 版本

Go 的旧版本永远不会变得更好。他们永远不会得到错误修复或优化。

  • Go 1.4 不应该再使用。
  • Go 1.5 和 1.6 编译器的速度更慢，但它产生更快的代码，并具有更快的 GC。
  • Go 1.7 的编译速度比 1.6 提高了大约 30％，链接速度提高了2倍（优于之前的Go版本）。
  • Go 1.8 在编译速度方面带来较小的改进，且在非Intel体系结构的代码质量方面有显著的改进。
  • Go 1.9，1.10，1.11 继续降低 GC 暂停时间并提高生成代码的质量。

Go 的旧版本不会有任何更新。 不要使用它们。 使用最新版本，你将获得最佳性能。

慎重使用自动化的DeepCopy

自动化的 DeepCopy 是非常耗时的，其中涉及到反射，内存分配，容器(如 map)扩展等，大概比手动拷贝慢一个数量级

原子操作

用 atomic.Load/StoreXXX，atomic.Value, sync.Map 等代替 Mutex。(优先级递减)

竞态检查

在开发环境加上-race编译选项进行竞态检查

pprof

在开发环境开启 net/http/pprof，方便实时 pprof

参考

https://lrita.github.io/2017/05/26/golang-memory-pprof/ https://raw.githubusercontent.com/sxs2473/go-performane-tuning/master/5.%E6%8A%80%E5%B7%A7/%E6%8A%80%E5%B7%A7.md https://juejin.im/entry/5ac9cf3a518825556534c76e