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

1. 高质量编程

1.1. 简介

1.1.1 高质量代码

高质量代码: 编写的代码能够达到正确可靠、简洁清晰、无性能隐患的目标

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

1.1.2 编程原则

实际应用场景千变万化，各种语言的特性和语法各不相同，但是高质量编程遵循的原则是相通的
高质量的编程需要注意以下原则：简单性、可读性、生产力
- 简单性
  - 消除多余的复杂性，用最简洁清晰的逻辑写代码
  - 不被理解的代码无法进行修复改进
- 可读性
  - 代码是写给人看的,而不是机器
  - 编写可维护代码的第一步是确保代码可读
- 生产力
  - 保证团队整体工作效率非常重要 — Go语言开发者 Dave Cheney

1.2. 常见编码规范

如何编写高质量的 Go 代码?

1.2.1 代码格式

使用 gofmt 自动格式化代码

Go语言官方提供的工具，能自动格式化Go语言代码，保证所有的 Go 代码与官方推荐格式保持一致
使用 goimports 自动管理依赖

Go语言官方提供的工具，自动增删依赖的包引用、将依赖包按字母序排序并分类
总结
- 提升可读性，风格一致的代码更容易维护、需要更少的学习成本、团队合作成本，同时可以降低 Review 成本

1.2.2 注释

注释应该做的

注释应该解释代码作用

适合注释公共符号

github.com/golang/go/b…

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

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

适合注释方法

github.com/golang/go/b…

// 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); ref != "" {
	req.Header.Set("Referer", ref)
}

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

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

github.com/golang/go/b…

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

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

适合注释代码的限制条件

github.com/golang/go/b…

// parseTimeZone parses a time zone string and returns its length. Time zones
// are human-generated and unpredictable. We can't do precise error checking.
// On the other hand, for a correct parse 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) {
	// ...
}

公共符号始终要注释

包中声明的每个公共的符号：变量、常量、函数以及结构都需要添加注释
任何既不明显也不简短的公共功能必须予以注释 github.com/golang/go/b…
无论长度或复杂程度如何, 对库中的任何函数都必须进行注释 github.com/golang/go/b…

例外: 不需要注释实现接口的方法

尽管LimitedReader.Read本身没有注释，但它紧跟LimitedReader结构的声明，明确它的作用 github.com/golang/go/b…

// 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, nil} }

// 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 Err when N <= 0.
// If Err is nil, it returns EOF instead.
type LimitedReader struct {
	R   Reader // underlying reader
	N   int64  // max bytes remaining
	Err error  // error to return on reaching the limit
}

func (l *LimitedReader) Read(p []byte) (n int, err error) {
	if l.N <= 0 {
		err := l.Err
		if err == nil {
			err = EOF
		}
		return 0, err
	}
	if int64(len(p)) > l.N {
		p = p[0:l.N]
	}
	n, err = l.R.Read(p)
	l.N -= int64(n)
	return
}

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

1.2.3 命名规范

variable
- 简洁胜于冗长
  - i 和 index 的作用域范围仅限于 for 循环内部时, index 的额外冗长几乎没有增加对于程序的理解
  - 将 deadline 替换成 t 降低了变量名的信息量
- 缩略词全大写，但当其位于变量开头且不需要导出时，使用全小写
  - 例如使用 ServeHTTP 而不是 ServeHttp
  - 使用 XMLHTTPRequest或者 xmHTTPRequest
- 变量距离其被使用的地方越远，则需要携带越多的上下文信息
  - 全局变量在其名字中需要更多的上下文信息，使得在不同地方可以轻易辨认出其含义
function
- 函数名不携带包名的上下文信息，因为包名和函数名总是成对出现的
  - Sample
    
    http 包中创建服务的函数如何命名更好？
```
// 调用时为 http.Serve
func Serve(I net.Listener，handlerHandler) error

// 调用时为 http.ServeHTTP, 携带包名的上下文信息
func ServeHTTP(I net.Listener，handlerHandler) error
```
- 函数名尽量简短
- 当名为 foo 的包某个函数返回类型 Foo 时，可以省略类型信息而不导致歧义
- 当名为 foo 的包某个函数返回类型 T 时（ T 并不是 Foo ），可以在函数名中加入类型信息
package
- 只由小写字母组成。不包含大写字母和下划线等字符
- 简短并包含一定的上下文信息。例如 schema、 task 等
- 不要与标准库同名。例如不要使用 sync 或者 strings
- 尽量满足以下规则
  - 不使用常用变量名作为包名。例如使用 bufio 而不是 buf
  - 使用单数而不是复数。例如使用 encoding 而不是 encodings
  - 谨慎地使用缩写。例如使用 fmt 在不破坏上下文的情况下比 format 更加简短
总结
- 关于命名的大多数规范核心在于降低理解代码的成本
  - 人们在阅读理解代码的时候也可以看成是计算机运行程序，好的命名能让人把关注点留在主流程上，清晰地理解程序的功能，避免频繁切换到分支细节，增加理解成本
- 重点考虑上下文信息, 设计简洁清晰地名称

1.2.4 控制流程

避免嵌套，保持正常流程清晰
如果两个分支中都包含 return 语句，则可以去除冗余的 else

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

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

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

Go 公共库的代码 github.com/golang/go/b…

// UnreadByte unreads the last byte. Only the most recently read byte can be unread.
//
// UnreadByte returns an error if the most recent method called on the
// Reader was not a read operation. Notably, Peek, Discard, and WriteTo are not
// considered read operations.
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.5 错误和异常处理

简单错误处理
- 简单错误指的是仅出现一次的错误，且在其他地方不需要捕获该错误
- 优先使用 errors.New 来创建匿名变量来直接表示该错误。
  - github.com/golang/go/b…
```
func defaultCheckRedirect(req *Request, via []*Request) error {
	if len(via) >= 10 {
		return errors.New("stopped after 10 redirects")
	}
	return nil
}
```
- 有格式化需求时使用 fmt.Errorf
错误的 Wrap 和 Unwrap
- 错误的 Wrap 实际上是提供了一个 error 嵌套另一 error 的能力，从而生成一个 error 的跟踪链
- 在 fmt.Errorf 中使用 %w 关键字来将一个错误 wrap 至其错误链中
  - github.com/golang/go/b…
```
c := cache.Default()
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.Is 可以判定错误链上的所有错误是否含有特定的错误。
- github.com/golang/go/b…
```
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
}
```
- 不同于使用 ==，使用该方法可以判定错误链上的所有错误是否含有特定的错误

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

github.com/golang/go/b…

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

panic

不建议在业务代码中使用 panic
如果当前 goroutine 中所有 deferred 函数都不包含 recover 就会造成整个程序崩溃
当程序启动阶段发生不可逆转的错误时，可以在 init 或 main 函数中使用 panic

github.com/Shopify/sar…

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 l.Printf() followed by a call to panic().
func (l *Logger) Panicf(format string, v ...any) {
	s := fmt.Sprintf(format, v...)
	l.Output(2, s)
	panic(s)
}

recover

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

github.com/golang/go/b…

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)
			}
		}
	}()
	if f == nil {
		f = notSpace
	}
	s.buf = s.buf[:0]
	tok = s.token(skipSpace, f)
	return
}

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

github.com/golang/webs…

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

	// ...
}

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

1.3. 性能优化建议

1.3.1 简介

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

1.3.2 如何使用

性能表现需要实际数据衡量
Go语言提供了支持基准性能测试的 benchmark 工具
Go 语言常见性能优化建议的性能对比测试代码，可参考 github.com/RaymondCode…
- 进入到对应的 benchmark 目录，运行 go test -bench=. -benchmem

1.3.3 `slice` 预分配内存

在尽可能的情况下，在使用 make() 初始化切片时提供容量信息，特别是在追加切片时
原理
- 数组与切片
- ueokande.github.io/go-slice-tr…
- 切片本质是一个数组片段的描述，包括了数组的指针，这个片段的长度和容量 (不改变内存分配情况下的最大长度)
- 切片操作并不复制切片指向的元素，创建一个新的切片会复用原来切片的底层数组，因此切片操作是非常高效的
- 切片有三个属性，指针 ( ptr )、长度 ( len ) 和容量 ( cap )。 append 时有两种场景：
  - 当 append 之后的长度小于等于 cap，将会直接利用原底层数组剩余的空间
  - 当 append 后的长度大于 cap 时，则会分配一块更大的区域来容纳新的底层数组
- 因此，为了避免内存发生拷贝，如果能够知道最终的切片的大小，预先设置 cap 的值能够获得最好的性能
另一个陷阱：大内存得不到释放
- 在已有切片的基础上进行切片，不会创建新的底层数组。因为原来的底层数组没有发生变化，内存会一直占用，直到没有变量引用该数组
- 因此很可能出现这么一种情况，原切片由大量的元素构成，但是我们在原切片的基础上切片，虽然只使用了很小一段，但底层数组在内存中仍然占据了大量空间，得不到释放
- 推荐的做法，使用 copy 替代 re-slice

1.3.4 `map` 预分配内存

Untitled 8.png

Untitled 9.png

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

1.3.5 使用 `strings.Builder`

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

1.3.6 使用空结构体节省内存

空结构体 struct{} 实例不占据任何内存空间
可作为占位符使用
- 节省资源
- 空结构体本身具备很强的语义, 即这里不需要任何值, 仅作为占位符
比如实现简单的 Set
- Go 语言标准库没有提供 Set 的实现，通常使用 map 来代替。对于集合场景，只需要用到 map 的键而不需要值

1.3.7 使用 `atomic` 包来实现多线程

Untitled 19.png

Untitled 20.png

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

总结

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

2. 性能调优实战

2.1. 简介

2.1.1 性能调优原则

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

2.2. 性能分析工具 `pprof`

性能调优的核心是性能瓶颈的分析，对于 Go 应用程序，最方便的就是 pprof 工具

2.2.1 `pprof` 功能说明

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

2.2.2 `pprof` 实践

项目

github.com/wolfogre/go…

项目提前迈入了一些炸弹代码, 产生可观测的性能问题
前置准备，熟悉简单指标，能够编译运行 pprof 测试项目
实际分析排查过程
- 排查 CPU 问题
  1. 命令行分析
    
    go tool pprof “http://localhost:6060/debug/pprof/profile?seconds=10”
  2. top 命令
    - Flat==Cum，函数中没有调用其他函数
    - Flat==0，函数中只有其他函数的调用
  3. list 命令
    
    根据指定的正则表达式查找代码行
  4. 熟悉 web 页面分析
    
    执行 web 命令
  5. 调用关系图，火焰图
    
    go tool pprof -http=:8080 “http://localhost:6060/debug/pprof/cpu”
- 排查堆内存问题
  - go tool pprof -http=:8080 “http://localhost:6060/debug/pprof/heap”
- 排查协程问题
  
  go tool pprof -http=:8080 “http://localhost:6060/debug/pprof/goroutine”
- 排查锁问题
  
  go tool pprof -http=:8080 “http://localhost:6060/debug/pprof/mutex”
- 排查阻塞问题
  
  go tool pprof -http=:8080 “http://localhost:6060/debug/pprof/block”

2.2.3 `pprof` 的采样过程和原理

CPU 采样
- 采样对象：函数调用和它们占用的时间
- 采样率：100次/秒，固定值
- 采样时间：从手动启动到手动结束
- 采样过程
堆内存采样
- 采样程序通过内存分配器在堆上分配和释放的内存，记录分配/释放的大小和数量
- 采样率：每分配512KB记录一次，可在运行开头修改，1为每次分配均记录
- 采样时间：从程序运行开始到采样时
- 采样指标：alloc_space，alloc_objects，inuse_space，inuse_objects
- 计算方式： $inuse=alloc-free$
协程和系统线程采样
阻塞操作和锁竞争采样

2.3. 性能调优案例

2.3.1 基本概念

Untitled 30.png

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

2.3.2 业务优化

流程
- 建立服务性能评估手段
  
  之所以不用 benchmark 是因为实际服务逻辑比较复杂，希望从更高的层面分析服务的性能问题，同时机器在不同负载下的性能表现也会不同
  
  右图是负载和单核qps的对应数据另外因为逻辑复杂，不同的请求参数会走不同的处理逻辑，对应的性能表现也不相同，需要尽量模拟线上真实情况，分析真正的性能瓶颈压测会录制线上的请求流量，通过控制回放速度来对服务进行测试，测试范围可以是单个实例，也可以是整个集群，同样性能采集也会区分单机和集群
  - 产出 ⇒ 服务性能指标分析报告
- 分析性能数据，定位性能瓶颈
  - 使用库不规范
    
    这里通过火焰图看出json的解析部分占用了较多的CPU资源，那么我们就能定位到具体的逻辑代码，是在每次使用配置时都会进行json解析，拿到配置项，实际组件内部提供了缓存机制，只有数据变更的时候才需要重新解析json
  - 高并发场景优化不足
    
    左边是服务高峰期的火焰图，右边是低峰期的火焰图，可以发现metrics，即监控组件的CPU资源占用变化较大，主要原因是监控数据上报是同步请求，在请求量上涨，监控打点数据量增加时，达到性能瓶颈，造成阻塞，影响业务逻辑的处理，后续是改成异步上报的机制提升了性能
- 重点优化项改造
  - 重放
    
    性能优化的前提是保证正确性，所以在变动较大的性能优化上线之前，还需要进行正确性验证，因为线上的场景和流程太多，所以要借助自动化手段来保证优化后程序的正确性同样是线上请求的录制，不过这里不仅包含请求参数录制，还会录制线上的返回内容，重放时对比线上的返回内容和优化后服务的返回内容进行正确性验证比如图中作者信息相关的字段值在优化有有变化，需要进一步排查原因
- 优化效果验证
  
  验证分两部分，首先依然是用同样的数据对优化后的服务进行压测，可以看到现在的数据比优化前好很多，能够支持更多的qps
  
  正式上线的时候会逐步放量，记录真正的优化效果
  
  同时压测并不能保证和线上表现完全一致，有时还要通过线上的表现再进行分析改进，是个长期的过程
- 总结
  - 建立压测评估链路
    - 服务性能评估
    - 构造请求流量
    - 压测范围
    - 性能数据采集
  - 分析性能火焰图，定位性能瓶颈
    - pprof 火焰图
  - 重点优化项分析
    - 规范组件库使用
    - 高并发场景优化
    - 增加代码检查规则避免增量劣化出现
    - 优化正确性验证
  - 上线验证评估
    - 逐步放量，避免出现问题
  - 进一步优化，服务整体链路分析
    - 规范上游服务调用接口，明确场景需求
    - 分析业务流程，通过业务流程优化提升服务性能

2.3.3 基础库优化

适应范围更广，覆盖更多服务
AB 实验 SDK 的优化
- 分析基础库核心逻辑和性能瓶颈
- 完善改造方案，按需获取，序列化协议优化
- 内部压测验证
- 推广业务服务落地验证

2.3.4 Go 语言优化

优点
- 接入简单,只需要调整编译配置
- 通用性强
- 适应范围最广，Go 服务都有收益
优化方式
- 优化内存分配策略
- 优化代码编译流程，生成更高效的程序
- 内部压测验证
- 推广业务服务落地验证

课后

了解下其他语言的编码规范，是否和 Go 语言编码规范有相通之处，注重理解哪些共同点
编码规范或者性能优化建议大部分是通用的，有没有方式能够自动化对代码进行检测？
从 github.com/golang/go/t… 中选择感兴趣的包，看看官方代码是如何编写的
使用 Go 进行并发编程时有哪些性能陷阱或者优化手段？
在真实的线上环境中，每个场景或者服务遇到的性能问题也是各种各样，搜索下知名公司的官方公众号或者博客，里面有哪些性能优化的案例？比如 eng.uber.com/category/os…
Go 语言本身在持续更新迭代，每个版本在性能上有哪些重要的优化点？

参考资料

熟悉 Go 语言基础后的必读内容，go.dev/doc/effecti…
Dave Cheney 关于 Go 语言编程实践的演讲记录，dave.cheney.net/practical-g…
《编程的原则：改善代码质量的 101 个方法》，总结了很多编程原则，按照是什么 -> 为什么 -> 怎么做进行了说明，mp.weixin.qq.com/s/vXSZOl2Gt…
如何编写整洁的 Go 代码，github.com/Pungyeon/cl…
Go 官方博客，有关于 Go 的最新进展，go.dev/blog/
Dave Cheney 关于 Go 语言编程高性能编程的介绍，dave.cheney.net/high-perfor…
Go 语言高性能编程，博主总结了 Go 编程的一些性能建议， geektutu.com/post/high-p…
Google 其他编程语言编码规范，可以对照参考，zh-google-styleguide.readthedocs.io

高质量编程与性能调优 | 青训营笔记

1. 高质量编程

1.1. 简介

1.1.1 高质量代码

1.1.2 编程原则

1.2. 常见编码规范

1.2.1 代码格式

1.2.2 注释

1.2.3 命名规范

1.2.4 控制流程

1.2.5 错误和异常处理

1.3. 性能优化建议

1.3.1 简介

1.3.2 如何使用

1.3.3 slice 预分配内存

1.3.4 map 预分配内存

1.3.5 使用 strings.Builder

1.3.6 使用空结构体节省内存

1.3.7 使用 atomic 包来实现多线程

总结

2. 性能调优实战

2.1. 简介

2.1.1 性能调优原则

2.2. 性能分析工具 pprof

2.2.1 pprof 功能说明

2.2.2 pprof 实践

2.2.3 pprof 的采样过程和原理

2.3. 性能调优案例

2.3.1 基本概念

2.3.2 业务优化

2.3.3 基础库优化

2.3.4 Go 语言优化

课后

参考资料

1.3.3 `slice` 预分配内存

1.3.4 `map` 预分配内存

1.3.5 使用 `strings.Builder`

1.3.7 使用 `atomic` 包来实现多线程

2.2. 性能分析工具 `pprof`

2.2.1 `pprof` 功能说明

2.2.2 `pprof` 实践

2.2.3 `pprof` 的采样过程和原理