【Go高质量编程与性能调优】高质量编程-性能优化建议-性能分析工具pprof | 青训营笔记这部分笔记的内容包括Go的高

这是我参与「第五届青训营」伴学笔记创作活动的第 4 天，今天学习的内容是Go的高质量编程、性能优化建议以及性能优化工具pprof的使用与分析，整理学习笔记如下。

4 高质量编程与性能调优实战

4.1 高质量编程简介与编码规范

4.1.1 高质量编程简介

核心要求：正确可靠、简洁清晰

编程原则：

简单性

消除“多余的复杂性”，以简单清晰的逻辑编写代码
不理解的代码无法修复改进

可读性

代码是写给人看的，而不是机器
编写可维护代码的第一步是确保代码可读

生产力

团队整体工作效率非常重要

4.1.2 编码规范

1. 代码格式工具

gofmt

Go语言官方提供的工作，能自动格式化Go语言代码为官方统一风格（常见IDE支持配置）

goimports

也是Go语言的官方推荐的工具，实际等于gofmt加上依赖包管理，自动增删依赖的包引用、将依赖包按字母顺序排序并分类。

VSCode中的代码格式化工具配置（Go插件设置 - Gormat Tool）

2. 注释

简介 - 注释应该做的

解释代码作用 - 注释公共符号
解释代码如何做的 - 注释实现过程
解释代码实现的原因 - 解释代码的外部因素、提供额外的上下文
解释代码什么情况会出错 - 解释代码的限制条件

注释 - 公共符号始终要注释

包中声明的每个公共的符号：变量、常量、函数以及结构都需要添加注释
任何既不明显也不简短的公共功能必须予以注释
无论长度或复杂程度如何，对库中的任何函数都必须进行注释

3. 命名规范

variable

简洁胜于冗长
缩略词全大写，但当其位于变量开头且无需导出时使用全小写
变量距离其被使用的地方越远，则需要携带更多的上下文信息（特别是全局变量）

function

函数名不携带包名的上下文信息，因为其总是成对出现
函数名尽量简短
当名为foo的包某个函数返回类型Foo时，可以省略类型信息而不导致歧义
当名为foo的包某个函数返回类型T时（T不为Foo），可以在函数名中加入类型信息

package

只由小写字母组成。不包含大写字母和下划线等字符
简短并包含一定的上下文信息
不要与标准库同名

尽量满足：

不使用常用变量名作为包名
使用单数而不是复数
谨慎使用缩写

4. 控制流程

避免嵌套，保持正常流程清晰
尽量保持正常代码路径为最小缩进（优先处理错误/特殊情况，尽早返回或继续循环来减少嵌套）

5. 错误和异常处理

Tips：

简单错误

简单的错误指的是仅出现一次的错误，在其他地方不需要捕获该错误
优先使用 errors.New 来创建匿名变量来直接表示简单错误

如果有格式化需求，使用 fmt.Errorf

错误的Wrap和Unwrap

错误的Wrap实际上是提供了一个error嵌套另一个error的能力，从而生成一个error跟踪链
在fmt.Error 中使用： %w 关键字来将一个错误关联至错误链中

错误判断

在错误链上获取特定种类的错误，使用 error.As

panic

不建议在业务代码中使用panic
调用函数不包含recover会造成程序崩溃
若问题可以被屏蔽或解决，建议使用error代替panic
当程序启动阶段发生不可逆转的错误时，可以在 init 或 main 函数中使用panic

recover

recover只能在被defer的函数中使用
嵌套无法生效
只在当前gotoutine生效
defer的语句时后进先出

如果需要更多的上下文信息，可以recover后再log中记录当前的调用栈

4.2 性能优化建议

性能优化的前提是满足正确可靠、简洁清晰等质量因素
性能优化是综合评估，有时候时间效率和空间效率可能对立
针对Go语言特性，介绍Go相关的性能优化建议

示例代码：go-practice

由于我们开了go mod，因此需要在根目录初始化一个 go.mod 文件

go mod init go-practice
go mod tidy

4.2.1 Benchmark测试工具

Go语言提供的支持基准性能测试的benchmark工具

使用方法：

在对应的benchmark目录 /start/，运行

go test -benchmem -run=^$ -bench ^BenchmarkFib10$ go-practice/start

结果说明：

其中PASS上一行为测试结果，分别指的是

测试函数名+ GOMAXPROCS 值（默认值与cpu核相同）
总共执行次数，即 b.N 的值
每次执行花费的时间
每次申请的内存大小
每次执行访问内存的次数

4.2.2 性能优化建议 - Slice

1. Slice预分配内存

尽可能在使用 make() 初始化切片时提供容量信息

**测试对比：**预分配内存每次执行只需访问1次内存，而未进行预分配则需8次

切片本质是一个数组片段的描述原理
- 数组指针
- 片段的长度
- 片段的容量（不改变内存分配情况下的最大长度）

切片操作并不复制切片指向的元素
创建一个新的切片会复用原来切片的底层数组
切片有三个属性，指针(ptr)、长度(len) 和容量(cap)。append 时有两种场景：
- 当 append 之后的长度小于等于 cap，将会直接利用原底层数组剩余的空间
- 当 append 后的长度大于 cap 时，则会分配一块更大的区域来容纳新的底层数组

因此，为了避免内存发生拷贝，如果能够知道最终的切片的大小，预先设置 cap 的值能够获得最好的性能。

2. 另一个陷阱：大内存未释放

在已有切片基础上创建切片，不会创建新的底层数组。因为原来的底层数组没有发生变化，内存会一直占用，直到没有变量引用该数组。
陷阱场景： 原切片由大量元素构成，代码在原切片基础上新建小切片，虽然只使用了很小一段，但底层数组在内存中仍然占据了大量空间，得不到释放。
推荐的做法：使用 copy 替代 re-slice

示例测试：

可直接运行测试两个测试函数或用以下命令

go test -run=. -v

测试结果：

对比发现，由于Slice创建一个新的切片会复用原来切片的底层数组的特性，因此当我们创建新切片与直接截取原切片对比，在内存上消耗较小。

4.2.3 性能优化建议 - Map

1. map预分配内存

不断向map中添加元素的操作会触发map的扩容
提前分配好空间可以减少内存拷贝和Rehash的消耗
建议根据实际需求提前预估好需要的空间

4.2.4 性能优化建议 - 字符串处理

1. 使用strings.Builder

三种字符串拼接对比

+
strings.Builder
bytes.Buffer

结果（ strings.Builder 最快，bytes.Buffer 较快，+ 最慢）

原理分析

字符串在Go语言中是不可变类型，占用内存大小是固定的
使用 + 每次都会重新分配内存（当使用 + 拼接 2 个字符串时，生成一个新的字符串，那么就需要开辟一段新的空间，新空间的大小是原来两个字符串的大小之和）
strings.Builder ，bytes.Buffer 的内存是以倍数申请的
strings.Builder, bytes.Buffer 底层都是 []byte 数组， bytes.Buffer 转化为字符串时重新申请了一块空间，存放生成的字符串变量，而 strings.Builder 直接将底层的 []byte 转换成了字符串类型返回
由于其内容扩容策略，不需要每次拼接重新分配内存

2. 预分配内存

使用以上两种字符串处理方法也可以提前预分配内存

结果如下，提前分配内存可以减少访存的次数

4.2.5 性能优化建议 - 空结构体

使用空结构体节省内存

空结构体 struct{} 实例不占据任何的内存空间
可作为各种场景下的占位符使用
- 节省资源
- 空结构体本身具备很强的语义，即这里不需要任何值，仅作为占位符

实例：

比如实现简单的 Set

Go 语言标准库没有提供 Set 的实现，通常使用 map 来代替。对于集合场景，只需要用到 map 的键而不需要值

4.2.6 性能优化建议 - atomic包

锁的实现是通过操作系统来实现，属于系统调用；atomic操作时通过硬件实现，效率较高
sync.Mutex 应该用来保护一段逻辑，不仅仅用于保护一个变量
对于非数值操作，可以使用 atomic.Value ，能承载一个 interface{}

原子操作&加锁对比示例

4.3 性能调优简介

性能调优原则

要依靠数据而不是猜测
要定位最大瓶颈而不是细枝末节
不要过早优化
不要过度优化

4.4 性能分析工具 pprof

性能调优的核心是性能瓶颈的分析，对于 Go 应用程序，最方便的就是 pprof 工具

4.4.1 pprof 功能简介

pprof 是用于可视化和分析性能分析数据的工具
可以知道应用在什么地方耗费了多少 CPU、memory 等运行指标

4.4.2 pprof 排查实战

0. 前置准备

克隆项目，阅读文档

相关材料：项目 - go-pprof-practice，文档 - golang pprof 实战

1. 编译运行项目

进入 /go-pprof-practice/ 文件夹根目录，编译运行项目

go build
./go-pprof-practice

2. 使用pprof

保持程序运行，打开浏览器访问

http://localhost:6060/debug/pprof/

可以看到成功打开

页面上展示了可用的程序运行采样数据，分别有：

类型	描述	备注
allocs	内存分配情况的采样信息	可以用浏览器打开，但可读性不高
blocks	阻塞操作情况的采样信息	可以用浏览器打开，但可读性不高
cmdline	显示程序启动命令及参数	可以用浏览器打开，这里会显示 `./go-pprof-practice`
goroutine	当前所有协程的堆栈信息	可以用浏览器打开，但可读性不高
heap	堆上内存使用情况的采样信息	可以用浏览器打开，但可读性不高
mutex	锁争用情况的采样信息	可以用浏览器打开，但可读性不高
profile	CPU 占用情况的采样信息	浏览器打开会下载文件
threadcreate	系统线程创建情况的采样信息	可以用浏览器打开，但可读性不高
trace	程序运行跟踪信息	浏览器打开会下载文件，本文不涉及，可另行参阅《深入浅出 Go trace》

3. 排查 CPU 问题

通过命令行输入以下命令，保存10s的数据情况，并进入pprof界面，用于后续分析

go tool pprof "http://localhost:6060/debug/pprof/profile?seconds=10"

top 命令

**作用：**查看占用资源最多的函数
- flat ：当前函数本身的执行耗时
- flat% ：flat 占CPU总时间的比例
- sum% ：上面每一行的 flat% 总和
- cum ：指当前函数本身加上其调用函数的总耗时
- cum% ：cum 占CPU总时间的比例

list 命令

**作用：**根据指定的正则表达式查找代码行

可以看到，定位到了当前消耗时间的的无效for循环

web 命令

作用： 调用关系可视化，生成一个 .svg 文件

Tips： 需要安装 graphviz，否则会出现报错

安装教程，安装过程如下：

下载并安装 Graphviz 安装时可以直接选择添加到环境变量测试安装
```
dot -version
```

出现以上信息则安装成功

py中安装 graphviz

命令如下
```
pip install graphviz
```

CPU问题处理

我们注释掉对应的该无效循环语句，重新编译运行

可以看到CPU的占用已经从原来的十几下降到几乎可以忽略不计了，但内存占用依然过高，继续排查

3. 排查 heap堆内存问题

通过命令行输入以下命令，保存10s的数据情况，通过 -http=:8080 进入pprof图形化界面，与之前的命令行方法相同，用于后续分析

go tool pprof -http=:8080 "http://localhost:6060/debug/pprof/heap"

会打开页面，并分析当前占用内存的信息

选择 VIEW-Source ，可以看到当前占用较多内存的问题

但该问题只是程序当前占用内存大小的问题，其他仍然可能存在问题

我们选择页面的 SAMPLE ，其中有四个不同选项

alloc_objects：程序累计申请的对象数
alloc_space：程序累计申请的内存大小
inuse_objects：程序当前持有的对象数
inuse_space：程序当前占用的内存大小

选择 SAMPLE-alloc_space

可以看到在 Dog 中还有一个重复进行申请与释放内存的操作

Heap堆内存问题处理

我们注释掉两个部分对应的该语句，重新编译运行

可以看到当前程序的内存以及CPU占用已经恢复正常

4. 排查 goroutine协程问题

goroutine泄露也会导致内存泄露

当前存在较多goroutine，我们运行命令进行排查

go tool pprof -http=:8080 "http://localhost:6060/debug/pprof/goroutine"

对于该比较长的图，我们可以选择 VIEW-Flame Graph 火焰图直观展示

可以看到当前 wolf.Drink 创建了超过90%的协程，可能存在问题

Tips：Flame Graph火焰图

从上到下表示调用顺序
每一块代表一个函数，越长代表占用CPU时间更长
火焰图是动态的，支持点击块进行分析

打开源代码，可以看到其每次创建协程，等待30s并无操作退出

goroutine协程问题处理

我们注释掉该部分对应的语句，重新编译运行

可以看到当前的协程数恢复正常

5. 排查 mutex锁问题

我们运行命令进行排查锁问题

go tool pprof -http=:8080 "http://localhost:6060/debug/pprof/mutex"

mutex锁问题处理

可以看到当前代码在锁停了较长时间，我们注释掉该部分对应的语句，重新编译运行，解决问题

6. 排查 block阻塞问题

查看当亲仍存在block阻塞问题

我们运行命令进行排查阻塞问题

go tool pprof -http=:8080 "http://localhost:6060/debug/pprof/block"

block阻塞问题处理

可以看到当前代码在该处阻塞了较长时间，我们注释掉该部分对应的语句，重新编译运行，解决问题

4.4.3 pprof 采样过程和原理

CPU 采样
- 采样对象：函数调用和它们占用的时间
- 采样率：100次/s，固定值
- 采样时间：从手动启动到手动结束

详细过程

堆内存采样
- 采样程序通过内存分配器在堆上分配和释放的内存，记录分配/释放的大小和数量
- 采样率：每分配512KB记录一次，可在运行开头修改，1为每次分配均记录
- 采样时间：从程序运行开始到采样时
- 采样指标：allooc_space, alloc_objects, inuse_space, inuse_objects
- 计算方式：inuse = alloc - free
Goroutine协程和ThreadCreate系统线程采样
- Goroutine：记录所有用户发起且在运行中的goroutine（即入口非 runtime 开头的 runtime.main 的调用栈信息）
- ThreadCreate：记录程序创建的所有系统线程的信息
Block阻塞操作和Mutex锁竞争采样
- 阻塞操作：采样阻塞操作的次数和耗时；阻塞耗时超过阈值的才会被记录，1为每次阻塞均记录
- 锁竞争：采样争抢锁的次数和耗时；只记录固定比例的锁操作，1为每次加锁均记录