1高质量编程
1.1编程原则
实际应用场景千变万化，各种语言的特性和语法各不相同
但是高质量编程遵循的原则是相通的
简单性
- 消除"多余的复杂性"，以简单清晰的逻辑编
- 写代码不理解的代码无法修复改进
可读性
- 代码是写给人看的，而不是机器
- 编写可维护代码的第-步是确保代码可读
生产力
- 团队整体工作效率非常重要
1.2编码规范
代码格式
gofmt自动格式代码
Go语言官方提供的工具，能自动格式化Go语言代码为官方统一风格常见IDE都支持方便的配置
注释
-
注释应该解释代码作用
注释公共符号
-
注释应该解释代码如何做的
注释实现过程
-
注释应该解释代码实现的原因
提供上下文
-
注释应该解释代码什么情况会出错
解释代码限制情
公共符号始终要注释
包中声明的每个公共的符号:变量、常量、函数以及结构都需要添加注释
任何既不明显也不简短的公共功能必须予以注释
无论长度或复杂程度如何，对库中的任何函数都必须进行注释
命名规范
variable
-
简洁胜于冗长
-
缩略词全大写，但当其位于变量开头且不需要导出时，使用全小写
使用ServeHTTP而不是ServeHttp
使用XMLHttpRequest或者xmlHTTPRequest
-
变量距离其被使用的地方越远，则需要携带越多的上下文信息
全局变量在其名字中需要更多的上下文信息，使得在不同地方可以轻易辨认出其含义
function
- 函数名不携带包名的上下文信息，因为包名和函数名总是成对出现的
- 函数名尽量简短
- 当名为foo的包某个函数返回类型Foo时，可以省略类型信息而不导致歧义
- 当名为foo的包某个函数返回类型T时(T 并不是Foo)，可以在函数名中加入类型信息
package
- 只由小写字母组成。不包含大写字母和下划线等字符
- 简短并包含一定的.上下文信息。例如schema、task 等
- 不要与标准库同名。例如不要使用sync或者strings
库名
- 不使用常用变量名作为包名。例如使用bufio而不是buf
- 使用单数而不是复数。例如使用encoding而不是encodings
- 谨慎地使用缩写。例如使用fmt在不破坏上下文的情况下比format更加简短
控制流程
- 线性原理，处理逻辑尽量走直线，避免复杂的嵌套分支
- 正常流程代码沿着屏幕向下移动
- 提升代码可维护性和可读性
- 故障问题大多出现在复杂的条件语句和循环语句中
错误或异常处理
简单错误
- 简单的错误指的是仅出现一次的错误，且在其他地方不需要捕获该错误
- 优先使用errors.New来创建匿名变量来直接表示简单错误
- 如果有格式化的需求，使用fmt. Errorf
Wrap
- 错误的Wrap实际上是提供了-一个error嵌套另一个error的能力，从而生成一个error的跟踪链
- 在fmt.Errorf中使用: %w关键字来将一一个error关联至错误链中
错误判定
- 判定一个错误是否为特定错误， 使用errors.Is
- 不同于使用==，使用该方法可以判定errors.ls上的所有错误是否含有特定的错误
- 在错误链上获取特定种类的错误，使用errors.As
panic
- 不建议在业务代码中使用panic
- 调用函数不包含recover会造成程序崩溃
- 若问题可以被屏蔽或解决，建议使用error代替panic
- 当程序启动阶段发生不可逆转的错误时，可以在init或main函数中使用panic
recover
- recover只能在被defer的函数中使用
- 嵌套无法生效
- 只在当前goroutine生效
- defer的语句是后进先出
- 如果需要更多的上下文信息，可以recover后在log中记录当前的调用栈
1.3性能建议
Benchmark
- 性能表现需要实际数据衡量
- Go语言提供了支持基准性能测试的benchmark工具
go test -bench=. -benchmen
GOMAXPROCS为
https://pkg.go.dev/runtime#GOMAXPROCS
Slice
- 尽可能在使用make()初始化切片时提供容量信息
- 切片本质是一个数组片段的描述 包括数组指针 片段的长度 片段的容量(不改变内存分配情况下的最大长度)
- 切片操作并不复制切片指向的元素
- 创建一个新的切片会复用原来切片的底层数组
- 可使用copy替代re -slice (大内存未释放)
map预分配内存
- 不断向map中添加元素的操作会触发map的扩容
- 提前分配好空间可以减少内存拷贝和Rehash的消耗
- 建议根据实际需求提前预估好需要的空间
字符串处理
-
使用strings. Builder 常见的字符串拼接方式
bytes. Buffer转化为字符串时重新申请了一块空间 strings.Builder直接将底层的[]字节转换成了字符串类型返回
空结构体
- 实现Set,可以考虑用map来代替
- 对于这个场景，只需要用到map的键，而不需要值
- 即使是将map的值设置为bool类型，也会多占据1个字节空间
atomic包
- 锁的实现是通过操作系统来实现，属于系统调用
- atomic操作是通过硬件实现，效率比锁高
- sync. .Mutex应该用来保护一段逻辑，不仅仅用于保护一个变量
- 对于非数值操作，可以使用atomic.Value, 能承载一 个interface{}
1.4性能分析工具pprof
import("net/http/pprof")
go tool pprof "http://localhost:6060/debug/pprof/profile?seconds= 10"
cpu
topN 查看占用资源最多函数
list 根据正则表达式找寻代码行
web 调整可视化关系
Heap堆内存
go tool pprof "http://localhost:6060/debug/pprof/heap"
goroutine协程
go tool pprof "http://localhost:6060/debug/pprof/goroutine"
2高性能
2.1自动内存管理
-
动态内存
程序在运行时根据需求动态分配的内存：malloc()
-
自动内存管理(垃圾回收)：由程序语言的运行时系统回收动态内存
避免手动内存管理，专注于实现业务逻辑
保证内存使用的正确性和安全性: double -free problem, use-after- free problem
-
三个任务
为新对象分配空间 找到存活对象 回收死亡对象的内存空间
追踪垃圾回收
-
对象被回收的条件:指针指向关系不可达的对象
-
标记根对象
静态变量、全局变量、常量、线程栈等
-
标记:找到可达对象
求指针指向关系的传递闭包:从根对象出发，找到所有可达对象
-
清理:所有不可达对象
将存活对象复制到另外的内存空间(Copying GC) 将死亡对象的内存标记为可分配” (Mark sweep GC) 移动并整理存活对象(Mark compact GC)
分代GC
- 分代假说(Generational hypothesis): most objects die young
- Intuition:很多对象在分配出来后很快就不再使用了
- 每个对象都有年龄:经历过GC的次数
- 目的:对年轻和老年的对象，制定不同的GC策略，降低整体内存管理的开销
- 不同年龄的对象处于heap的不同区域
引用计数
-
每个对象都有一个与之关联的引用数目
-
对象存活的条件:当且仅当引用数大于
-
优点 内存管理的操作被平摊到程序执行过程中
内存管理不需要了解runtime的实现细节: C+ +智能指针(smart pointer)
-
缺点
维护引用计数的开销较大:通过原子操作保证对引用计数操作的原子性和可见性 无法回收环形数据结构weak reference 内存开销:每个对象都引入的额外内存空间存储引用数目 回收内存时依然可能引发暂停
2.2内存管理
分块
缓存
对象分配
GC
12.3编译器和静态分析
编译器结构
-
重要的系统软件
识别符合语法和非法的程序
生成正确且高效的代码
-
分析部分(前端front end)
词法分析，生成词素(lexeme)
语法分析，生成语法树
语义分析，收集类型信息，进行语义检查
中间代码生成，生成intermediate representation (IR)
-
综合部分(后端 back end)
代码优化，机器无关优化，生成优化后的IR
代码生成，生成目标代码
静态分析
- 静态分析:不执行程序代码，推导程序的行为，分析程序的性质。
- 控制流(Control flow):程序执行的流程
- 数据流(Data flow):数据在控制流上的传递
过程分析
- 过程内分析(Intra- procedural analysis) 仅在函数内部进行分析
- 程序间分析(过程间分析) 考虑过程调用时参数传递和返回值的数据流和控制流
- 为什么过程间分析是个问题？ 需要通过数据流分析得知i的具体类型，才能知道i.foo()调用的是哪个foo() 根据i的具体类型，产生了新的控制流，A.foo(),分析继续 过程间分析需要同时分析控制流和数据流联合求解，比较复杂
12.4编译器优化
函数内联
-
内联:将被调用函数的函数体(callee)的副本替换到调用位置(caller)上，同时重写代码以反映参数的绑定
-
优点
消除函数调用开销，例如传递参数、保存奇存器等
将过程间分析转化为过程内分析，帮助其他优化，例如逃逸分析
-
缺点
函数体变大，instruction cache (icache)不友好
编译生成的Go镜像变大
-
函数内联在大多数情况下是正向优化
-
内联策略 调用和被调函数的规模
