高质量编程及性能调优实战｜ 青训营笔记

用户2228395396735
63 阅读11分钟

这是我参与「第五届青训营 」伴学笔记创作活动的第 3 天

一、本堂课重点内容

  • 介绍编码规范，帮助大家写出高质量程序

  • 介绍 Go 语言的性能优化建议，分析对比不同方式对性能的影响和背后的原理

  • 讲解常用性能分析工具 pprof 的使用和工作原理，熟悉排查程序性能问题的基本流程

  • 分析性能调优实际案例，介绍实际性能调优时的工作内容

二、详细知识点介绍

01. 高质量编程

1.1 简介

[!question] 什么是高质量？高质量编程需要满足哪些条件？

正确性： 是否考虑各种边界条件，错误的调用是否能够处理 可靠性： 异常情况或者错误的处理策略是否明确，依赖的服务出现异常是否能够处理 简洁： 逻辑是否简单，后续调整功能或新增功能是否能够快速支持 清晰： 其他人在阅读理解代码的时候是否能清楚明白，重构或者修改功能是否不会担心出现无法预料的问题

[!question] 高质量编程的编程原则有哪些？

  1. 简单性 消除”多余的复杂性”，以简单清晰的逻辑编写代码。 在实际工程项目中，复杂的程序逻辑会让人害怕重构和优化，因为无法明确预知调整造成的影响范围。难以理解的逻辑，排查问题时也难以定位，不知道如何修复。
  2. 可读性 可读性很重要，因为代码是写给人看的，而不是机器。在项目不断迭代的过程中，大部分工作是对已有功能的完善或扩展，很少会完全下线某个功能，对应的功能代码实际会生存很长时间。
  3. 生产力 编程在当前更多是团队合作，因此团队整体的工作效率是非常重要的一方面。为了降低新成员上手项目代码的成本，Go语言甚至通过工具强制统一所有代码格式。编码在整个项目开发链路中的一个节点，遵循规范，避免常见缺陷的代码能够降低后续联调、测试、验证、上线等各 个节点的出现问题的概率，就算出现问题也能快速排查定位。

1.2 编码规范

如何编写高质量的Go代码？

  • 代码格式
  • 注释
  • 命名规范
  • 控制流程
  • 错误和异常处理

1.2.1 代码格式

首先是推荐使用gofmt自动格式化代码，保证所有的Go代码与官方推荐格式保持一致 而且可以很方便的进行配置，像Goland内置了相关功能，直接开启即可在保存文件的时候自动格式化。

[[202301171307-Go代码格式化之gofmt的使用]]

另外可以考虑goimports，会对依赖包进行管理，自动增删依赖的包引用，按字母序排序分类，具体可以根据团队实际情况配置使用。

1.2.2 注释

注释应该做的：

注释应该解释代码作用
注释应该解释代码如何做的
注释应该解释代码实现的原因
注释应该解释代码什么情况会出错

规范：

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

1.2.3 命名规范

变量

  • 简洁胜于冗长
  • 缩略词全大写，但当其位于变量开头且不需要导出时，使用全小写
    • 例如使用ServeHTTP而不是ServeHttp
    • 使用XMLHTTPRequest或者xmlHTTPRequest
  • 变量距离其被使用的地方越远，则需要携带越多的上下文信息
  • 全局变量在其名字中需要更多的上下文信息，使得在不同地方可以轻易辨认出其含义

函数

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

package

  • 只由小写字母组成。不包含大写字母和下划线等字符
  • 简短并包含一定的上下文信息。例如schema、task 等
  • 不要与标准库同名。例如不要使用sync或者strings

以下规则尽量满足，以标准库包名为例：

  • 不使用常用变量名作为包名。例如使用bufio而不是buf
  • 使用单数而不是复数。例如使用encoding而不是encodings
  • 谨慎地使用缩写。例如使用fmt在不破坏上下文的情况下比format更加简短

1.2.4 控制流程

  1. 避免嵌套
  2. 尽量保持正常代码路径为最小缩进

1.2.5 错误和异常处理

简单错误

  • 简单的错误指的是仅出现1次的错误，且在其他地方不需要捕获该错误
  • 优先使用errors. New来创建匿名变量来直接表示简单错误
  • 如果有格式化的需求，使用fmt Errorf

错误的Wrap和Unwrap

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

错误判定

  • 判定一个错误是否为特定错误，使用errors.Is 不同于使用 == ，使用该方法可以判定错误链上的所有错误是否含有特定的错误

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

panic

它的出现表示程序无法正常工作

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

recover

有painc，自然就会提到recover，因为我们并不能控制所有的代码，避免不了引入其他库，如果是引入库 的bug导致panic，影响到我自身的逻辑该如何处理?

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

小结：

  • error尽可能提供简明的上下文信息链，方便定位问题
  • panic用于真正异常的情况
  • recover生效范围，在当前goroutine的被defer的函数中生效

1.3 性能优化建议

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

1.3.1 Benchmark

Go自带的性能评估工具

// -8：八核 次数（b.N） 每次执行花费ns 每次执行申请内存大小 每次执行申请内存次数
BenchmarkFib10-8 1855870 602.5 ns/op 0 B/op 0 allocs/op

1.3.2 Slice

预分配内存

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

第一条建议就是预分配，尽可能在使用make()初始化切片时提供容量信息，特别是在追加切片时。

首先我们看看slice的结构： 切片本质是一个数组片段的描述， 包括数组指针 片段的长度 片段的容量(不改变内存分配情况下的最大长度)

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

切片操作并不复制切片指向的元素，创建一个新的切片会复用原来切片的底层数组。

以切片的append为例，append时有两种场景: 当append之后的长度小于等于cap，将会直接利用原底层数组剩余的空间。 当append后的长度大于cap时，则会分配一块更大的区域来容纳新的底层数组。 因此，为了避免内存发生拷贝，如果能够知道最终的切片的大小，预先设置cap的值能够避免额外的内存分配，获得更好的性能。

另一个陷阱：大内存未释放 因此很可能出现这么一种情况，原切片由大量的元素构成，但是我们在原切片的基础上切片，虽然只使用了很小一段，但底层数组在内存中仍然占据了大量空间，得不到释放。

  • 可使用copy替代re-slice
func GetLastBySlice(origin []int) []int{
	return origin[len(orgin)-2:]
}

func GetLastCope(origin []int) []int{
	result := make([]int, 2)
	copy(result, origin[len(origin)-2:])
	return result
}

func testGetLast(t *testing.T, f func([]int) []int){
	result := make([][]int, 0)
	for k := 0; k < 100; k++{
		origin := generateWithCap(128*1024)
		result = append(result, f(origin))
	}
	printNem(t)
	_= result
}

两部分代码使用了不同的逻辑取slice的最后两位数创建新数组，同时统计输出了内存占用信息： lastBySlice 耗费了100.14 MB内存，也就是说，申请的100个1 MB大小的内存没有被回收。因为切片虽然只使用了最后2个元素，但是因为与原来1M的切片引用了相同的底层数组，底层数组得不到释放，因此，最终100 MB的内存始终得不到释放。 而lastByCopy仅消耗了3.14MB的内存。 这是因为，通过copy,指向了一个新的底层数组，当origin不再被引用后，内存会被垃圾回收。

1.3.3 Map

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

1.3.4 字符串处理

  • 使用strings.Builder
  • 使用+拼接性能最差，strings Builder, bytes Buffer相近，strings Buffer更快

原因：

  • 字符串在Go语言中是不可变类型，占用内存大小是固定的
  • 使用+每次都会重新分配内存
  • strings. Builder, bytes. Buffer底层都是[]byte数组
  • 内存扩容策略，不需要每次拼接重新分配内存

但是为什么stringbuilder会比bytebuffer更快一些？

  • bytes. Buffer转化为字符串时重新申请了一块空间
  • strings. Builder直接将底层的]byte转换成了字符串类型返回

进一步性能优化的话，就可以使用builder.Grow方法，通过预分配提升性能。

1.3.5 空结构体

使用空结构体节省内存

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

1.3.6 atomic 包

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

02. 性能调优实战

2.1 简介

性能调优原则：

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

2.2 性能分析工具 pprof

希望知道应用在什么地方耗费了多少CPU、Memory pprof是用于可视化和分析性能分析数据的工具

  • 分析部分 - 有两种方式：网页/可视化终端

  • 具体的工具 - 可以在runtime/pprof中找到源码，同时Golang的http标准库中也对pprof做了 些封装，能让 你在http服务中直接使用它

  • 采样部分 - 它可以采样程序运行时的CPU、堆内存、goroutine、 锁竞争、 阻塞调用和系统线程的使用数 据

  • 展示 - 用户可以通过列表、调用图、火焰图、源码、反汇编等视图去展示采集到的性能指标。方便分析

在浏览器中打开 http://localhost:6060/debug/pprof/ ，可以看到采样数据和各种指标。

实战pprof

1. CPU问题

pprof的采样结果是将一段时间内的信息汇 总输出到文件中，所以首先需要拿到这个profile文件。你可以直接使用暴露的接口链接下载文件后使用，也可以直接用pprofI具连接这个接口下载需要的数据。

这里我们使用go tool pprof +采样链接来启动采样。 链接中就是刚刚「炸弹」程序暴露出来的接口，链接结尾的profile代表采样的对象是CPU使用。如果你在浏览器里直接打开这个链接，会启动个60秒的采样，并在结束后下载文件。这里我们加上seconds= 10的参数，让它采样十秒。

稍等片刻，我们需要的采样数据已经记录和下载完成，并展示出pprof终端：


PS E:\5\go-pprof-practice> go tool pprof "http://localhost:6060/debug/pprof/profile?seconds=10"
Fetching profile over HTTP from http://localhost:6060/debug/pprof/profile?seconds=10
Saved profile in C:\Users\WKX\pprof\pprof.samples.cpu.001.pb.gz
Type: cpu
Time: Jan 17, 2023 at 4:16pm (CST)
Duration: 10.17s, Total samples = 2.55s (25.06%)
Entering interactive mode (type "help" for commands, "o" for options)
(pprof) top

首先，输入top，查看CPU占用最高的函数 这五列从左到右分别是: Flat:当前函数的占用 Flat%: Flat占总量的比例 Sum%:_上面所有行的Flat%总和 Cum (Cumulative) :当前函数加上其调用函数的总占用 Cum%: Cum占总量的比例

[!question] 那么，在什么情况下Flat=cum?在什么情况下Flat=0?

Cum-Flat得到的是函数中调用其他函数所消耗的资源，所以在函数中没有对其他函数进行调用时，Cum-Flat=0， 也就是Flat=cum。 相应地，函数中除了调用另外的函数，没有其他逻辑时，Flat=0。

其次，输入list，根据指定的正则表达式查找代码行。

![[Pasted image 20230117165157.png]]

有的时候这样不是很直观，我们可以使用web命令，生成一个图，让调用关系可视化。

如果web后报错 Failed to execute dot. Is Graphviz installed? Error: exec: "dot": executable file not found in %PATH%

是没有安装gvedit导致的

进入gvedit官网graphviz.gitlab.io/_pages/Down… 下载稳定版

按照提示进行安装即可。

2. Heap堆内存

在刚刚排查CPU的过程中，我们使用的是pprof终端，这里我们介绍另-种展示方式。 通过http=:8080参数，可以开启pprof自带的Web UI，性能指标会以网页的形式呈现。 再次启动pprof工具，注意这时的链接结尾是heap等待采样完成后，浏览器会被自动打开，展示出熟悉的web视图， 同时展示的资源使用从「CPU时间」变为了「内存占用」。 可以明显看到，这里出问题的是*Mouse.Steal()函数，它占用了1GB内存。在页面顶端的View菜单中，我们可以切换不同的视图。

在SAMPLE中，还有一些需要注意的点：

  • alloc_ objects: 程序累计申请的对象数
  • inuse objects: 程序当前持有的对象数
  • alloc space:程序累计申请的内存大小
  • inuse_ space: 程序当前占用的内存大小

3. goroutine - 协程

用火焰图进行分析

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

4. mutex - 锁

修改链接后缀为mutex，在Source视图下可以定位。

5. block - 阻塞

修改链接后缀为block，在Source视图下可以定位。

我们只定位到一个block的问题。但刚刚的计数页面上有两个阻塞操作，那么另一个为什么没有展示呢?

可以关注一下pprof Top视图中表格之外的部分，有4个节点因为cumulative小于1.41秒被drop掉了，这就是另一个阻塞操作的节点，但他因为总用时小于总时长的干分之5，所以被省略掉了。这样的过滤策略能够更加有效地突出问题所在，而省略相对没有问题的信息。

如果不作任何过滤全部展示的话，对于一个复杂的程序可能内容就会非常庞大了，不利于我们的问题定位。

三、引用参考

  • 青训营：高质量编程简介及编码规范
  • 青训营：性能优化指南
  • 青训营：性能优化分析工具
avatar
文章
阅读
粉丝