学习笔记第二篇。总共第二篇。

一、本堂课重点内容：

本堂课主要介绍了Go语言的编码规范、pprof工具使用方法、pprof工具采样原理

二、详细知识点介绍：

常见编码规范

gofmt工具：`` goimports工具：go install golang.org/x/tools/cmd/goimports@latest

注释：

注释应该解释代码作用（适合注释公共符号，公共符号始终需要注释）例如go/file.go#L313 at master · golang/go (github.com)
注释应该解释代码如何做的（适合注释实现过程）例如go/client.go#L678 at master · golang/go (github.com)
注释应该解释代码实现的原因（适合解释代码的外部因素，如解释历史原因等）例如go/client.go#L521 at master · golang/go (github.com)
注释应该解释代码什么情况会出错（解释代码的限制条件）

公开函数始终需要注释：

包中声明的每个公共符号，变量、常量、函数、结构都需要注释
任何既不明显也不简短的公共功能必须注释
无论长度或复杂度如何，库中的任何函数都需要注释

Good code has lots of comments, bad code requires lots of comments -- Dave Thomas and Andrew Hunt

命名规范

简洁
缩略词全大写，例外：位于开头且不需要导出，则缩略词全小写。ServerHTTP、xmlHTTPRequest
变量距离被使用的地方越远，则需要携带越多的上下文信息（特别是全局变量）

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

函数命名

函数名不要携带包名的上下文信息，因为包名和函数名总是一起出现。如果再次携带则属于冗长内容。
简短
名为foo的包返回类型Foo时，可以省略类型信息，这不会导致歧义
名为foo的包返回类型T≠foo时，可以在函数名中加入T类型信息

package命名

只由小写字母，无大写字母和下划线
简短
不要与标准库同名

尽量满足：

不使用常用变量名，如使用bufio而不是buf
使用单数而不是复数，如encoding而不是encodings
谨慎使用缩写。例如fmt比format更简短

控制流程

保持正常流程清晰

// bad
if foo {
   return err
} else {
   return nil
}

// good
if foo {
   return err
}
return nil

优先处理错误情况，特殊情况，尽早返回或继续循环来减少嵌套。避免正常情况被嵌套过深。

// bad
err := doSomething()
if err== nil {
    err := doAnotherThing()
    if err == nil {
        return nil // normal case
    }
    return err
}
return err

// good
err := doSomething()
 if err!= nil {
     return err
 }
err := doAnotherThing()
if err != nil {
    return err
}
return nil // normal case

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

错误和异常处理

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

简单错误

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

错误的wrap和unwrap

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

if err != nil {
    return fmt.Errorf("reading srcfiles list: %w", err)
}

Go1.13在errors中新增了三个新API和一个新的format关键字，分别是errors.Is errors.As, errors.Unwrap 以及fmt.Errorf的%w。

如果项目运行在小于Go1.13的版本中，导入golang.org/x/xerrors来使用

错误判定

判定一个错误是否属于特定错误。error.Is不同于使用==，使用该方法可以判定错误链上的所有错误是否含有特定的错误。
在错误链上获取特定种类的错误，使用errors.As

panic

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

recover

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

defer func(){
    if e := recover( ); e !=nil {
        f = nil
        err = fmt.Errorf("gitfs panic: %v \n%s"，e，debug.Stack())
    }
}()

性能优化建议

简介

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

避免常见的性能陷阱可以保证大部分程序的性能

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

benchmark

go test -bench=.-benchmem GOMAXPROCS在1.5版本后，默认值为cpu核数pkg.go.dev/runtime#GOM…

性能优化建议-

slice

预分配内存尽可能在使用make()初始化切片时提供容量信息

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

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

map

预分配内存尽可能在使用make()初始化map时提供容量信息

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

使用strings.Builder

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

func PreStrBuilder(n int，str string) string {
    var builder strings.Builder
    builder.Grow(n * len(str))
    for i := 0; i < n; i++ {
        builder.WriteString(str)
    }
    return builder.String() 
}

func PreByteBuffer(n int, str string) string {
    buf := new(bytes.Buffer)
    buf.Grow(n * len(str))
    for i := 0; i < n; i++ {
        buf.WriteString(str)
    }
    return buf.String()
}

使用空结构体节省内存

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

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

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

使用atomic包

通常比加锁效率高

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

三、性能调优：

性能调优原则
- 要依靠数据不是猜测
- 要定位最大瓶颈而不是细枝末节
- 不要过早优化（产品迭代很快，早期的代码和使用量可能即使不优化也完全不影响）
- 不要过度优化（特定的优化手段可能阻碍功能变更/功能变更后原有优化不再可行）

性能分析工具pprof

可以知道应用在什么地方耗费了多少 CPU、memory 等运行指标
pprof 是用于可视化和分析性能分析数据的工具

pprof

排查 CPU 问题

命令行分析
go tool pprof "http://localhost:6060/debug/pprof/profile?seconds=10"

top

flat: 当前函数本身的执行耗时
flat%: flat 占CPU总时间的比例sum%上面每一行的flat%总和
cum: 指当前函数本身加上其调用函数的总耗时
cum%: cum占CPU总时间的比例 Q&A:
什么情况下Flat == Cum? 函数中没有调用其他函数
什么情况下Flat == 0? 函数只调用了其他函数

list

根据指定的正则查找代码 QQ截图20220512084818.png

web

排查堆内存问题

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

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

排查协程问题

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

火焰图Flame Graph

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

排查锁问题

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

排查阻塞问题

go tool pprof -http=:8080 "http://localhost:6060/debug/pprof/block"

采样过程和原理

CPU 采样
堆内存采样
协程和系统线程采样
阻塞操作和锁竞争采样

「高质量编程与性能调优实战」学习笔记 ｜ 青训营