这是我参与「第五届青训营 」伴学笔记创作活动的第 3 天，本次课程是关于高质量编程和性能调优的，我认为这一步十分重要，下面是我本次课程的收获

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

1.1 高质量编程

1.1.1 简介

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

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

编程原则

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

• 简单性

  • 消除“多余的复杂性”，以简单清晰的逻辑编写代码
  • 不理解的代码无法修复改进

• 可读性

  • 代码是写给人看的，而不是机器
  • 编写可维护代码的第一步是确保代码可读

• 生产力

  • 团队整体工作效率非常重要

1.1.2 编码规范

分为以下几点

• 代码格式
• 注释
• 命名规范
• 控制流程
• 错误和异常处理

1.1.3 编码规范-注释

• 注释应该做的

  • 注释应该解释代码作用

    适合注释公共符号

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

    适合注释实现过程

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

    适合注释代码的外部因素、提供额外上下文

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

    适合解释代码的限制条件

• 公共符号始终要注释

  • 包中声明的每个公共的符号：变量、常量、函数以及结构都需要添加注释
  • 任何既不明显也不简短的公共功能必须予以注释
  • 无论长度或复杂程度如何，对库中的任何函数都必须进行注释
  • 有一个例外，不需要注释实现接口的方法

1.1.4 编码规范-代码格式

• 推荐使用gofmt自动格式化代码，在一些开发工具中都内置了gomat
• goimports也可以进行代码格式化优化，相比gofmt还可以自动增删依赖的包引用、将依赖包按字母排序并分类

1.1.5 编码规范-命名规范

variable的命名规范

• 简洁胜于冗长

// bad
for index := 0; index < 5; index++ {
}
// good
for i := 0; i < 5; i++ {
}

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

  • 例如是ServeHTTP而不是ServeHttp
  • xmlHTTPRequest和XMLHTTPReques都可以，需要看使用需求

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

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

function命名规范

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

package命名规范

• 只由小写字母组成，不包含大写字母和下划线等字符
• 简短并包含一定的上下文信息，例如schema、task
• 不要与标准库同名，例如不要 使用fmt、strings
• 不要使用常用变量名作为包名，例如使用bufio而不是buf
• 使用单数而不是复数，例如使用enconding而不是encondings
• 谨慎使用缩写

1.1.6 编码规范-控制流程

避免嵌套，保证正常流程流程清晰

• 如果两个分支中都包含return语句，则可以去除冗余的else

// bad
if foo {
    return
} else {
    return nil
}
// good
if foo {
    retun
}
return

尽量保证正常代码路径为最小缩进

• 优先处理错误情况/特殊情况，尽早返回或继续循环来减少嵌套

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

// good
func OneFunc() error {
    if err := doSomething(); err != nil {
        return err
    }
    if err := doAnotherThing(); err != nil {
        return err
    }
    return nil
}

小结

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

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

简单错误

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

func defaultCheckRedirect(req *Request, via[]*Request) error {
    if len(via) >= 10 {
        return errors.New("stopped after 10 redirects")
    }
    return nil
}

复杂错误

错误的Wrap和Unwarp

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

list, _, err := c.GetBytes(cache.Subkey(a.actionID), "srcfiles"))
if err != nil {
    return fmt.Errorf("reding srcfiles list:%w", err)
}

错误判定

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

data, err = lockedfile.Read(targ)
if errors.Is(err, fs.ErrNotExist) {
    return []byte{}, nil
}
return data, err

• 在错误链上获取特定种类的错误，使用errors.As

if _, err := os.Open("non-existing"); err != nil {
    var pathError *fs.PathError
    if errors.As(err, &pathError) {
        fmt.Println("Failed at path:", patchError.Path)
    }
    fmt.Println(err)
}

panic

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

recover

• recover只能在被defer的函数中使用
• 嵌套无法生效
• 只在当前goroutine生效
• defer的语句是后进先出

func (s *ss) Token(skipSpace bool, f func(rune) bool)
(tok []bute, err error) {
    defer func() {
        if e := recover(); e != nil {
            if se, ok := e.(scanError); ok {
                err = se.err
            } else {
                panic(e)
            }
        }
    }()
}

• 如果需要更多的上下文信息，可以recover后再log中记录当前的调用栈

func (t *treeFS) Open(name stirng) (f fs.File, err error) {
    defer func() {
        if e := recover(); e != nil {
            f = nil
            err = fmt.Errorf("gitfs panic: %v\n%s", e, debug.Stack())
        }
    }()
}

小结

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

1.2 性能优化建议

1.2.1 简介

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

1.2.2 Benckmark

如何使用

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

func Fib(n int) {
    if n < 2 {
        return n
    }
    return Fib(n-1) + Fib(n-2)
}
func BenchmarkFib10(b, *testing.B) {
    for n := 0; n < b.N; n++ {
        Fib(10)
    }
}

结果分别为测试函数名-核数、一共执行多少次、每次执行花费的时间

1.2.3 Slice

slice预分配内存

• 尽可能在使用make()初始化切片时提供容量信息
• 此外预分配容量比不预分配的执行效率有大大的提升

// bad
func BenchmarkNoPreAlloc(b *testing.B) {
    data := make([]int, 0)
    for i := 0; i < b.N; i++ {
        data = append(data, i)

    }
// good
func BenchmarkPreAlloc(b *testing.B) {
    data := make([]int, 0, b.N)
    for i := 0; i < b.N; i++ {
        data = append(data, i)
    }
}

执行结果

提前分配容量效率高的原因

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

  • 包括数组指针
  • 片段长度
  • 片段的容量（不改变内存分配情况下的最大长度）

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

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

存在的问题—大内存未释放

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

• 场景

  • 原切片较大，代码在原切片基础上新建小切片
  • 原底层数组在内存中有引用，得不到释放

• 可使用copy替代re-slice

以下代码可以证明

1.2.4 Map

与Slice一致，预分配让性能大大提升

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

1.2.5 字符串处理

使用strings.Builder

• 常见的字符串拼接方式

func BenchmarkPlus(b *testing.B) {
    str := "hello"
    s := ""
    for i := 0; i < b.N; i++ {
        s += str
    }
}

func BenchmarkStrBuilder(b *testing.B) {
    var builder strings.Builder
    str := "hello"
    for i := 0; i < b.N; i++ {
        builder.WriteString(str)
    }
}

func BenchmarkByteBuffer(b *testing.B) {
    str := "hello"
    buf := new(bytes.Buffer)
    for i := 0; i < b.N; i++ {
        buf.WriteString(str)
    }
}

结果

使用+拼接性能最差，strings.Buffer最快

性能分析

• 字符串在Go语言中是不可变类型，占用内存大小是固定的
• 使用+每次都会重新分配内存
• strings.Builder， bytes.Buffer底层都是[]byte数组
• 内存扩容策略不需要每次都重新分配内存

strings.Builder最快的原因

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

此外字符串拼接也可以使用Grow函数进行预分配容量，能进一步提升拼接性能

1.2.6 空结构体

• 使用空结构体struct{}实例不占据任何的内存空间

• 可作为各种场景的占位符使用

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

func BenchmarkEmptyStructMap(b *testing.B) {
    m := make(map[int]struct{})
    for i := 0; i < b.N; i++ {
        m[i] = struct{}{}
    }
}

func BenchmarkBoolMap(b *testing.B) {
    m := make(map[int]bool)
    for i := 0; i < b.N; i++ {
        m[i] = false
    }
}

结果

性能分析

• 实现Set，可以用map代替
• 在该场景下，只需要map的key，所以使用空结构体是最适合的

1.2.7 atomic包

type atomicCounter struct {
    i int32
}

func AtomicAddOne(c *atomicCounter) {
    atomic.AddInt32(&c.i, 1)
}

type mutexCounter struct {
    i int32
    m sync.Mutex
}

func MutexAddOne(c *mutexCounter) {
    c.m.Lock()
    c.i++
    c.m.Lock()
}

分析

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

小结

• 避免常见的性能陷阱就可以保证大部分程序的性能
• 不要太刻意的追求程序的性能，可能会适得其反导致代码晦涩难懂
• 在满足正确可靠、简洁清晰的要求下提高程序性能

1.3 性能调优实战

1.3.1 简介

性能调优原则

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

1.3.2 性能分析工具pprof

pprof是用于可视化和分析性能分析数据的工具

1.3.3 pprof-功能简介

1.3.4 pprof-排查实战

克隆项目

地址：github.com/wolfogre/go…

浏览器打开localhost:6060/debug/pprot查看指标

CPU

• 任务管理器

通过上述可以看到CPU占用非常高达到了17%

• pprof工具

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

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

flat：当前函数本身的执行耗时

flat%：flat占CPU总时间的比例

sum%：上面每一行的flat%总和

cum：当前函数本身加上其调用函数的总耗时

cum%：cum占CPU总时间的比例

结果

通过以上数据，可目视animal/felidae/tiger的Eat函数耗时占比非常高，可以得出问题就出现在这里

解决

输入list Eat查找这个函数具体是什么地方出了问题

可以看出是24行的一个100亿次的空循环造成的，注释掉然后重新运行，查看任务管理器结果

可以看出CPU占用率几乎为0了，说明解决成功

• pprof可视化工具

以上方式虽然解决了CPU占用过高的情况，但是还是存在内存占用过高的情况，下面我使用pprof的可视化工具来解决

命令行输入go tool pprof -http=:8080 "http://localhost:6060/debug/pprof/heap"会跳转到可视化页面

通过Graph、Top、Source视图逐步分析找到原因

根据以上定位，我发现Mouse.Steal()函数的50行会不断的往Buffer加1MB内存，直到Buffer达到1GB为止，注释掉重新运行查看效果

内存占用率的确降低了，所以说明解决成功，但是这还远远没有结束，还有其他的指标需要查看

其他指标

alloc_objects：程序累计申请的对象数

alloc_space：程序累计申请的内存大小

inuse_objects：程序当前持有的对象数

inuse_space：程序当前占用的内存大小

alloc_space

通过以上分析可以看出dog.Run()函数的第43行，会反复申请16MB的空间，因为GC机制所以在inuse里不会表现出来，定位到就是这里出了问题，注释掉重新运行

通过可视化的Top视图可以看出解决了这个问题

gouroutine

对于这个小程序来说，这个协程量级已经很大了，所以我进行性能分析排查是哪里出的问题

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

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

因为调用关系图太长不好定位，我选择用火焰图分析，可以看出

wolf.Drink()函数占用CPU时间非常的，所以在Source视图下搜索wolf定位代码问题

可以看出34行等到了30秒才退出了，注释掉重新运行查看结果

结果可以得出协程数量大大减少，解决了这个问题

mutex

可以看出还存在一个mutex，所以我可以继续做性能分析来解决这个问题

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

通过Source视图中发现存在阻塞解锁操作，注意掉这一行查看效果

很明显，我的分析正确解决了这个问题

block

上面我发现还有一个阻塞，下面用同样的方法进行分析并观察结果

命令行输入go tool pprof -http=:8080 "http://localhost:6060/debug/pprof/block"

通过调用关系图可以得出这个锁不需要处理，是程序运行的一个部分

1.3.5 pprof-采样过和原理

CPU

过程

• 采样对象：函数调用和它们占用的时间
• 采样率：100次/秒，固定量
• 采样时间：从手动启动到手动结束

原理

• 操作系统

  每10ms向进程发送一次SIGPROF信号

• 进程

  每次接收到SIGPROF会记录调用堆栈

• 写缓冲

  每100ms读取已经记录的调用栈并写入输出流

Heap-堆内存

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

Gouroutine & ThreadGreate

• Goroutine

  记录所有用户发起且在运行中的gorountine（是入口非runtime开头）runtime.main调用栈信息

• ThreadGreate

  记录程序创建的所有系统线程信息

Block & Mutex

阻塞操作

• 采样阻塞操作的次数和耗时
• 采样率：阻塞耗时超过阈值的才会被记录，1为每次阻塞均记录

锁竞争

• 采样争抢锁的次数和耗时
• 采样率：只记录固定比例的锁操作，1为每次加锁均记录

1.4 性能调优案例

1.4.1 简介

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

1.4.2 业务服务优化

基本概念

• 服务：能单独部署，承载一定功能的程序
• 依赖：ServiceA的功能实现依赖ServeceB的响应结果，称为ServiceA依赖ServiceB
• 调用链路：能支持一个接口请求的相关服务集合以及其相互之间的依赖关系
• 基础库：公共的工具包，中间件

流程

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

建立服务性能评估手段

• 服务性能评估方式

  • 单独的benchmark无法满足复杂的业务逻辑分析
  • 不同负载情况下性能表现差异

• 请求流量构造

  • 不同请求参数覆盖逻辑不同
  • 线上真实流量情况

• 压测范围

  • 单机压测
  • 集群压测

• 性能数据采集

  • 单机性能数据
  • 集群性能数据

分析性能数据，定位性能瓶颈

• 使用库不规范
• 高并发场景优化不足

重点优化项改造

• 正确是基础

• 响应数据diff

  • 线上请求数据录制回放
  • 新旧逻辑接口数据diff

优化效果验证

• 重复压测验证

• 上线评估优化效果

  • 关注服务监控
  • 逐步放量
  • 收集性能数据

进一步优化，服务链路分析

• 规范上游服务调用接口，明确场景需求
• 分析链路，通过业务流程优化提升服务性能

1.4.3 基础库优化

AB实验SDK的优化

• 分析基础库核心逻辑和性能瓶颈

  • 设计完善改造方案
  • 数据按需获取
  • 数据序列化协议优化

• 内部压测验证

• 推广业务服务落地验证

1.4.4 Go语言优化

编译或运行时优化

• 优化内存分配策略
• 优化代码编译流程
• 内部压测验证
• 推广业务服务落地验证

优点在于接入简单，只需要调整编译配置，同时通用性很强

总结

• 性能调优的原则

  一定要依靠数据而不是猜测

• 性能分析工具pprof

  必须熟练使用pprof工具排查性能问题并了解其基本原理

• 性能调优二原则

  • 保证正确性
  • 定位主要瓶颈