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

---

本节摘要：

1.如何编写更简洁清晰的代码

2.常用Go语言程序优化手段

3.熟悉Go程序性能分析工具

4.了解工程中性能优化的原则和流程

1.高质量编程

---

简介：

代码正确可靠，简介清晰的目标

• 边界条件是否考虑完备

• 异常处理方面，保证稳定性

• 易读易维护，代码清晰，方便合作运维

编程原则：

• 简单性：用简单清晰的逻辑去处理功能，消除多余复杂的逻辑，避免代码无法修复改进

• 可读性：项目是相互迭代，功能是不断完善的，因此要方便维护阅读

• 生产力：要有团队整体工作效率

编程规范

代码格式：

推荐使用gofmt自动格式化代码

gofmt是GO官方提供的工具，能够在退出时自动格式化代码为官方统一标准

或者

goimports

也是GO官方的工具，在gofmt基础上还有依赖包的管理，能够自动增删依赖包的引用，将依赖包按字母排序分类，比较清晰

注释：

• 解释代码作用，比如一些公共符号，公共常量，公共函数等

• 解释代码如何做的，注释代码的实现过程

• 解释代码实现的原因，为什么要这么写，可能有上下文联系，外部因素等等

• 解释代码什么情况会出错，一些限制条件

公共符号必须要注释，防止他人使用时看不懂或出现错误

1）包中声明的每个公共的符号变量、常量、函数以及结构都需要添加注释

2）任何既不明显也不简短的公共功能必须予以注释

3）无论长度或复杂程度如何,对库中的任何函数都必须进行注释

代码是最好的注释，代码本身最好能体现出它的功能等等

命名规范：

变量名

1. 简洁胜于冗长

2. 缩略词全大写，但当其位于变量开头且不需要导出时，使用全小写·例如使用ServeHTTP而不是 ServeHttp

3. 使用XMLHTTPRequest或者xmHTTPRequest

4. 变量距离其被使用的地方越远，则需要携带越多的上下文信息

5. 全局变量在基名字中需要更多的上下文信息，使得在不同地方可以轻易辨认出其含义

比如我们要用截止时间时，用deadline就比用t好

函数

1. 函数名不携带包名的上下文信息，因为包名和函数名总是成对出现的函数名尽量简短

2. 当多为foo 的包某个函数返回类型Foo时，可以省略类型信息而不导致歧义

3. 当名为foo的包某个函数返回类型T时(T并不是Foo)，可以在函数名中加入类型信息

4. 尽量将函数与包名相关联，与包相关性强，命名就可以略微省去和包相关的信息，方便在其他的地方出现类似功能时可以很好的命名

包

必须满足规则

1. 只由小写字母组成。不包含大写字母和下划线等字符

2. 简短并包含一定的上下文信息。例如schema、task 等

3. 不要与标准库同名。例如不要使用sync或者strings，避免冲突或被误解，影响开发效率

非必须满足规则

4. 不使用常用变量名作为包名。例如使用bufio而不是 buf

5. 使用单数而不是复数。例如使用encoding而不是encodings

6. 谨慎地使用缩写。例如使用fmt在不破坏上下文的情况下比 format更加简短

控制流程

避免if else的嵌套，尽量清晰简洁

比如两个分支都包含return，可以省去冗余的else

休闲处理错误情况和特殊情况，尽早的返回或继续循环来减少嵌套

线性原理,处理逻辑尽量走直线

避免复杂的嵌套分支正常流程代码沿着屏幕向下移动

故障问题大多出现在复杂的条件语句和循环语句中

错误和异常处理

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

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

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

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

在错误链上获取特定种类的错误，使用errors.As，可把出现问题的地方给拼接出来，方便定位问题

不建议在业务代码中使用panic

调用函数不包含recover 会造成程序崩溃

当程序启动阶段发生不可逆转的错误时，可以在 init 或 main 函数中使用panic

recover只能在被defer的函数中使用嵌套无法生效，只在当前goroutine生效defer的语句是后进先出，可以recover 后在log中记录当前的调用栈

• error尽可能提供简明的上下文信息链，方便定位问题

• panic 用于真正异常的情况

• recover生效范围，在当前goroutine的被 dofer的函数中生效

• defer语句会在函数返回前调用多个defer语句是后进先出

性能优化建议

性能优化的前提是代码的正确可靠，简洁等根本的质量因素

性能优化需要综合考量时间复杂度和空间复杂度

使用Benchmark进行性能测试

gotest-bench=, -benchmem

BenchmarkFib10是测试函数名-8表示GOMAXPROCS的值为8

1855870: 表示一共执行1855870次即b.N的值

602.5ns/op : 每次执行花费602.5ns

0 B/op::每次执行申请多大的内存

0 allocs/op : 每次执行申请几次内存

Slice性能优化建议

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

左边为没有预制大小，右边是初始化了大小

执行时间对比：

明显初始化大小后会提升效率

切片本质是一个数组片段的描述

包括数组指针

片段的长度

片段的容量(不改变内存分配情况下的最大长度)

切片操作并不复制切片指向的元素

创建一个新的切片会复用原来切片的底层数组，如果容量不够会先扩容，再添加，这样的操作是需要消耗时间的

在已有切片基础上创建切片，不会创建新的底层数组场景：

原切片较大，代码在原切片基础上新建小切片·原底层数组在内存中有引用，得不到释放可使用copy替代 re-slice

Map性能优化建议

和Slice类似，最好先预分配内存，提前分配好空间可以减少内存拷贝和 Rehash的消耗，不断向map中添加元素的操作会触发map的扩容

字符串处理性能优化

使用strings.Builder进行字符串拼接可以提升性能

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

左为直接拼接，右为使用Builder

性能差异如下：

性能差异原因：

1. 字符串在Go语言中是不可变类型，占用内存大小是固定的使用＋每次都会重新分配内存

2. strings.Builder，bytes.Buffer底层都是[]byte 数组内存扩容策略，不需要每次拼接重新分配内存

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

如果知道字符串大小，最好预分配内存，这样的效率最优，原理和Slice差不多

空结构体的使用

空结构体struct实例不占据任何的内存空间可作为各种场景下的占位符使用

空结构体本身具备很强的语义，即这里不需要任何值，仅作为占位符

比如：

测试性能结果如下：

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

atomic包的使用处理线程问题

左为使用atomic包处理线程问题，右为使用加锁的方式，也就是我们之前经常用到的方式

对比性能：

使用atomic包可以提升性能

原因分析：

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

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