Go高质量编程与性能优化

高质量编程

简介

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

各种边界条件是否考虑完备
异常情况处理，稳定性保证
易读易维护

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

简单性
- 消除“多余的复杂性”，以简单清晰的逻辑编写代码
  - 不理解的代码无法修复改进
可读性
- 代码是写给别人看的，而不是机器
  - 编写可维护代码的第一步是确保代码可读
生产力
- 团队整体工作效率非常重要

编码规范

如何编写高质量的 Go 代码
- 代码格式
- 注释
- 命名规范
- 控制流程
- 错误和异常处理

代码格式

推荐使用 gofmt 自动格式化代码
- gofmt
  - Go 语言官方提供的工具，能自动格式化 Go 语言代码为官方统一风格
  - 常见 IDE 都支持方便的配置
- goimports
  - 也是 Go 语言官方提供的工具
  - 实际等于 gofmt 加上依赖包管理
  - 自动增删依赖的包引用、将依赖包按字母序排序并分类

注释

注释应该做的
- 注释应该解释代码作用
  - 适合注释公共符号
- 注释应该解释代码如何做的
  - 适合注释实现过程
- 注释应该解释代码实现的原因
  - 适合解释代码的外部因素
  - 提供额外上下文
- 注释应该解释代码什么情况会出错
  - 适合解释代码的限制条件
公共符号始终要注释
- 包中声明的每个公共的符号：变量、常量、函数以及结构都需要添加注释
- 任何既不明显也不简短的公共必须予以注释
- 无论长度或复杂程度如何，对库中的任何函数都必须进行注释
- 尽管 LimitedReader.Read 本身没有注释，但他紧跟 LimitedReader 结构的声明，明确它的作用
- 有一个例外，不需要注释实现接口的方法，具体不要像下面这样做
小结
- 代码是最好的注释
- 注释应该提供代码未表达出的上下文信息

命名规范

variable
- 简洁胜于冗长
- 缩略词全大写，但当其位于变量开头且不需要导出时，使用全小写
  - 例如使用 ServeHTTP 而不是 ServeHttp
  - 使用 XMLHTTPRequest 或者 xmlHTTPRequest
- 变量距离其被使用的地方越远，则需要携带越多的上下文信息
  - 全局变量在其名字中需要更多的上下文信息，使得在不同地方可以轻易辨认出其含义
  - - i 和 index 的作用域范围仅限于 for 循环内部时 index 的额外冗长几乎没有增加对于程序的理解
  - - 将 deadline 替换成 t 降低了变量名的信息量
    - t 常指任意时间
    - deadline 指截止时间，有特定的含义
function
- 函数名不携带包名的上下文信息，因为包名和函数名总是成对出现的
- 函数名尽量简短
- 当名为 foo 的包某个函数返回类型 Foo 时，可以省略类型信息而不导致歧义
  - 例如在 http 包中创建服务的函数
    - 命名func Serve(I net.Listener, handler Handler) error而不是func ServeHTTP(I net.Listener, handler Handler) error
    - 在其它包中调用时只需写 http.Serve 而不是 http.ServeHTTP
- 当名为 foo 的包某个函数返回类型 T 时（T 并不是 Foo），可以在函数名中加入类型信息
package
- 只由小写字母组成。不包含大写字母和下划线等字符
- 简短并包含一定的上下文信息
  - 例如 schema、task 等
- 不要与标准库同名
  - 例如不要使用 sync 或者 strings
- 以下规则尽量满足，以标准包名为例
  - 不使用常用变量名作为包名
    - 例如使用 bufio 而不是 buf
  - 是用单数而不是复数
    - 例如使用 encoding 而不是 encodings
  - 谨慎地使用缩写
    - 例如使用 fmt 在不破环上下文的情况下比 format 更加简短
小结
- 核心目标是降低阅读理解代码的成本
- 重点考虑上下文信息，设计简洁清晰的名称

控制流程

避免嵌套，保持正常流程清晰
- 如果两个分支中都包含 return 语句，则可以去除冗余的 else
尽量保持正常代码路径为最小缩进
- 优先处理错误情况/特殊情况，尽早返回或继续循环来减少嵌套
  - - 最常见的正常流程的路径被嵌套在两个 if 条件内
    - 成功的返回条件是 return nil ，必须仔细匹配大括号来发现
    - 函数最后一行返回一个错误，需要追溯到匹配的左括号，才能了解何时会触发错误
    - 如果后续正常流程需要增加一步操作，调用新的函数，则又会增加一层嵌套
  - 调整后
小结
- 线性原理，处理逻辑尽量走直线，避免复杂的嵌套分支
- 正常流程代码沿着屏幕向下移动
- 提升代码可维护性和可读性
- 故障问题大多出现在复杂的条件语句和循环语句中

错误和异常处理

简单错误处理
- 简单的错误指的是仅出现一次的错误，且在其他地方不需要捕获该错误
- 优先使用 error.New 来创建匿名变量来直接表示简单错误
- 如果有格式化的需求，使用 fmt.Errorf
错误的 Wrap 和 Unwrap
- 错误的 Wrap 实际上是提供了一个 error 嵌套另一个 error 的能力，从而生成一个 error 的跟踪链
- 在 fmt.Errorf 中使用：%v 关键字来将一个错误关联至错误链中
错误判定
- 判定一个错误是否为特定错误，使用 error.Is
- 不同于使用==，使用该方法可以判定错误链上的所有错误是否含有特定的错误
- 在错误链上获取特定种类的错误，使用 errors.As
panic
- 不建议在业务代码中使用 panic
- 调用函数不包含 recover 会造成整个程序崩溃
- 若问题可以被屏蔽或解决，建议使用 error 代替 panic
- 当程序启动阶段发生不可逆转的错误时，可以在 init 或 main 函数中使用 panic
recover
- recover 只能在被 defer 的函数中使用
- 嵌套无法生效
- 只在当前 goroutine 生效
- defer 的语句是后进后出
- 如果需要更多的上下文信息，可以 recover 后在 log 中记录当前的调用栈
小结
- error 尽可能提供简明的上下文信息，方便定位问题
- panic 用于真正异常的情况
- recover 生效范围，在当前 goroutine 的被 defer 的函数中生效

性能优化建议

Benchmark

如何使用
- 性能表现需要实际数据衡量
- Go 语言提供了支持基准性能测试的 benchmark 工具
- go test -bench=. -benchmem
结果说明

Slice 预分配内存

尽可能在使用 make() 初始化切片时提供容量信息，特别是在追加切片时
原理
- 切片本质是一个数组片段的描述
  - 包括了数组的指针
  - 片段的长度
  - 片段的容量(不改变内存分配情况下的最大长度)
- 切片操作并不复制切片指向的元素
- 创建一个新的切片会复用原来切片的底层数组
另一个陷阱：大内存未释放
- 在已有切片的基础上创建切片，不会创建新的底层数组
  - 因为原来的底层数组没有发生变化，内存会一直占用，直到没有变量引用该数组
- 场景
  - 原切片较大，代码在原切片基础上新建小切片
  - 原底层数组在内存中有引用，得不到释放
- 可使用 copy 替代 re-slice

Map 预分配内存

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

字符串处理（使用 strings.Builder)

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

空结构体节省内存

空结构体 struct{} 示例不占据任何内存空间
可作为各种场景下的占位符使用
- 节省资源
- 空结构体本身具备很强的语义，即这里不需要任何值，仅作为占位符
实现 Set，可以考虑用 map 来代替
对于这个场景，只需要用到 map 的键，而不需要值
即使是将 map 的值设置为 bool 类型，也会多占据 1 个字节空间

atomic 包

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

小结

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

性能调优实战

简介

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

性能分析工具 pprof

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

功能简介

排查实战

搭建 pprof 实践项目

Github（来自 Wolfogre）
https://github.com/wolfogre/go-pprof-practice
项目提前埋入了一些炸弹代码，产生可观测的性能问题

浏览器查看指标

localhost:6060/debug/pprof/

排查 CPU

命令行分析（可读性较差）
- go tool pprof "[http://localhost:6060/debug/pprof/profile?seconds=10](https://link.juejin.cn/?target=http%3A%2F%2Flocalhost%3A6060%2Fdebug%2Fpprof%2Fprofile%3Fseconds%3D10)"
- 命令：topN
  - 查看占用资源最多的函数
    - flat 当前函数本身的执行耗时
    - flat% flat 占 CPU 总时间的比例
    - sum% 上面每一行的 flat% 总和
    - cum 指当前函数本身加上其调用函数的总耗时
    - cum% cum 占 CPU 总时间的比例
      - Flat == Cum，说明函数中没有调用其他函数
      - Flat == 0，说明函数中只有其他函数的调用
- 命令：list
  - 根据指定的正则表达式查找代码行
- 命令：web
  - 调用关系可视化
go tool pprof -http=:8080 "[http://localhost:6060/debug/pprof/cpu](http://localhost:6060/debug/pprof/cpu)"

排查 Heap-堆内存

go tool pprof -http=:8080 "[http://localhost:6060/debug/pprof/heap](https://link.juejin.cn/?target=http%3A%2F%2Flocalhost%3A6060%2Fdebug%2Fpprof%2Fheap)"
VIEW：切换视图类型
- Top 视图 –> Source 视图
SAMPLE
- alloc_objects：程序累计申请的对象数
- alloc_space：程序累计申请的内存大小
- inuse_objects：程序当前持有的对象数
- inuse_space：程序当前占用的内存大小

排查 goroutine-协程

goroutine 泄露也会导致内存泄漏

go tool pprof -http=:8080 "[http://localhost:6060/debug/pprof/goroutine](https://link.juejin.cn/?target=http%3A%2F%2Flocalhost%3A6060%2Fdebug%2Fpprof%2Fgoroutine)"
VIEW 切换到 flamegraph 视图（常用）
- 由上到下表示调用顺序
- 每一块代表一个函数，越长代表占用 CPU 的时间更长
- 火焰图是动态的，支持点击块进行分析
支持搜索，在 Source 视图下搜索

排查 mutex-锁

go tool pprof -http=:8080 "[http://localhost:6060/debug/pprof/mutex](https://link.juejin.cn/?target=http%3A%2F%2Flocalhost%3A6060%2Fdebug%2Fpprof%2Fmutex)"

排查 block-阻塞

go tool pprof -http=:8080 "[http://localhost:6060/debug/pprof/block](https://link.juejin.cn/?target=http%3A%2F%2Flocalhost%3A6060%2Fdebug%2Fpprof%2Fblock)"

采样过程和原理

CPU

采样对象：函数调用和它们占用的时间
采样率：100 次/秒，固定值
采样时间：从手动启动到手动结束
- 开始采样 –> 设定信号处理函数 –> 开启定时器
- 停止采样 –> 取消信号处理函数 –> 关闭定时器
操作系统
- 每 10ms 向进程发送一次 SIGPROF 信号
进程
- 每次接收到 SIGPROF 会记录调用堆栈
写缓冲
- 每 100ms 读取已经记录的调用栈并写入输出流

Heap-堆内存

采样程序通过内存分配器在堆上分配和释放的内存，记录分配/释放的大小和数量
采样率：每分配 512KB 记录一次，可在运行开头修改，1 为每次分配均记录
采样时间：从程序运行开始到采样时
采样指标：alloc_space，alloc_objects，inuse_space，inuse_objects
计算方式：inuse = alloc - free

Goroutine-协程 & ThreadCreate-线程创建

Goroutine
- 记录所有用户发起且在运行中的 goroutine （即入口非 runtime 开头的）runtime.main 的调用栈信息
- Stop The World –> 遍历 allg 切片 –> 输出创建 g 的堆栈 –> Start The World
ThreadCreate
- 记录程序创建的所有系统线程的信息
- Stop The World –> 遍历 allm 链表 –> 输出创建 m 的堆栈 –> Start The World

Block-阻塞 & Mutex-锁

阻塞操作
- 采样阻塞操作的次数和耗时
- 采样率：阻塞耗时超过阈值的才会被记录，1 为每次阻塞均记录
- 阻塞操作 – (上报调用栈和消耗时间) –> Profiler –> 时间未到阈值则丢弃
- I–(采样)–> 遍历阻塞记录 –> 统计阻塞次数和耗时
锁竞争
- 采样争抢锁的次数和耗时
- 采样率：只记录固定比例的锁操作，1 为每次加锁均记录
- 锁竞争操作 – (上报调用栈和消耗时间) –> Profiler –> 比例未命中则丢弃
- I–(采样)–> 遍历锁记录 –> 统计锁竞争次数和耗时