Go性能优化-高质量编程 | 青训营笔记

九牧
106 阅读16分钟

hut-6968718_1280.png

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

1. 简介

什么是高质量编程？

编写的代码能够达到正确可靠、简洁清晰的目标可称之为高质量代码

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

编程原则

实际应用场景千变万化，各种语言的特性和语法各不相同但是高质量编程遵循的原则是相通的

简单性

  • 消除”多余的复杂性”，以简单清晰的逻辑编写代码
  • 不理解的代码无法修复改进（也就是常说的“屎山”）

可读性

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

生产力

  • 团队整体工作效率非常重要
    • 例如代码规范

2. 编码规范

2.1 代码格式

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

另外可以考虑 goimports，会对依赖包进行管理，自动增删依赖的包引用，按字母序排序分类，具体可以根据团队实际情况配置使用之所以将格式化放在第一条，因为这是后续规范的基础，团队合作 review 其他人的代码时就能体会到这条规范的作用了

2.2 注释

大多数时候我们都在关注代码实现，但是注释的重要性容易被忽视

  • 注释应该解释代码作用

  • 注释应该解释代码如何做的

  • 注释应该解释代码实现的原因

  • 注释应该解释代码什么情况会出错

好的代码有很多注释，坏代码需要很多注释

1、注释应该解释代码作用

适合注释公共符号

首先是注释应该解释代码作用，这种注释适合说明公共符号，比如对外提供的函数注释描述它的功能和用途。只有在函数的功能简单而明显时才能省路这些注释（例如，简单的取值和设值函教）另外注释要避免啰嗦，不要对显而易见的内容进行说明。

image-20230124111936110

下面的代码中注释就没有必要加上，通过名称可以很容易的知道作用。

image-20230124111956892

2、注释应该解释代码如何做的

适合注释实现过程

第二种注释是对代码中复杂的，并不明显的逻辑进行说明，适合注释实现过程

image-20230124112205871

上面这段代码是给新 url 加上最近的 referer 信息，并不是特别明显，所以注释说明了一下

下面的是一个反例，虽然是对过程注释，但是描述的是显而易见的流程，注意不要用自然语言直接翻译代码作为注释，信息冗余还好，有时候表述不一定和代码一致

image-20230124112230700
3、注释应该解释代码实现的原因
  • 适合解释代码的外部因素
  • 提供额外上下文

第三条，注释可以解释代码的外部因素，这些因素脱离上下文后通常很难理解

image-20230124112735125

github.com/golang/go/b…

示例中有一行 shouldRedirect=false 的语句，如果没有注释，无法清楚地明白为什么会设置 false ，所以注释里提到了这么做的原因，给出了上下文说明

4、注释应该解释代码什么情况会出错

适合解释代码的限制条件

第四，注释应该提醒使用者—些潜在的限制条件或者会无法处理的情况

image-20230124112946747

github.com/golang/go/b…

例如函数的注释中可以说明是否存在性能隐患，输入的限制条件，可能存在哪些错误情况，让使用者无需了解实现细节，示例介绍了解析时区字符串的流程，同时对可能遇到的不规范字符串处理进行了说明

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

image-20230124113415472

github.com/golang/go/b…

示例是一个公共函数的注释说明，结合之前提到的规范，注释表述了函数的功能和如何工作的

当然也有例外，就是注释没有提供有用的信息。它没有告诉你这个方法做了什么，更糟糕是它告诉你去看其他地方的文档，在这种情况下，建议完全删除该注释

image-20230124113717610

6、小结
  • 代码是最好的注释
  • 注释应该提供代码未表达出的上下文信息

2.3 命名规范

2.3.1 Variable

写代码中最常见的就是命名了，最头疼的也是命名了，想想就开始纠结了😂

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

image-20230124114442404

i和index的作用域范围仅限于for循环内部时，index的额外冗长几乎没有增加对于程序的理解，所以更加简单的为好。但是索引的作用域扩展，在循环外也会用到的时候，就要考虑更加符合需求的名称了。

image-20230124114710146

  • 将deadline替换成t降低了变量名的信息量。t常代指任意时间，deadline指截止时间，有特定的含义
  • 函数提供给外部调用时，签名的信息很重要，要将自己的功能准确表现出来，自动提示一般也会提示函数的方法签名，通过参数名更好的理解功能很有必要，节省时间
2.3.2 function
  • 函数名不携带包名的上下文信息，因为包名和函数名总是成对出现的
  • 函数名尽量简短
  • 当名为foo的包某个函数返回类型Foo时，可以省略类型信息而不导致歧义
  • 当名为foo的包某个函数返回类型Ⅰ时(T并不是Foo)，可以在函数名中加入类型信息
2.3.3 package
  • 只由小写字母组成。不包含大写字母和下划线等字符
  • 简短并包含一定的上下文信息。例如 schema、task 等
  • 不要与标准库同名。例如不要使用 sync 或者 strings

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

  • 不使用常用变量名作为包名。例如使用 bufio 而不是 buf
  • 使用单数而不是复数。例如使用 encoding 而不是 encodings
  • 谨慎地使用缩写。例如使用 fmt 在不破坏上下文的情况下比 format 更加简短
2.3.4 小结
  • 核心目标是降低阅读理解代码的成本
  • 重点考虑上下文信息，设计简洁清晰的名称

总体来说，命名的核心在于降低阅读理解代码的成本，人们在阅读理解代码的时候会尝试模拟计算机运行程序，好的命名能让人把关注点留在主流程上，清晰地理解程序的功能，避免频繁切换到分支细节，增加理解成本。

好的命名就像一个好笑话。如果你必须解释它，那就不好笑了

2.4 控制流程

避免嵌套，保持正常流程清晰

image-20230124125335625

从最简单的一个 if else 条件开始，如果两个分支都包含 return 语句，则可以去除冗余的 else 方便后续维护，else 一般是正常流程，如过需要在正常流程新增判断逻辑，避免分支嵌套

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

image-20230124125657151
  • 最常见的正常流程的路径被嵌套在两个 if 条件内
  • 成功的退出条件是 return nil，必须仔细匹配大括号来发现
  • 函数最后一行返回一个错误，需要追溯到匹配的左括号，才能了解何时会触发错误
  • 如果后续正常流程需要增加一步操作，调用新的函数，则又会增加一层嵌套
image-20230124125808582

调整后

image-20230124125855292

github.com/golang/go/b…

上面是go仓库中的代码示例，也是优先处理err情况，保持正常流程的统一

小结：

  • 线性原理，处理逻辑尽量走直线，避免复杂的嵌套分支
  • 正常流程代码沿着屏幕向下移动
  • 提升代码可维护性和可读性
  • 故障问题大多出现在复杂的条件语句和循环语句中

2.5 错误和异常处理

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

image-20230124130336256

github.com/golang/go/b…

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

image-20230124130659770

同时结合错误的判定方法来确认调用链中是否有关注的错误出现。这个能力的好处是每一层调用方可以补充自己对应的上下文，方便跟踪排查问题，确定问题的根本原因在哪里

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

image-20230124132323703

github.com/golang/go/b…

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

image-20230124132516245

github.com/golang/go/b…

它和is的区别在于as会提取出调用链中指定类型的错误，并将错误赋值给定义好的变量，方便后续处理，示例中是把问题的path打印出来了

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

image-20230124133105546

github.com/Shopify/sar…

比错误更加严重的就是 panic，因为它的出现就意味着程序无法正常工作了

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

image-20230124133357745

github.com/golang/go/b…

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

image-20230124134040804

github.com/golang/webs…

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

因为错误和异常是不正常的情况，除了希望程序能兼容这些场景外，重要的也有记录问题的上下文信息，方便后续定位原因在明确 panic recover 这些功能的作用范围的情况下，编写更可靠的程序

3. 性能优化建议

3.0 简介

高质量的代码能够完成功能，但是在大规模程序部署的场景，仅仅支持正常功能还不够，我们还要尽可能的提升性能，节省资源成本，接下来就主要介绍性能相关的建议

高性能代码为了效率会用到许多技巧，没有相关背景的人难以理解，不过有些基础性能问题是和语言本身相关的，接下来主要介绍这类内容，对应的调整对可读性和可维护性影响不大在满足正确性、可靠性、健壮性、可读性等质量因素的前提下，设法提高程序的性能

有时候时间效率和空间效率可能对立，此时应当分析那个更重要，作出适当的折衷。例如多花费一些内存来提高性能针对Go语言编程，介绍Go相关的性能优化建议

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

3.1 Benchmark

  • 性能表现需要实际数据衡量
  • Go语高提供了支持基准性能测试的 benchmark 工具

我们以斐波那契数列的函数为例，编写 fib.go 和测试文件 fib_test.go，然后通过命令行运行 benchmark 可以得到详细的测试结果（-benchmem 表示也统计内存消息）

// 在两个函数的当前文件下执行此命令（最好文件内只有这两个文件）
go test -bench . -benchmem
image-20230124174116273

image-20230124180605252

简单介绍一下各项的含义：

  • BenchmarkFib10 是测试函数名；-8表示 GOMAXPROCS 的值为8
  • 表示一共执行 4786677 次即 b.N 的值
  • 每次执行花费 250.4ns
  • 每次执行申请多大的内存
  • 每次执行申请几次内存

可能需要记住，后面测试会频繁出现

3.1 Slice

Slice 是go中最常见的结构，也非常的方便，同样在使用过程中需要注意性能的点

1、Slice预分配内存

尽可能在使用 make() 初始化切片的时候提供容量信息，特别是在追加切片的时候

image-20230124184334270 image-20230124184355567

image-20230124185140964

对比看下两种情况的性能表现，左边是没有提供初始化容量信息，右边是设置了容量大小结果中可以看出执行时间相差很多（第二个数据可以简单的看成1s执行了几次），预分配只有一次内存分配

why？为什么会有怎么大的性能差异？

  • 切片本质是一个数组片段的描述
    • 包括数组指针
    • 片段的长度
    • 片段的容量（不改变内存分配情况下的最大长度）
    • 切片操作并不复制切片指向的元素
  • 创建一个新的切片会复用原来切片的底层数组

image-20230124192410790 image-20230124192434534

ueokande.github.io/go-slice-tr…

以切片的 append 为例，append 时有两种场景:

  • 当 append 之后的长度小于等于cap，将会直接利用原底层数组剩余的空间

  • 当 append 后的长度大于 cap 时，则会分配一块更大的区域来容纳新的底层数组

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

2、大内存未释放
  • 在已有切片基础上创建切片，不会创建新的底层数组
  • 场景
  • 原切片较大，代码在原切片基础上新建小切片
  • 原底层数组在内存中有引用，得不到释放
  • 可使用 copy 替代，re-slice
image-20230124200032945 image-20230124200131291 
go test -run=. -v

或直接选中两个文件使用 goland 中的 run，里面有测试功能

image-20230124200405982

两部分代码使用了不同的逻辑取 slice 的最后两位数创建新数组，同时统计输出了内存占用信息

结果差异非常明显，lastBySlice 耗费了100.2MB 内存，也就是说，申请的 100 个 1MB 大小的内存没有被回收。因为切片虽然只使用了最后2个元素，但是因为原来 1M 的切片引用了相同的底层数组，底层数组得不到释放，因此最终 100MB 的内存始终得不到释放；而 lastByCopy 仅消耗了 1.17MB 的内存，这是因为，通过copy，指向了一个新的底层数组，当 origin 不再被引用后，内存会被垃圾回收

3.2 Map

map 预分配内存

image-20230124201434669 image-20230124201457199

image-20230124202201351

可能是电脑的问题，总是10000，估计配置不太行，运算速度太慢了

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

3.3 字符串处理

使用 strings.Builder

image-20230124203330618 image-20230124203352486

image-20230124203506740

image-20230124204507640

可能是电脑太拉了，跑Plus感觉跑了一万年😭

使用＋拼接性能最差，strings.Builder、bytes.Buffer 相近，strings.Buffer 更快

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

image-20230124204853902 image-20230124204921317

字符串拼接和 slice 一样，同样支持预分配，在预知字符串长度的情况下，我们可以进一步提升拼接性能注意这里能确认 stringbuiler 只有一次内存分配，bytebuffer 有两次

image-20230124205409847

3.4 空结构图

性能优化有时是时间和空间的平衡，之前提到的都是提高时间效率的点，对于空间上是否有优化的手段呢？空结构体是节省内存空间的一个手段

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

image-20230124210454117

可能是电脑的问题，总是10000，估计配置不太行，运算速度太慢了

  • 实现 Set，可以考虑用 map 来代替
  • 对于这个场景，只需要用到 map 的键，而不需要值
  • 即使是将 map 的值设置为 bool 类型，也会多占据 1 个字节空间

3.5 atomic包

image-20230124211908872 image-20230124211938735

image-20230124211843297

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

3.6 小结

  • 避免常见的性能陷阱可以保证大部分程序的性能
  • 普通应用代码，不要一味地追求程序的性能
  • 越高级的性能优化手段越容易出现问题
  • 在满足正确可靠、简洁清晰的质量要求的前提下提高程序性能

如有错误，欢迎指正！

avatar
文章
阅读
粉丝