高质量编程与性能调优实战 | 青训营笔记01.高质量编程这是我参与「第三届青训营 -后端场」笔记创作活动的的第2篇笔记

01.高质量编程

这是我参与「第三届青训营 -后端场」笔记创作活动的的第2篇笔记

1.1 高质量编程简介

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

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

编程原则

简单性

可读性

生产力

1.2 编码规范

如何编写高质量的代码

代码格式

注释

命名规范

控制流程

错误和异常处理

1.2.1 编码规范-代码格式

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

goimports管理依赖包

1.2.2 编码规范–注释

注释应该解释代码作用

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

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

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

1.2.3 编码规范-命名规范

简介胜于冗长

缩略词全大写,但当其位于变量开头且不需要导出时,使用全小写

例如使用ServeHTTP而不是ServeHttp

使用XMLHTTPRequest或者xmlHTTPRequest

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

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

variable

i和index作用域范围仅限于for循环内部时index的额外冗长几乎没有增加对于程序的理解（bad）
将deadline替换成t降低了变量名的信息量（good）

function

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

package

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

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

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

小结

核心目标是降低阅读理解代码的成本
重点考虑上下文信息，设计简介清晰的名称

1.2.4 编程规范–控制流程

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

小结

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

1.2.5 编码规范-错误和异常处理

简单错误

简单的错误指的是仅出现一次的错误，且在其他地方不需要捕获该错误
优先使用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

recover只能在被fefer函数中使用
嵌套无法生效
只在当前goroutine生效
defer的语句是后进先出
如果需要更多的上下文信息,可以recover后在log中记录当前的调用栈

小结

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

1.3 性能优化建议

简介

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

1.3.1 性能优化建议 – Benchmark

如何使用:

性能表现需要实际数据衡量
Go语言提供了支持基准性能测试的benchmark工具
go test -bench =. -benchmen

1.3.2 性能优化建议 –Slice

1. Slice预分配内存

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

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

包括数组指针

片段的长度

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

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

创建一个新的切片恢复用原来的切片的底层数组

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

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

1.3.3 性能优化建议–Map

map 预分配内存

分析：

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

1.3.4 性能优化建议–字符串处理

使用`strings.Builder`

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

1.3.5 性能优化建议–空结构体

使用空结构体节省内存

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

一个开源实现线程安全的Set: https://github.com/deckarep/golang-set/blob/main/threadunsafe.go

1.3.6 性能优化建议– atomic包

使用atomic包

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

小结

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

02.性能调优实战

2.1 简介

性能调优原则:

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

2.2 性能分析工具pprof

说明

希望知道应用在什么地方耗费了多少CPU、Memory
pprof 是用于可视化和分析性能分析数据的工具
pprof功能简介
pprof排查实战
pprof的采样过程和原理

2.2.1 性能分析工具pprof – 功能简介

2.2.2 性能分析工具pprof – 排查实战

搭建pprof实践项目

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

启动并访问http://localhost:6060/debug/pprof/

CPU

终端访问:go tool pprof "http://localhost:6060/debug/pprof/profile?seconds=10"

输入top: 查看占用资源最多的函数

参数	含义
flat	当前函数本身的执行耗时
flat%	flat占CPU总时间的比例
sum%	上面每一行的flat%总和
cum	指当前函数本身加上其调用函数的总耗时
cum%	cum占CPU总时间的比例

Flat == Cum ,函数中没有调用其它函数
Flat == 0,函数中只有其它函数被调用

输入 list Eat:查找具体出问题的函数

输入web:调用关系可视化

Heap – 堆内存

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

Top视图:

Source视图:

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

转到alloc_space:

一直在请求空间,但是没有使用,马上被gc

goroutine – 协程

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

View - frame graph

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

mutex – 锁

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

block – 阻塞

以此类推…

2.2.3 性能分析工具pprof – 采样过程和原理

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的调用栈信息
ThreadCreate
- 记录程序创建的所有系统线程的信息

Block – 阻塞 & Mutex – 锁

阻塞操作
- 采样阻塞操作的次数和耗时
- 采样率:阻塞耗时超过阈值的才会被记录，1为每次阻塞均记录
锁竞争
- 采样争抢锁的次数和耗时
- 采样率:只记录固定比例的锁操作，1为每次加锁均记录

2.3 性能调优案例

业务服务优化
基础库优化
Go语言优化

2.3.1 业务服务优化

基本概念

服务: 能单独部署，承载一定功能的程序

依赖: Service A的功能实现依赖Service B的响应结果，称为Service A 依赖Service B
调用链路:能支持一个接口请求的相关服务集合及其相互之间的依赖关系
基础库:公共的工具包、中间件

流程

建立服务性能评估手段
分析性能数据，定位性能瓶颈
重点优化项改造
优化效果验证

建立服务性能评估手段

服务性能评估方式
- 单独benchmark无法满足复杂逻辑分析
- 不同负载情况下性能表现差异
请求流量构造
- 不同请求参数覆盖逻辑不同
- 线上真实流量情况
压测范围
- 单机器压测
- 集群压测
性能数据采集
- 单机性能数据
- 集群性能数据

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

01.高质量编程

1.1 高质量编程简介

1.2 编码规范

1.2.1 编码规范-代码格式

1.2.2 编码规范–注释

1.2.3 编码规范-命名规范

variable

function

package

小结

1.2.4 编程规范–控制流程

小结

1.2.5 编码规范-错误和异常处理

简单错误

错误的Wrap和Unwrap

错误判定

panic

recover

小结

1.3 性能优化建议

简介

1.3.1 性能优化建议 – Benchmark

1.3.2 性能优化建议 –Slice

1. Slice预分配内存

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

1.3.3 性能优化建议–Map

map 预分配内存

1.3.4 性能优化建议–字符串处理

使用strings.Builder

1.3.5 性能优化建议–空结构体

使用空结构体节省内存

1.3.6 性能优化建议– atomic包

小结

02.性能调优实战

2.1 简介

2.2 性能分析工具pprof

说明

2.2.1 性能分析工具pprof – 功能简介

2.2.2 性能分析工具pprof – 排查实战

CPU

Heap – 堆内存

goroutine – 协程

mutex – 锁

block – 阻塞

2.2.3 性能分析工具pprof – 采样过程和原理

CPU

Heap – 堆内存

Goroutine – 协程 & ThreadCreate – 线程创建

Block – 阻塞 & Mutex – 锁

2.3 性能调优案例

2.3.1 业务服务优化

建立服务性能评估手段

使用`strings.Builder`