Go高质量编码与性能优化建议｜ 青训营笔记

Lenox
101 阅读9分钟

Go高质量编码与性能优化建议

这是我参与「第五届青训营 」伴学笔记创作活动的第 2 天

高质量编码

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

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

编程原则

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

简单性

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

可读性

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

生产力

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

编码规范

代码格式

gofmt：Go 语言官方提供的工具，能自动格式化 Go 语言代码为官方统一风格常见IDE都支持方便的配置

goimports：也是 Go 语言官方提供的工具，实际等于 gofmt 加上依赖包管理，自动增删依赖的包引用、将依赖包按字母序排序并分类

注释

  • 公共符号始终要注释 包中声明的每个公共的符号变量、常量、函数以及结构都需要添加注释

  • 任何既不明显也不简短的公共功能必须予以注释

  • 无论长度或复杂程度如何对库中的任何函数都必须进行注释

  • 例外：不需要注释实现接口的方法。

注释应该做的事情：

  • 注释应该解释代码作用

    • 注释公共符号

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

    • 解释实现过程

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

    • 解释代码的外部因素
    • 提供额外上下文

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

    • 解释代码的限制条件

总结

  • 代码是最好的注释
  • 注释应该提供代码未表达出的上下文信息

命名规范

variable

  • 简洁胜于冗长

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

    • 例如使用ServeHTTP而不是ServeHttp
    • 使用XMLHTTPRequest或者xmlHTTPRequest

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

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

  • 例子：

    //bad
for index := 0; index < len(s); index++ {
    //do something
}
//good
for i:=0; i < len(s); i++ {
    //do something
}

    i和index的作用域范围仅限于for循环内部时，index的额外冗长几乎没有增加对于程序的理解

    //Good
func (c *Client) send(req *Request, deadline time.Time)
​
//Bad
fun (c *Client) send(req *Request, t time.Time)

    将deadline替换成t降低了变量名的信息量，t常代指任意时间，而deadline指截止时间，有特定的含义

function

  • 函数名不携带包名的上下文信息，因为包名和函数名总是成对出现的

  • 函数名尽量简短

  • 当名为foo的包某个函数返回类型Foo时，可以省略类型信息而不导致歧义

  • 当名为foo的包某个函数返回类型T时(T并不是Foo)，可以在函数名中加入类型信息

  • 例子：http包中创建服务的函数如何命名更好？

    func Serve(I net.Listener, handler Handler) error
func ServeHTTP(I net.Listener, handler Handler) error

    考虑到调用的时候可能是HTTP包.Serve或者是HTTP包.ServeHTTP，后者明显冗余。

package

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

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

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

小结

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

控制流程

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

    //Bad
if foo {
    return X
} else {
    return nil
}
//Good
if foo {
    return x
}
return nil

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

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

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

总结

  • 线性原理，处理逻辑尽量走直线，避免复杂的嵌套分支
  • 提高代码的可读性

错误和异常处理

简单错误

  • 简单的错误指的是仅出现一次的错误，且在其他地方不需要捕获该错误

  • 优先使用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和Unwrap

  • 错误的Wrap实际上是提供了一个error嵌套另一个error的能力，从而生成一个error的跟踪链

  • 在fmt.Errorf中使用：%w关键字来将一个错误关联至错误链中

    list, _, err := c.GetBytes(cache.Subkey(a.actionID, "srcfiles"))
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 来使用。以下语法均已 Go1.13 作为标准。

错误判定

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

    if _, err := os.Open("non-existing"); err != nil {
    if errors.Is(err, fs.ErrNotExist) {
        fmt.Println("file does not exist")
    } else {
        fmt.Println(err)
    }
}

panic

  • 不建议在业务代码中使用panic

  • 调用函数不包含recover会造成程序崩溃

  • 若问题可以被屏蔽或解决，建议使用error代替panic

  • 当程序启动阶段发生不可逆转的错误时，可以在init或main函数中使用panic

    func main() {
    // ...
    ctx, cancel := context.WithCancel(context.Background())
    client, err := sarama.NewConsumerGroup(strings.Split(brokers, ","), group, config)
    if err != nil {
        log.Panicf("Error creating consumer group client: %v", err)
    }
    // ...
}

recover

  • recover只能在被defer的函数中使用,嵌套无法生效,只在当前goroutine生效

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

  • defer语句会在函数返回前调用，多个defer语句是后进先出

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

小结

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

性能优化建议

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

如何使用

  • 性能表现需要实际数据衡量

  • Go语言提供了支持基准性能测试的benchmark工具

    go test -bench=. -benchemem
    • 性能对比测试代码，可参考 RaymondCode/go-practice (github.com)
    • func Fib(n int) int {
    if n < 2 {
        return n
    }
    return Fib(n-1) + Fib(n-2)
}
​
import "testing"
​
// BenchmarkFib10 run 'go test -bench=. -benchmem' to get the benchmark result
func BenchmarkFib10(b *testing.B) {
    // run the Fib function b.N times
    for n := 0; n < b.N; n++ {
        Fib(10)
    }
}

    • 首先要初始化一下mod文件

      F:\go_workspace\go-practice-main\start>go mod init start
go: creating new go.mod: module start
go: to add module requirements and sums:
        go mod tidy

      mod文件内容

      module start
​
go 1.19

      执行测试

      F:\go_workspace\go-practice-main\start>go test -bench=. -benchmem
goos: windows
goarch: amd64
pkg: start
cpu: 12th Gen Intel(R) Core(TM) i5-12500H
BenchmarkFib10-16        6027478               203.2 ns/op             0 B/op          0 allocs/op
PASS
ok      start   1.529s

slice预分配内存

  • 在尽可能的情况下，在使用 make() 初始化切片时提供容量信息，特别是在追加切片时

  • 原理

    • ueokande.github.io/go-slice-tr…

    • 切片本质是一个数组片段的描述，包括了

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

    • 切片操作并不复制切片指向的元素，创建一个新的切片会复用原来切片的底层数组，因此切片操作是非常高效的

    • 切片有三个属性，指针(ptr)、长度(len) 和容量(cap)。append 时有两种场景：

    • 当 append 之后的长度小于等于 cap，将会直接利用原底层数组剩余的空间

    • 当 append 后的长度大于 cap 时，则会分配一块更大的区域来容纳新的底层数组

      image-20230118134416522

    • 因此，为了避免内存发生拷贝，如果能够知道最终的切片的大小，预先设置 cap 的值能够获得最好的性能

    • func NoPreAlloc(size int) {
    data := make([]int, 0)
    for k := 0; k < size; k++ {
        data = append(data, k)
    }
}
​
func PreAlloc(size int) {
    data := make([]int, 0, size)
    for k := 0; k < size; k++ {
        data = append(data, k)
    }
}

      测试

      F:\go_workspace\go-practice-main\benchslice>go test -bench=. -benchmem
goos: windows
goarch: amd64
pkg: start
cpu: 12th Gen Intel(R) Core(TM) i5-12500H
BenchmarkNoPreAlloc-16           2743500               464.3 ns/op          2040 B/op          8 allocs/op
BenchmarkPreAlloc-16             7555752               161.5 ns/op           896 B/op          1 allocs/op
PASS
ok      start   4.580s

  • 另一个陷阱：大内存得不到释放

    • 在已有切片的基础上进行切片，不会创建新的底层数组。因为原来的底层数组没有发生变化，内存会一直占用，直到没有变量引用该数组

    • 因此很可能出现这么一种情况，原切片由大量的元素构成，但是我们在原切片的基础上切片，虽然只使用了很小一段，但底层数组在内存中仍然占据了大量空间，得不到释放

    • 推荐的做法，使用 copy 替代 re-slice

      func testGetLast(t *testing.T, f func([]int) []int) {
	result := make([][]int, 0)
	for k := 0; k < 100; k++ {
		origin := generateWithCap(128 * 1024) // 1M
		result = append(result, f(origin))
	}
	printMem(t)
	_ = result
}

func GetLastBySlice(origin []int) []int {
	return origin[len(origin)-2:]
}

func GetLastByCopy(origin []int) []int {
	result := make([]int, 2)
	copy(result, origin[len(origin)-2:])
	return result
}

func TestLastBySlice(t *testing.T) {
	testGetLast(t, GetLastBySlice)
}

func TestLastByCopy(t *testing.T) {
	testGetLast(t, GetLastByCopy)
}

      测试结果：

      F:\go_workspace\go-practice-main\benchslice>go test -run=. -v
=== RUN   TestLastBySlice
    slice_test.go:44: 2.25 MB
--- PASS: TestLastBySlice (0.31s)
=== RUN   TestLastByCopy
    slice_test.go:44: 2.25 MB
--- PASS: TestLastByCopy (0.20s)
PASS
ok      start   0.608s
    map 预分配内存

    • 原理

      • 不断向 map 中添加元素的操作会触发 map 的扩容

      • 根据实际需求提前预估好需要的空间

      • 提前分配好空间可以减少内存拷贝和 Rehash 的消耗

        func NoPreAlloc(size int) {
	data := make(map[int]int)
	for i := 0; i < size; i++ {
		data[i] = 1
	}
}

func PreAlloc(size int) {
	data := make(map[int]int, size)
	for i := 0; i < size; i++ {
		data[i] = 1
	}
}

        测试：

        F:\go_workspace\go-practice-main\benchmap>go test -bench=. -benchmem 
goos: windows
goarch: amd64
pkg: benchmap
cpu: 12th Gen Intel(R) Core(TM) i5-12500H
BenchmarkNoPreAlloc-16             21882             53955 ns/op           86555 B/op         64 allocs/op
BenchmarkPreAlloc-16               49760             23082 ns/op           41097 B/op          6 allocs/op
PASS
ok      benchmap        4.401s
    • 使用 strings.Builder

      • 常见的字符串拼接方式

          func Plus(n int, str string) string {
	s := ""
	for i := 0; i < n; i++ {
		s += str
	}
	return s
}

        • strings.Builder

          func StrBuilder(n int, str string) string {
	var builder strings.Builder
	for i := 0; i < n; i++ {
		builder.WriteString(str)
	}
	return builder.String()
}

        • bytes.Buffer

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

      • strings.Builder 最快，bytes.Buffer 较快，+ 最慢

      • 原理

        • 字符串在 Go 语言中是不可变类型，占用内存大小是固定的，当使用 + 拼接 2 个字符串时，生成一个新的字符串，那么就需要开辟一段新的空间，新空间的大小是原来两个字符串的大小之和
        • strings.Builder，bytes.Buffer 的内存是以倍数申请的
        • strings.Builder 和 bytes.Buffer 底层都是 []byte 数组，bytes.Buffer 转化为字符串时重新申请了一块空间，存放生成的字符串变量，而 strings.Builder 直接将底层的 []byte 转换成了字符串类型返回

        测试：

        F:\go_workspace\go-practice-main\benchstring>go test -bench=. -benchmem
goos: windows
goarch: amd64
pkg: benchstring
cpu: 12th Gen Intel(R) Core(TM) i5-12500H
BenchmarkPlus-16                    2911            490489 ns/op         3212603 B/op        999 allocs/op
BenchmarkStrBuilder-16            262308              4522 ns/op           24824 B/op         14 allocs/op
BenchmarkByteBuffer-16            190588              6123 ns/op           22464 B/op          9 allocs/op
BenchmarkPreStrBuilder-16         438807              2714 ns/op            6144 B/op          1 allocs/op
BenchmarkPreByteBuffer-16         298934              4132 ns/op           12288 B/op          2 allocs/op
PASS
ok      benchstring     7.620s
    使用空结构体节省内存

    • 空结构体不占据内存空间，可作为占位符使用

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

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

        • 节省资源
        • 空结构体本身具备很强的语义，即这里不需要任何值，仅作为占位符
      func EmptyStructMap(n int) {
	m := make(map[int]struct{})

	for i := 0; i < n; i++ {
		m[i] = struct{}{}
	}
}

func BoolMap(n int) {
	m := make(map[int]bool)

	for i := 0; i < n; i++ {
		m[i] = false
	}
}

    • 比如实现简单的 Set

      • Go 语言标准库没有提供 Set 的实现，通常使用 map 来代替。对于集合场景，只需要用到 map 的键而不需要值，即使是将map的值设置为bool类型，也会多占据1个字节空间

    • 测试：

      F:\go_workspace\go-practice-main\benchstruct>go test -bench=. -benchmem    
goos: windows
goarch: amd64
pkg: benchstruct
cpu: 12th Gen Intel(R) Core(TM) i5-12500H
BenchmarkEmptyStructMap-16          2745            433987 ns/op          389437 B/op        255 allocs/op
BenchmarkBoolMap-16                 2334            455816 ns/op          427602 B/op        320 allocs/op
PASS
ok      benchstruct     3.507s
    使用 atomic 包

    • 原理

      • 锁的实现是通过操作系统来实现，属于系统调用，atomic 操作是通过硬件实现的，效率比锁高很多

      • sync.Mutex 应该用来保护一段逻辑，不仅仅用于保护一个变量

      • 对于非数值系列，可以使用 atomic.Value，atomic.Value 能承载一个 interface{}

        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.Unlock()
}

        测试：

        F:\go_workspace\go-practice-main\benchatomic>go test -bench=. -benchmem
goos: windows
goarch: amd64
pkg: benchatomic
cpu: 12th Gen Intel(R) Core(TM) i5-12500H
BenchmarkAtomicAddOne-16        100000000               10.51 ns/op            4 B/op          1 allocs/op
BenchmarkMutexAddOne-16         58662964                20.13 ns/op           16 B/op          1 allocs/op
PASS
ok      benchatomic     4.083s
    总结
    • 避免常见的性能陷阱可以保证大部分程序的性能
    • 针对普通应用代码，不要一味地追求程序的性能，应当在满足正确可靠、简洁清晰等质量要求的前提下提高程序性能
avatar
文章
阅读
粉丝