不要使用Logrus
这其实和泛型有关。因为Go语言是一门强类型的静态语言,所以你不可能像NodeJS或者PHP那样绕过数据类型。那如果我们还需要使用通用的类型怎么办呢?比如像Loger,或者ORM,因为只有使用了通用的类型,才能编写出通用的代码,不然每个都要写一次。
最终,我们只能用反射。而 Logrus 大量使用反射,这导致大量分配计数。虽然通常不是一个大问题(取决于代码),但性能很重要,尤其是在大规模、高并发的项目中。虽然这听起来像是一个非常小的优化,但避免反射很重要。如果你看到一些可以不考虑类型而使用结构的代码,它会使用反射并且会对性能产生影响。
例如,Logrus 并不关心类型,但显然 Go 需要知道(最终)。Logrus 怎么办呢?使用反射来检测类型,这是开销。
log.WithFields(log.Fields{
“animal”: myWhatever,
}).Info(“A walrus appears”)
所以我会更喜欢zerolog,当然zap也不错。两者都宣称零分配,这也是我们希望的,因为它们的性能影响最小。
不要使用encoding/json
当我们需要一个功能、函数的时候,很多人都建议使用标准库。但是标准库中的encoding/json模块是个例外。其实也和上面的例子一样,encoding/json使用反射,这会导致性能不高,并且在编写返回 json 响应的 API 、或者微服务时会造成损失。
比如你可以使用 Easyjson,它很简单,也很高效,它是使用代码生成器来创建将结构转换为 json 所需的代码,以最大限度地减少分配。这是一个手动构建步骤,很烦人。有趣的是json-iterator也使用反射,但速度明显更快,我怀疑是黑魔法。
尽可能不要在goroutine中使用闭包
比如,下面这个示例代码:
for i:=0;i<10;i++ {
go func() {
fmt.Println(i)
}()
}
大多数人可能期望这会打印数字 0 到 9,就像将任务委托给 goroutine 时那样。
但是实际结果:根据系统,你将得到一两个数字和许多 10。
为什么会这样?闭包可以访问父作用域,因此可以直接使用变量。尽管更新的 linters 可能会警告你“变量闭包捕获”,但并不会要求你重新声明该变量。
Go 的性能名声很大程度上归功于执行的运行时优化,它尝试“猜测”你想要做什么并优化某些执行路径。在此期间,它“捕获”变量并以理论上最有效的方式将它们传递到需要它们的地方(例如,在完成一些非并发操作以释放某些 CPU 上的分配之后)。这种情况下的结果是循环可能会启动 goroutines,goroutines可能会在很晚之后从父作用域接收到 i 的值。不能保证在多次执行此代码时你会看到哪个,可能是数字10,也可以是其他数字。
如果你出于某种原因确实使用了闭包,一定要传递变量i,就像对待每个函数一样对待闭包。
转载:https://blog.csdn.net/Edu_enth/article/details/128490611