这是我参与「第三届青训营 -后端场」笔记创作活动的的第2篇笔记
01 高质量编程
1.1 高质量编程简介
什么是高质量?
- 编写的代码能够达到正确可靠、简洁清晰的目标可称之为高质量代码
- 各种边界条件是否考虑完备
- 异常情况处理,稳定性保证
- 易读易维护
简单性
- 消除“多余的复杂性”,以简单清晰的逻辑编写代码
- 不理解的代码无法修复改进
可读性
- 代码是写给人看的,而不是机器
- 编写可维护代码的第一步是确保代码可读
生产力
- 团队整体工作效率非常重要
1.2 编码规范
如何编写高质量的Go代码?
-
代码格式
- 推荐使用gofmt自动格式化代码
-
注释
- 注释应该解释代码作用
- 注释应该解释代码如何做的
- 注释应该解释代码实现的原因
- 注释应该解释代码什么情况会出错
-
代码是最好的注释
注释应该提供代码未表达出的上下文信息
-
命名规范
-
variable
-
简洁胜于冗长
-
缩略词全大写,但当其位于变量开头且不需要导出时,使用全小写
- 例如使用ServerHTTP,而不是ServerHttp
- 使用XMLHTTPRequest 或者 xmlHTTPRequest
-
变量距离其被使用的地方越远,则需要携带越多的上下文信息
- 全局变量在其名字中需要更多的上下文信息,使得在不同地方可以轻易辨认出其含义
-
-
function
- 函数名不携带包名的上下文信息,因为包名和函数名总是成对出现的
- 函数名尽量简短
- 当名为foo的包某个函数返回类型Foo时,可以省略类型信息而不导致歧义
- 当名为foo的包某个函数返回类型T时(T并不是Foo),可以在函数名中加入类型信息
-
package
-
只由小写字母组成。不包含大写字母和下划线等字符
-
简短并包含一定的上下文信息。例如schema、task等
-
不要与标准库同名。例如不要使用sync或者strings
-
以下规则尽量满足,以标准库包名为例:
- 不使用常用变量名作为包名。例如使用bufio而不是buf
- 使用单数而不是复数。例如使用encoding而不是encodings
- 谨慎地使用缩写。例如使用fmt在不破坏上下文的情况下比format更加简短
-
-
小结:
- 核心目标是降低阅读理解代码的成本
- 重点考虑上下文信息,设计简洁清晰的名称
-
-
控制流程
-
避免嵌套,保持正常流程清晰
-
保持正常代码路径为最小缩进
- 优先处理错误情况/特殊情况,尽早返回或继续循环来减少嵌套
-
小结:
- 线性原理,处理逻辑尽量走直线,避免复杂的嵌套分支
- 正常流程代码沿着屏幕向下移动
- 提升代码可维护性和可读性
- 故障问题大多出现在复杂的条件语句和循环语句中
-
-
错误和异常处理
-
简单错误
- 简单的错误指的是仅出现一次的错误,且在其他地方不需要捕获该错误
- 优先使用
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只能在被defer的函数中使用
- 嵌套无法生效
- 只在当前groutine生效
- defer的语句是后进先出
-
小结:
- error尽可能提供简明的上下文信息链,方便定位问题
- panic用于真正异常的情况
- recover生效范围,在当前groutine的被defer的函数中生效
-
1.3 性能优化建议
简介
- 性能优化的前提是满足正确可靠、简洁清晰等质量因素
- 性能优化是综合评估,有时候时间效率和空间效率可能对立
- 针对Go语言特性,介绍Go相关的性能优化建议
Benchmark
- 性能表现需要实际数据衡量,Go语言提供了支持基准性能测试的benchmark工具
go test -bench=. -benchmen
Slice
-
slice预分配内存
- 尽可能在使用make()初始化切片时提供容量信息
-
另一个陷阱:大内存未释放
- 在已有切片基础上创建切片,不会创建新的底层数组
-
场景
- 原切片较大,代码在原切片基础上新建小切片
- 原底层数组在内存中有引用,得不到释放
-
可使用copy代替re-slice
-
Map
-
map预分配内存
- 不断向map中添加元素的操作会触发map的扩容
- 提前分配好空间可以减少内存拷贝和Rehash的消耗
- 建议根据实际需求提前预估好需要的空间
字符串处理
-
使用strings.Builder
-
常见的字符串拼接方式:
-
方式1:
+ -
方式2:
strings.Builder -
方式3:
ByteBuffer -
结果:
-
使用+拼接性能最差,strings.Builder, bytes.Buffer相近,strings.Buffer更快
-
分析:
- 字符串在Go语言中是不可变类型,占用内存大小是固定的
- 使用+每次会重新分配内存
- strings.Builder, bytes.Buffer 底层都是[]bytre数组
- 内存扩容策略,不需要每次拼接重新分配内存
-
空结构体
-
使用空结构体节省内存
-
空结构体struct{}不占据任何的内存空间
-
可作为各种场景下的占位符使用
- 节省资源
- 空结构体本身具备很强的语义,即这里不需要任何值,仅作为占位符
-
-
实现Set,可以考虑用map来代替
- 对于这个场景,只需要用到map的键,而不需要值
- 即使是将map的值设置为bool类型,也会多占据1个字节空间
atomic包
-
如何使用
-
对比加锁:
-
结果:
- 锁的实现是通过操作系统来实现,属于系统调用
- atomic操作是通过硬件实现,效率比锁高
- sync.Mutex应该用来保护一段逻辑,不仅仅用于保护一个变量
- 对于非数值操作,可以使用atomic.Value,能承载一个interface{}
小结:
- 避免常见的性能陷阱可以保证大部分程序的性能
- 普通应用代码,不要一味地追求程序的性能
- 越高级的性能优化手段越容易出现问题
- 在满足正确可靠、简洁清晰的质量要求的前提下提高程序性能
02 性能调优实战
2.1 性能调优简介
性能调优原则
- 要依靠数据而不是猜测
- 要定位最大瓶颈而不是细枝末节
- 不要过早优化
- 不要过度优化
性能分析工具pprof
说明
- 希望知道应用在什么地方耗费了多少CPU、Memory
- pprof适用于可视化和分析性能分析数据的工具
2.2 性能分析工具pprof实战
-
pprof功能简介
-
pprof排查实战
- 搭建pprof实践项目
- 项目代码:github.com/wolfogre/go…
- 项目提前买入了一些炸弹代码,产生可观测的性能问题
-
CPU
go tool pprof "http://localhost:6060/debug/pprof/profile?seconds=10"
-
命令:topN
- 查看占用资源最多的函数:
- flat : 当前函数本身的执行耗时
- flat% : flat占CPU总时间的比例
- sum% : 上面每一行的flat% 总和
- cum : 指当前函数本身加上其调用函数的总耗时
- cum% : cum占CPU总时间的比例
- Flat == Cum , 函数中没有调用其它函数
- Flat == 0 , 函数中只有其他函数的调用
-
命令:list
- 根据指定的正则表达式查找代码
-
命令:web
- 调用关系可视化
-
定位到问题代码部分,去删除该部分代码(只适用于该案例)即可
- 接下来排查内存问题
-
Heap-堆内存
go tool pprof -http=:8080 "http://localhost:6060/debug/pprof/heap"- 需要安装一个工具...待续
-
groutine-协程
go tool pprof -http=:8080 "http://localhost:6060/debug/pprof/goroutine"
-
mutex-锁
go tool pprof -http=:8080 "http://localhost:6060/debug/pprof/mutex"
-
block-阻塞
go tool pprof -http=:8080 "http://localhost:6060/debug/pprof/block"
小结:
pprof的采样过程和原理
略
2.3 性能调优案例
-
业务服务优化
-
流程
- 建立服务性能评估手段
- 分析性能数据,定位性能瓶颈
- 重点优化项改造
- 优化效果验证
-
-
基础库优化
-
Go语言优化
2.4 总结
-
性能调优原则
- 要依靠数据而不是猜测
-
性能分析工具pprof
-
性能调优
- 保证正确性
- 定位主要瓶颈