241118学习日志——[CSDIY] [ByteDance] 后端训练营 [06]

CSDIY：这是一个非科班学生的努力之路，从今天开始这个系列会长期更新，（最好做到日更），我会慢慢把自己目前对CS的努力逐一上传，帮助那些和我一样有着梦想的玩家取得胜利！！！
第一弹：Cpp零基础学习【30 DAYS 从0到1】
第二弹：Cpp刷题文档【LeetCode】
第三弹：Go开发入门【字节后端青训营】
第四弹：Cpp简单项目开发【黑马Rookie】
第五弹：数据结构绪论【数据结构与算法】
第六弹：Go工程实践【字节后端青训营】
第七弹：高质量编程和性能调优【字节后端青训营】

241118——[ByteDance] [02] 高质量编程与性能调优实践

实际开发中，不仅仅需要实现功能，也要让团队其他人看懂。

• 优秀的功能和效率
• 清晰的算法思路和编程习惯

1. 高质量编程

正确可靠，清晰简介的代码是受欢迎的

1.1 高质量编程简介

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

Go：编程原则 - Go 语言开发者 Dave Cheney

• 简单性：消除多余的“复杂性”，人无法理解的代码无法修复改进
• 可读性：代码是写给人看的
• 生产力：团队整体工作效率很重要

1.2 编码规范

如何编写高质量的 Go 代码

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

1.2.1 代码格式

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

gofmt / goimports （对依赖包进行增删排序）

某些 IDE 自带格式化功能

1.2.2 注释

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

——Dave Thomas and Andrew Hunt

公共符号：

一些常量，公开变量

公共符号始终要注释

但有一个例外：不需要注释实现接口的方法。具体不要让开发者去溯源？

实现过程：

代码是怎么实现的，在维护代码时也要维护注释

实现原因：

提供适合的上下文

限制条件：

解释代码在什么情况下会出错

小结：

• 代码是最好的注释
• 注释应该提供代码未表达出的上下文信息 而不是逐句逐语法解释

1.2.3 命名规范

variab：

• 简介胜于冗长
• 缩略词全大写
• 变量距离被使用的地方越远，越需要携带更多的上下文信息

function：

• 函数名不携带包名的上下文信息
• 函数名尽量简短
• 函数名可以在不影响歧义的情况下，可以在函数名加入类型信息

package：

• 只由小写字母组成
• 简短且携带一定信息
• 不要与标准库同名

尽量满足

• 不使用常用变量名作为包名
• 使用单数而不是复数
• 谨慎使用缩写（ format > fmt ）

小结：

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

1.2.4 控制流程

• 避免 if - else 分支嵌套

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

小结：

• 线性原理
• 故障问题大多都出现在复杂的条件语句中

1.2.5 错误和异常处理

简单错误：仅出现一次的错误

复杂错误：

错误的 Wrap 和 Unwrap

错误判定：

判断一个错误是否为特定错误

在错误链上获取特定种类的错误

panic：

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

recover：

• recover 可以用来解决 panic 引发的进一步错误

• recover 只能被 defer 函数中使用

• 在 recover 后在 log 中记录当前调用栈

小结：

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

1.3 性能优化建议

性能优化的前提是满足正确可靠、简介清晰

1.3.1 Benchmark

Go 自带的工具

go test -bench=. -benchmen

1.3.2 Slice

预分配内存（避免频繁扩容）

1.3.3 Map

预分配内存

提前分配好内存可以减少内存和 rehash 的消耗

1.3.4 字符串处理

string.Builder : 转化为字符串时 重新申请了一块空间

实际上也是预分配的逻辑

1.3.5 空结构体

空结构体节省内存

• 节省资源
• 不需要任何值，仅仅做占位符

可以用来实现 Set，此时只需要键，而不需要值

1.3.6 atomic 包

• 锁的实现通过操作系统实现，属于系统调用
• 通过硬件实现

小结：

• 避免常见性能陷阱
• 普通应用代码，不要一味追求i性能
• 越高级的性能手段越容易出问题

2. 性能调优实战

学校里学不到的！

2.1 性能调优简介

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

2.2 性能分析工具 pprof 实战

说明

• 希望知道在什么地方耗费了多少CPU、Memory
• 可视化分析

开始之前：请查看完整教程：

https://blog.wolfogre.com/posts/go-ppof-practice/

如果要说在 golang 开发过程进行性能调优，pprof 一定是一个大杀器般的工具。但在网上找到的教程都偏向简略，难寻真的能应用于实战的教程。这也无可厚非，毕竟 pprof 是当程序占用资源异常时才需要启用的工具，而我相信大家的编码水平和排场问题的能力是足够高的，一般不会写出性能极度堪忧的程序，且即使发现有一些资源异常占用，也会通过排查代码快速定位，这也导致 pprof 需要上战场的机会少之又少。即使大家有心想学习使用 pprof，却也常常相忘于江湖。

既然如此，那我就送大家一个性能极度堪忧的“炸弹”程序吧！

这程序没啥正经用途缺极度占用资源，基本覆盖了常见的性能问题。本文就是希望读者能一步一步按照提示，使用 pprof 定位这个程序的的性能瓶颈所在，借此学习 pprof 工具的使用方法。

因此，本文是一场“实验课”而非“理论课”，请读者腾出时间，脚踏实地，一步一步随实验步骤进行操作，这会是一个很有趣的冒险，不会很无聊，希望你能喜欢。

2.2.1 功能简介

• Tool工具
• Sample采样：CPU、Heap、Goroutine
• Profile分析：网页
• View展示：Top、Graph、FlameGraph、Source

搭建 pprof 项目

2.2.2 排查实战

保持程序运行，打开浏览器访问 http://localhost:6060/debug/pprof/

可以查看指标：数据平铺

查看 CPU 情况：

查看占用资源最多的函数

命令：top

flat	flat%	sum%	cum	cum%
当前函数本身执行耗时	flat占 CPU 总时间的比例	上面每一行的 flat% 总和	当前函数本身加上其调用函数的总耗时	cum 占CPU 总时间的比例

Flat == Cum，函数中没有调用其他函数

Flat == 0，函数中只有其他函数的调用

命令：list

根据指定正则表达式查找代码行

命令：web

生成一个调用关系图，使得调用关系可视化

---

heap-堆内存

goroutine-协程

• goroutine 泄露会导致内存泄漏

mutex-锁

block-阻塞

2.2.3 采样过程和原理

CPU

• 采样对象：函数调用和它们占用的时间
• 采样率：100次/秒，固定值
• 采样时间：从手动启动到手动结束
• 操作系统
• 进程
• 写缓冲

Heap - 堆内存

• 采样率：每分配512KB记录一次
• 采样时间：从程序运行开始到采样时

Goroutine - 协程 & ThreadCreate - 线程创建

• Goroutine - 协程：记录所有用户发起且在运行中的 Goroutine
• ThreadCreate - 线程创建：记录程序创建所有系统线程的信息

Bolck - 阻塞 & Mutex - 锁

• 阻塞操作：采样阻塞操作的次数和耗时
• 锁竞争：采样争抢锁的次数和耗时

2.3 性能调优案例

• 实际业务服务性能调优案例

• 对逻辑相对复杂的程序如何进行性能调优

2.3.1 业务服务优化

基本概念

• 服务：能单独部署，承载一定功能的程序
• 依赖：
• 调用链路：能支持一个接口请求的相关服务集合及其相互之间的依赖关系
• 基础库：公共的工具包

流程

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

建立服务性能评估手段

• 服务性能评估方式
• 请求流量构造
• 压测范围
• 性能数据采集

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

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

重点优化项改造

• 正确性
• 响应数据

优化效果验证

• 重复压测验证
• 上限评估优化结果

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

• 规范上游服务调用接口
• 分析链路

2.3.2 基础库优化

AB 实验 SDK 优化

• 分析基础库核心逻辑
• 内部压测验证
• 推广业务服务落地验证

2.3.3 Go 语言优化

编译器 & 运行时优化

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

2.4 总结

• 性能调优原则
  • 要依靠数据而不是猜测
• 性能调优工具 pprof
  • 熟练使用 pprof 工具排查性能问题并了解其基本原理
• 性能调优
  • 保证正确性
  • 定位主要瓶颈

碎碎念：每周一可以说是最怕的日子，有很多DDL，但还是挺过来了。跟上字节的课可以说有点困难。。。很多时候都想放弃，但是后端入门篇就这样被我水过去了…谁知道呢，后面的课程会更加虐，但我一想到CSDIY里面的话，我就心有余甘…很多时也想过放弃和偷懒，也想过自己是不是在假努力，但谁说学了一定要会呢？我就是喜欢做笔记的感觉，我就是喜欢敲键盘（打字）怎么了？？？所以呢，还是不想给自己借口。

与君共勉。