【超万字详细笔记】高质量编程与性能调优实战（上）（3） ｜ 青训营笔记

Frank星子
200 阅读16分钟

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

学习目标

  • 如何编写更简洁清晰的代码

    在工作中，编程是团队合作的工程，好的代码让其他人更容易在你的基础上开发，同时出问题的概率更低，大家更乐于与你合作，也让团队更高效，另外在面试的时候，也有编码环节，能不能用代码清晰的表达出你的思路，让面试官额外加分

  • 常用 Go 语言程序优化手段

    每种语言都有自己的特性，本文将介绍 Go 语言的特性和性能优化的手段。

  • 熟悉 Go 程序性能分析工具

  • 了解工程中性能优化的原则和流程

1. 高质量编程

1.1 简介

什么是高质量

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

高质量代码的标准：

  • 正确性：是否考虑各种边界条件，错误的调用是否能够处理
  • 可靠性：异常情况或者错误的处理策略是否明确，依赖的服务出现异常是否能够处理
  • 简洁：逻辑是否简单，后续调整功能或新增功能是否能够快速支持
  • 清晰：其他人在阅读理解代码的时候是否能清楚明白，重构或者修改功能是否不会担心出现无法预料的问题

编程原则

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

简单性

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

可读性

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

生产力

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

​ —— Go 语言开发者 Dave Cheney

1.2 编码规范

如何编写高质量的 Go 代码

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

1.2.1 代码格式

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

  • gofmt

    • Go 语言官方提供的工具，能自动格式化 Go 语言代码为官方通用风格
    • 常见IDE都支持方便地配置

  • goimports

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

1.2.2 注释

注释应该做的

  • 解释代码作用
  • 解释代码如何做的
  • 解释代码实现的原因
  • 解释代码什么情况会出错

Good code has lots of comments, bad code requires lots of comments.

好的代码有很多注释，坏代码需要很多注释

—— Dave Thomas and Andrew Hunt

1.2.2.1 注释应该解释代码作用

这种注释适合说明公告符号，比如对外提供的函数注释描述它的功能和用途. 只有在函数的功能简单而明显时才能省略这些注释(例如, 简单的取值和设值函数)。

  • 示例

    // Open opens the named file for reading. If successful, methods on the returned file can be used
// for reading; the associated file descriptor has mode O_RDONLY
// If there is an error, it will be of type *PathError
func Open(name string) (*file, error) {
    return OpenFile(name, O_RDONLY, 0)
}

  • 反例（对显而易见的内容进行说明）

    // Returns true if the table cannot hold any more entries
func IsTableFull() bool

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

对代码中复杂的，并不明显的逻辑进行说明，适合注释实现过程

  • 示例

    // Add the Referer header from the most recent
// request URL to the new one, if it's not https->http:
if ref := refererForURL(reqs[len(reqs)-1].URL, req.URL); red != "" {
    req.Header.Set("Referer", ref)
}

  • 反例（描述的是显而易见的流程）

    // Process every element in the list
for e := range elements {
    process(e)
}

PS：注意不要用自然语言直接翻译代码作为注释，信息冗余还好，有时候表述不一定和代码一致。

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

适合解释代码的外部因素。

这些因素在脱离上下文的情况下很难理解。

在下面的示例中，有一行 shouldRedirect = false 的语句，如果没用注释，很难明白为什么会设置成false 。所以注释里提到了这么做的原因，并给出上下文说明。

  • 示例

    下面的注释介绍了解析时区字符串的流程，同时对可能遇到的不规范字符串进行了说明。

    switch resp.StatusCode {
// ...
case 307, 308:
    redirectMethod = reqMethod
    shouldRedirect = true
    includeBody = true
    
    if ireq.GetBody == nil && ireq.outgoingLength() != 0 {
        // We had a request body, and 307/308 require re-sending it, but Getbody is not defined.
        // So just return this response to the user instead of an error, like we did in Go 1.7 
        // and earlier
        shouldRedirect = false
    }

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

注释应该提醒使用者一些潜在的限制条件或者会无法处理的情况。

例如函数的注释中可以说明是否存在性能隐患，输入的限制条件，可以存在哪些错误情况，让使用者无需了解实现细节。

  • 示例

    下面的注释介绍了解析时区字符串的流程，同时对可能遇到的不规范字符串处理进行了说明。

    // parseTimeZone parses a time zone string and returns its length. Time zones are human-generated and 
// unpredictable. We can't do prase there must be a time zone at the beginning of the string, so it's 
// almost always true that there's one there. We look at the beginning of the string for a run of 
// upper-case letters.
// If there are more than 5, it's an error
// If there are 4 or 5 and the last is a T, it's a time zone.
// If there are 3, it's a time zone.
// Otherwise, other than special cases, it's not a time zone.
// GMT is special because it can have an hour offset.
func parseTimeZone(value string) (length int, ok bool)

1.2.2.5 公共符号始终要注释

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

Google Style 指南中有两条规则、

  1. 任何既不明显也不简短的公共功能必须予以注释
  2. 无论长度或复杂程序如何，对库中的任何函数都必须进行注释

  • 示例1

    下面是一个公共函数的注释说明，结合了之前提到的规范，表述了函数的功能和如何工作的。

    // ReadAll reads from r until an error or EOF and returns the data it read.
// A successful call returns err == nil, not err == EOF, Because ReadAll is defined to read from src
// until EOF, it does not treat an EOF from Read as an error to be reported.
func ReadAll(r Reader) ([]byte, error)

  • 示例2

    这是 go 仓库中相对完整的代码块。

    由于 LimitReader 的功能和 LimitedReader 结构体都有注释说明， LimitedReader.Read 的功能遵循 LimitReader ，在前面的注释中已经有详细说明，所以 LimitedReader.Read 前面没有注释。

    // LimitReader returns a Reader that reads from r
// but stops with EOF after n bytes.
// The underlying implementation is a *LimitedReader.
func LimitReader(r Reader, n int64) Reader { return &LimitedReader{r, n}} }
​
// A LimitedReader reads from R but limits the amount of data returned to just N bytes.
// Each call to Read updates N to reflect the new amount remaining.
// Read returns EOF when N <= 0 or when the underlying R returns EOF.
type LimitedReader struct {
    R Reader // underlying reader
    N int64  // max bytes remaining
}
​
func (l *LimitedReader) Read(p []byte) (n int, err errror) {
    if l.N <= 0 {
        return 0, EOF
    }
    if int64(len(p)) > l.N {
        p = p[0:l.N]
    }
    n, err = l.R.Read(p)
    l.N -= int64(n)
    return
}

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

    下面的注释中没用提供有用的信息，没有告诉你这个方法做了什么。更糟糕的是它告诉你去看其他地方的文档。这种情况建议完全删除该注释。

    // Read implements the io.Reader interface
func (r *FileReader) Read(buf []byte) (int, error)

1.2.2.6 小结

  • 代码是最好的注释
  • 注释应该提供代码未表达出的上下文信息
  • 简洁清晰的代码对流程注释没有要求，但是对于为什么这么做，代码的相关背景，可以通过注释补充，提供有效信息，大家可以在工作中慢慢体会

1.2.3 命名规范

  • 简洁胜于冗长

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

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

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

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

1.2.3.1 循环变量

当 i 和 index 的作用域范围仅限于 for 循环内部时，index 的额外冗长几乎没用增加对于程序的理解，所以用更简单的 i 是更好的。

如果索引的作用域扩展，在循环外也会用到的时候，可以考虑更符合需求的名称。

// Bad
for index := 0; index < len(s); index++ {
    // dosomething
}
​
// Good
for i := 0; index < len(s); index++ {
    // dosomething
}

1.2.3.2 函数参数名称要易于理解

t 常代指任意时间，deadline 指截止时间，有特定的含义

将 t 替换成 deadline 增加了变量名的信息量，方便理解参数的功能。

函数提供给外部调用时，通过参数名更好地理解功能很有必要，可以节省时间。

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

1.2.3.3 函数命名

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

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

func Serve(l net.Listener, hander Hander) error

func ServeHTTP(l net.Listener, hander Hander) error

在调用http包的Server方法时，代码是http.Serve，携带有http包名，所以函数名无需添加包信息

1.2.3.4 包命名

  • 只由小写字母组成，不包含大写字母和下划线等字符
  • 简短并包含一定的上下文信息，例如 schema、task等
  • 不要与标准库同名，例如不要使用 sync 或者 strings
  • 需要用多个单词表达上下文的命名可以使用缩写，例如使用 strconv 而不是 stringconversion

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

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

包名也涉及到项目代码结构的划分和层次安排，具体名称不同项目会有细微差异，实际保持项目内风格统一。

1.2.3.5 小结

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

Good naming is like a good joke. If you have to explain it, it's not funny.

好的命名就像一个好笑话。如果你必须解释它，那就不好笑了。

—— Dave Cheney

1.2.4 控制流程

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

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

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

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

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

  • 反例

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

    问题：

    • 最常见的正常流程的路径被嵌套在两个 if 条件内
    • 成功的退出条件是 return nil，必须仔细匹配大括号才能发现
    • 函数最后一行返回一个错误，需要追溯到匹配的左括号，才能了解何时会触发错误
    • 如果后续正常流程需要增加一步操作，调用新的函数，则又会增加一层嵌套

  • 示例（上面的反例调整后）

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

    优点：

    • 从上到下就是正常流程的执行过程
    • 初步阅读代码时可以先忽略每一步的err的情况，对整体流程有更清晰的了解
    • 如果后续想排查问题可以针对具体某一步的错误详细分析
    • 如果后续正常流程新增操作，也是优先处理err情况，保持正常流程的统一

  • 示例2（Go 仓库中的代码示例）

    func (b *Reader) UnreadByte() error {
    if b.lastByte < 0 || b.r == 0 && b.w > 0 {
        return ErrInvalidUnreadByte
    }
    // b.r > 0 || b.w == 0
    if b.r > 0 {
        b.r--
    } else {
        // b.r == 0 || b.w == 0
        b.w = 1
    }
    b.buf[b.r] = byte(b.lastByte)
    b.lastByte = -1
    b.lastRuneSize = -1
    return nil
}

1.2.4.3 小结

  • 线性原理，处理逻辑尽量走直线，避免复杂的嵌套分支
  • 正常流程代码沿着屏幕向下移动
  • 提升代码可维护性和可读性
  • 故障问题大多出现在复杂的条件语句和循环语句中，在维护这种逻辑时，添加功能会变成高风险的操作，很容易遗漏部分条件导致问题。因此要避免复杂的条件和循环语句。

1.2.5 错误和异常处理

1.2.5.1 简单错误

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

优先使用 error.New 来创建匿名变量来直接表示简单错误

如果有格式化的需求，使用 fmt.Errorf

示例：

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

1.2.5.2 错误的 Warp 和 Unwarp

错误的 Warp 实际上是提供给了一个 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)
}

Go 1.13 在 errors 中新增了三个新的 API 和一个新的 format 关键字，分别是 errors.Is, errors.As, errors.Unwrap 以及 fmt.Errorf 的 %w。如果项目运行在小于 Go 1.13 的版本中，导入 golang.org/x/xerrors 来使用

1.2.5.3 错误判定

  • 判定一个错误是是否为特定错误，使用 errors.Is

    不同于使用 == ，使用该方法可以判定错误链上的所有错误是否含有特定的错误

    data, err = lockedfile.Read(targ)
if errors.Is(err, fs.ErrNotExist) {
    // Treat non-existent as empty, to bootstrap the "latest" file
    // the first time we connect to a given database
    return []byte{}, nil
}
return data, err

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

    errors.As 和 errors.Is 的区别在于 As 会提取出调用链中指定类型的错误，并将错误赋值给定义好的变量，方便后续处理

    示例中是把问题的 path 打印出来了

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

1.2.5.4 panic

在 Go 中，比错误更严重的就是 panic， 它的出现表示程序无法正常工作了。那么在使用 panic 时应该注意什么呢？

  • 不建议在业务代码中使用 panic。因为 panic 发生后，会向上传播至调用栈顶，如果当前 goroutine 中所有 deferred 函数都不包含 recover 会造成程序崩溃
  • 若问题可以被屏蔽或解决，建议使用 error 代替 panic
  • 特殊地，当程序启动阶段发生不可逆转的错误时，可以在 init 或 main 函数中使用 panic。因为在这种情况下，服务启动起来也不会有意义。

下面的示例是启动消息队列监听器的逻辑，在创建消费组失败的时候会 Panicf，实际打印日志，然后抛出 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)
    }
    // ...
}
​
// Panicf is equivalent to Printf() followed by a call to panic()
func Panicf(format string, v ...interface{}) {
    s := fmt.Sprintf(format, v...)
    std.Output(2, s)
    panic(s)
}

1.2.5.5 recover

有 panic，自然就会提到 recover，因为我们并不能控制所有的代码，避免不了其他库。如果是引入库的 bug 导致 panic，影响到自身的逻辑该如何处理？

注意 recover 的生效条件

  • recover 只能在被 defer 的函数中使用
  • 嵌套无法生效
  • 只在当前 goroutine 生效
  • 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)
            }
        }
    }()
    // ...
}

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

func (t *treeFS) Open(name string) (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())
        }
    }()
    // ...
}

1.2.5.6 小结

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

1.2.6 练习

image.png

左边：Time

右边：ParseDuration

image.png

多个 defer 语句是后进先出，所以先输出3，然后输出1。

else没有执行到，所以不输出2。

1.3 性能优化建议

1.3.1 简介

高质量的代码能够完成功能，但是在大规模程序部署的场景，仅仅支持正常功能还不够，我们还要尽可能地提升性能，节省资源成本。接下来主要介绍性能相关的建议。

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

1.3.2 Benchmark

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

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

以计算斐波拉契数列的函数为例，分两个文件，fib.go 编写函数代码，fib_test.go 编写 benchmark 的逻辑，通过命令 go test -bench=. -benchmen 运行 benchmark 可以得到测试结果

-benchemen 表示也统计内存信息

// from fib.go
func Fib(n int) int {
    if n < 2 {
        return n
    }
    return Fib(n-1) + Fib(n-2)
}
​
// from fib_test.go
func BenchmarkFib10(b *testing.B) {
    // run the Fib function b.N times
    for n := 0; n < b.N; n++ {
        Fib(10)
    }
}

结果说明：

image.png

1.3.2 Slice

Slice 预分配内存

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

对比一下两种情况的性能表现，NoPreAlloc 没有提供初始化容量信息，PreAlloc 设置了容量大小

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)
    }
}

image.png

结果中可以看出执行时间相差很多。111预分配只有一次内存分配。

为什么会出现这么大的性能差异呢？

首先看一下 slice 的结构

type slice struct {
    array unsafe.pointer
    len int
    cap int
}

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

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

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

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

image.png

以切片的 append 为例，append时有两种场景：

  • 当 append 之后的长度小于等于 cap，将会直接利用原底层数组剩余的空间。
  • 当 append 后的长度大于 cap 时，则会分配一块更大的区域来容纳新的底层数组。

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

使用 slice 的一个陷阱：大内存未释放

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

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

这种情况可以使用 copy 替代 re-slice

示例：

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 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
}

image.png

两部分代码使用了不同的逻辑取 slice 的最后两位数创建新数组，同时统计输出了内存占用信息

结构差异非常明显，lastBySlice 耗费了 100.14MB 内存，也就是说，申请的 100 个 1MB 大小的内存没有被回收。因为切片虽然只使用了最后 2 个元素，但是因为与原来 1M 的切片引用了相同的底层数组，底层数组得不到释放，因此 100.14MB 的内存始终得不到释放。而 lastByCopy 仅消耗了 14MB 的内存。这是因为通过 copy 指向了一个新的底层数组，当 origin 不再被引用后，内存会被垃圾回收。

1.3.3 Map

map 预分配内存

示例：

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
    }
}

image.png

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

1.3.4 字符串处理

编程过程中除了slice和map，平时很多编码功能都和字符串处理相关的，字符串处理也是高频操作。

1.3.4.1 字符串拼接的不同方式和速度差异

下面看看直接用 + 拼接、 strings.Builder 和 bytes.Buffer 的差异。

// 字符串拼接
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()
}
​
// 使用 byte.Buffer
func ByteBuffer(n int, str string) string {
    buf := new(bytes.Buffer)
    for i := 0; i < n; i++ {
        buf.WriteString(str)
    }
    return buf.String()
}

image.png

根据测试结果，使用 + 拼接性能最差， strings.Builder 和 bytes.Buffer 相近，strings.Buffer 更快。

分析：

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

1.3.4.2 为什么 strings.Builder 比 bytes.Buffer 更快

比较 strings.Builder 和 bytes.Buffer 的源码

bytes.Buffer：

// To build strings more efficiently, see the strings.Builder type.
func (b *Buffer) String() string {
    if b == nil {
        // Special case, useful in debugging
        return "<nil>"
    }
    return string(b.buf[b.off:])
}

strings.Builder：

// String returns the accumulated string.
func (b *Builder) String() string {
    return *(*string)(unsafe.Pointer(&b.buf))
}
  • bytes.Buffer 转化为字符串时重新申请了一块空间
  • strings.Builder 直接将底层的 []byte 转化成了字符串类型返回

1.3.4.3 预分配

字符串拼接同样支持预分配，在预知字符串长度的情况下，我们可以进一步提升拼接性能

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

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

image.png

注意： strings.Builder 只有一次内存分配，bytes.Buffer 有两次

1.3.5 空结构体

性能优化有时是时间和空间的平衡，之前提到的都是提高时间效率的点，对于空间上是否有优化的手段呢？

空结构体是节省内存空间的一个手段

  • 空结构体 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
    }
}

image.png

空结构体的实用场景：实现 set

  • 这个场景只需要用到 map 的键，而不需要值
  • 即使是将 map 的值设置为 bool 类型，也会多占据 1 个字节空间

1.3.6 Atomic包

在多线程的场景下，比如实现一个多线程共用的计数器，如何保证计数准确，线程安全，有不同的方式，比如使用 Atomic 包和加锁。

下面对比一下 Atomic 包和加锁的性能

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

image.png

可以看到 Atomic 包比加锁的性能更好，原因如下

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

1.3.7 小结

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