关于go语言日志错误堆栈的信息
Go 语言内存管理（三）：逃逸分析
Go 语言较之 C 语言一个很大的优势就是自带 GC 功能，可 GC 并不是没有代价的。写 C 语言的时候，在一个函数内声明的变量，在函数退出后会自动释放掉，因为这些变量分配在栈上。如果你期望变量的数据可以在函数退出后仍然能被访问，就需要调用 malloc 方法在堆上申请内存，如果程序不再需要这块内存了，再调用 free 方法释放掉。Go 语言不需要你主动调用 malloc 来分配堆空间，编译器会自动分析，找出需要 malloc 的变量，使用堆内存。编译器的这个分析过程就叫做逃逸分析。
创新互联是专业的海州网站建设公司，海州接单;提供网站设计制作、网站建设,网页设计,网站设计,建网站,PHP网站建设等专业做网站服务;采用PHP框架,可快速的进行海州网站开发网页制作和功能扩展;专业做搜索引擎喜爱的网站,专业的做网站团队,希望更多企业前来合作!
所以你在一个函数中通过 dict := make(map[string]int) 创建一个 map 变量，其背后的数据是放在栈空间上还是堆空间上，是不一定的。这要看编译器分析的结果。
可逃逸分析并不是百分百准确的，它有缺陷。有的时候你会发现有些变量其实在栈空间上分配完全没问题的，但编译后程序还是把这些数据放在了堆上。如果你了解 Go 语言编译器逃逸分析的机制，在写代码的时候就可以有意识地绕开这些缺陷，使你的程序更高效。
Go 语言虽然在内存管理方面降低了编程门槛，即使你不了解堆栈也能正常开发，但如果你要在性能上较真的话，还是要掌握这些基础知识。
这里不对堆内存和栈内存的区别做太多阐述。简单来说就是， 栈分配廉价，堆分配昂贵。 栈空间会随着一个函数的结束自动释放，堆空间需要时间 GC 模块不断地跟踪扫描回收。如果对这两个概念有些迷糊，建议阅读下面 2 个文章：
这里举一个小例子，来对比下堆栈的差别：
stack 函数中的变量 i 在函数退出会自动释放；而 heap 函数返回的是对变量 i 的引用，也就是说 heap() 退出后，表示变量 i 还要能被访问，它会自动被分配到堆空间上。
他们编译出来的代码如下：
逻辑的复杂度不言而喻，从上面的汇编中可看到， heap() 函数调用了 runtime.newobject() 方法，它会调用 mallocgc 方法从 mcache 上申请内存，申请的内部逻辑前面文章已经讲述过。堆内存分配不仅分配上逻辑比栈空间分配复杂，它最致命的是会带来很大的管理成本，Go 语言要消耗很多的计算资源对其进行标记回收（也就是 GC 成本）。
Go 编辑器会自动帮我们找出需要进行动态分配的变量，它是在编译时追踪一个变量的生命周期，如果能确认一个数据只在函数空间内访问，不会被外部使用，则使用栈空间，否则就要使用堆空间。
我们在 go build 编译代码时，可使用 -gcflags '-m' 参数来查看逃逸分析日志。
以上面的两个函数为例，编译的日志输出是：
日志中的 i escapes to heap 表示该变量数据逃逸到了堆上。
需要使用堆空间，所以逃逸，这没什么可争议的。但编译器有时会将 不需要 使用堆空间的变量，也逃逸掉。这里是容易出现性能问题的大坑。网上有很多相关文章，列举了一些导致逃逸情况，其实总结起来就一句话：
多级间接赋值容易导致逃逸 。
这里的多级间接指的是，对某个引用类对象中的引用类成员进行赋值。Go 语言中的引用类数据类型有 func , interface , slice , map , chan , *Type(指针) 。
记住公式 Data.Field = Value ，如果 Data , Field 都是引用类的数据类型，则会导致 Value 逃逸。这里的等号 = 不单单只赋值，也表示参数传递。
根据公式，我们假设一个变量 data 是以下几种类型，相应的可以得出结论：
下面给出一些实际的例子：
如果变量值是一个函数，函数的参数又是引用类型，则传递给它的参数都会逃逸。
上例中 te 的类型是 func(*int) ，属于引用类型，参数 *int 也是引用类型，则调用 te(j) 形成了为 te 的参数(成员) *int 赋值的现象，即 te.i = j 会导致逃逸。代码中其他几种调用都没有形成 多级间接赋值 情况。
同理，如果函数的参数类型是 slice , map 或 interface{} 都会导致参数逃逸。
匿名函数的调用也是一样的，它本质上也是一个函数变量。有兴趣的可以自己测试一下。
只要使用了 Interface 类型(不是 interafce{} )，那么赋值给它的变量一定会逃逸。因为 interfaceVariable.Method() 先是间接的定位到它的实际值，再调用实际值的同名方法，执行时实际值作为参数传递给方法。相当于 interfaceVariable.Method.this = realValue
向 channel 中发送数据，本质上就是为 channel 内部的成员赋值，就像给一个 slice 中的某一项赋值一样。所以 chan *Type , chan map[Type]Type , chan []Type , chan interface{} 类型都会导致发送到 channel 中的数据逃逸。
这本来也是情理之中的，发送给 channel 的数据是要与其他函数分享的，为了保证发送过去的指针依然可用，只能使用堆分配。
可变参数如 func(arg ...string) 实际与 func(arg []string) 是一样的，会增加一层访问路径。这也是 fmt.Sprintf 总是会使参数逃逸的原因。
例子非常多，这里不能一一列举，我们只需要记住分析方法就好，即，2 级或更多级的访问赋值会 容易 导致数据逃逸。这里加上 容易 二字是因为随着语言的发展，相信这些问题会被慢慢解决，但现阶段，这个可以作为我们分析逃逸现象的依据。
下面代码中包含 2 种很常规的写法，但他们却有着很大的性能差距，建议自己想下为什么。
Benchmark 和 pprof 给出的结果:
熟悉堆栈概念可以让我们更容易看透 Go 程序的性能问题，并进行优化。
多级间接赋值会导致 Go 编译器出现不必要的逃逸，在一些情况下可能我们只需要修改一下数据结构就会使性能有大幅提升。这也是很多人不推荐在 Go 中使用指针的原因，因为它会增加一级访问路径，而 map , slice , interface{} 等类型是不可避免要用到的，为了减少不必要的逃逸，只能拿指针开刀了。
大多数情况下，性能优化都会为程序带来一定的复杂度。建议实际项目中还是怎么方便怎么写，功能完成后通过性能分析找到瓶颈所在，再对局部进行优化。
go程序如何分配堆栈的
在Go语言中有一些调试技巧能帮助我们快速找到问题，有时候你想尽可能多的记录异常但仍觉得不够，搞清楚堆栈的意义有助于定位Bug或者记录更完整的信息。
本文将讨论堆栈跟踪信息以及如何在堆栈中识别函数所传递的参数。
Functions
先从这段代码开始：
Listing 1
01 package main
02
03 func main() {
04 slice := make([]string, 2, 4)
05 Example(slice, "hello", 10)
06 }
07
08 func Example(slice []string, str string, i int) {
09 panic("Want stack trace")
10 }
Example函数定义了3个参数，1个string类型的slice, 1个string和1个integer, 并且抛出了panic，运行这段代码可以看到这样的结果：
Listing 2
Panic: Want stack trace
goroutine 1 [running]:
main.Example(0x2080c3f50, 0x2, 0x4, 0x425c0, 0x5, 0xa)
/Users/bill/Spaces/Go/Projects/src/github.com/goinaction/code/
temp/main.go:9 +0x64
main.main()
/Users/bill/Spaces/Go/Projects/src/github.com/goinaction/code/
temp/main.go:5 +0x85
goroutine 2 [runnable]:
runtime.forcegchelper()
/Users/bill/go/src/runtime/proc.go:90
runtime.goexit()
/Users/bill/go/src/runtime/asm_amd64.s:2232 +0x1
goroutine 3 [runnable]:
runtime.bgsweep()
/Users/bill/go/src/runtime/mgc0.go:82
runtime.goexit()
/Users/bill/go/src/runtime/asm_amd64.s:2232 +0x1
堆栈信息中显示了在panic抛出这个时间所有的goroutines状态，发生的panic的goroutine会显示在最上面。
Listing 3
01 goroutine 1 [running]:
02 main.Example(0x2080c3f50, 0x2, 0x4, 0x425c0, 0x5, 0xa)
/Users/bill/Spaces/Go/Projects/src/github.com/goinaction/code/
temp/main.go:9 +0x64
03 main.main()
/Users/bill/Spaces/Go/Projects/src/github.com/goinaction/code/
temp/main.go:5 +0x85
第1行显示最先发出panic的是goroutine 1, 第二行显示panic位于main.Example中, 并能定位到该行代码，在本例中第9行引发了panic。
下面我们关注参数是如何传递的：
Listing 4
// Declaration
main.Example(slice []string, str string, i int)
// Call to Example by main.
slice := make([]string, 2, 4)
Example(slice, "hello", 10)
// Stack trace
main.Example(0x2080c3f50, 0x2, 0x4, 0x425c0, 0x5, 0xa)
这里展示了在main中带参数调用Example函数时的堆栈信息，比较就能发现两者的参数数量并不相同，Example定义了3个参数，堆栈中显示了6个参数。现在的关键问题是我们要弄清楚它们是如何匹配的。
第1个参数是string类型的slice，我们知道在Go语言中slice是引用类型，即slice变量结构会包含三个部分：指针、长度(Lengthe)、容量(Capacity)
Listing 5
// Slice parameter value
slice := make([]string, 2, 4)
// Slice header values
Pointer: 0x2080c3f50
Length: 0x2
Capacity: 0x4
// Declaration
main.Example(slice []string, str string, i int)
// Stack trace
main.Example(0x2080c3f50, 0x2, 0x4, 0x425c0, 0x5, 0xa)
因此，前面3个参数会匹配slice， 如下图所示：
Figure 1
figure provided by Georgi Knox
我们现在来看第二个参数，它是string类型，string类型也是引用类型，它包括两部分：指针、长度。
Listing 6
// String parameter value
"hello"
// String header values
Pointer: 0x425c0
Length: 0x5
// Declaration
main.Example(slice []string, str string, i int)
// Stack trace
main.Example(0x2080c3f50, 0x2, 0x4, 0x425c0, 0x5, 0xa)
可以确定，堆栈信息中第4、5两个参数对应代码中的string参数，如下图所示：
Figure 2
figure provided by Georgi Knox
最后一个参数integer是single word值。
Listing 7
// Integer parameter value
10
// Integer value
Base 16: 0xa
// Declaration
main.Example(slice []string, str string, i int)
// Stack trace
main.Example(0x2080c3f50, 0x2, 0x4, 0x425c0, 0x5, 0xa)
现在我们可以匹配代码中的参数到堆栈信息了。
Figure 3
figure provided by Georgi Knox
Methods
如果我们将Example作为结构体的方法会怎么样呢?
Listing 8
01 package main
02
03 import "fmt"
04
05 type trace struct{}
06
07 func main() {
08 slice := make([]string, 2, 4)
09
10 var t trace
11 t.Example(slice, "hello", 10)
12 }
13
14 func (t *trace) Example(slice []string, str string, i int) {
15 fmt.Printf("Receiver Address: %p\n", t)
16 panic("Want stack trace")
17 }
如上所示修改代码，将Example定义为trace的方法，并通过trace的实例t来调用Example。
再次运行程序，会发现堆栈信息有一点不同：
Listing 9
Receiver Address: 0x1553a8
panic: Want stack trace
01 goroutine 1 [running]:
02 main.(*trace).Example(0x1553a8, 0x2081b7f50, 0x2, 0x4, 0xdc1d0, 0x5, 0xa)
/Users/bill/Spaces/Go/Projects/src/github.com/goinaction/code/
temp/main.go:16 +0x116
03 main.main()
/Users/bill/Spaces/Go/Projects/src/github.com/goinaction/code/
temp/main.go:11 +0xae
首先注意第2行的方法调用使用了pointer receiver，在package名字和方法名之间多出了"*trace"字样。另外，参数列表的第1个参数标明了结构体(t)地址。我们从堆栈信息中看到了内部实现细节。
Packing
如果有多个参数可以填充到一个single word, 则这些参数值会合并打包：
Listing 10
01 package main
02
03 func main() {
04 Example(true, false, true, 25)
05 }
06
07 func Example(b1, b2, b3 bool, i uint8) {
08 panic("Want stack trace")
09 }
这个例子修改Example函数为4个参数：3个bool型和1个八位无符号整型。bool值也是用8个bit表示，所以在32位和64位架构下，4个参数可以合并为一个single word。
Listing 11
01 goroutine 1 [running]:
02 main.Example(0x19010001)
/Users/bill/Spaces/Go/Projects/src/github.com/goinaction/code/
temp/main.go:8 +0x64
03 main.main()
/Users/bill/Spaces/Go/Projects/src/github.com/goinaction/code/
temp/main.go:4 +0x32
这是本例的堆栈信息，看下图的具体分析：
Listing 12
// Parameter values
true, false, true, 25
// Word value
Bits Binary Hex Value
00-07 0000 0001 01 true
08-15 0000 0000 00 false
16-23 0000 0001 01 true
24-31 0001 1001 19 25
// Declaration
main.Example(b1, b2, b3 bool, i uint8)
// Stack trace
main.Example(0x19010001)
以上展示了参数值是如何匹配到4个参数的。当我们看到堆栈信息中包括十六进制值，需要知道这些值是如何传递的。
Go 语言的错误处理机制是一个优秀的设计吗
这个问题说来话长，我先表达一下我的观点，Go语言从语法层面提供区分错误和异常的机制是很好的做法，比自己用单个返回值做值判断要方便很多。
上面看到很多知乎大牛把异常和错误混在一起说，有认为Go没有异常机制的，有认为Go纯粹只有异常机制的，我觉得这些观点都太片面了。
具体对于错误和异常的讨论，我转发一下前阵子写的一篇日志抛砖引玉吧。
============================
最近连续遇到朋友问我项目里错误和异常管理的事情，之前也多次跟团队强调过错误和异常管理的一些概念，所以趁今天有动力就赶紧写一篇Go语言项目错误和异常管理的经验分享。
首先我们要理清：什么是错误、什么是异常、为什么需要管理。然后才是怎样管理。
错误和异常从语言机制上面讲，就是error和panic的区别，放到别的语言也一样，别的语言没有error类型，但是有错误码之类的，没有panic，但是有throw之类的。
在语言层面它们是两种概念，导致的是两种不同的结果。如果程序遇到错误不处理，那么可能进一步的产生业务上的错误，比如给用户多扣钱了，或者进一步产生了异常；如果程序遇到异常不处理，那么结果就是进程异常退出。
在项目里面是不是应该处理所有的错误情况和捕捉所有的异常呢？我只能说，你可以这么做，但是估计效果不会太好。我的理由是：
如果所有东西都处理和记录，那么重要信息可能被淹没在信息的海洋里。
不应该处理的错误被处理了，很容易导出BUG暴露不出来，直到出现更严重错误的时候才暴露出问题，到时候排查就很困难了，因为已经不是错误的第一现场。
所以错误和异常最好能按一定的规则进行分类和管理，在第一时间能暴露错误和还原现场。
对于错误处理，Erlang有一个很好的概念叫速错，就是有错误第一时间暴露它。我们的项目从Erlang到Go一直是沿用这一设计原则。但是应用这个原则的前提是先得区分错误和异常这两个概念。
错误和异常上面已经提到了，从语言机制层面比较容易区分它们，但是语言取决于人为，什么情况下用错误表达，什么情况下用异常表达，就得有一套规则，否则很容易出现全部靠异常来做错误处理的情况，似乎Java项目特别容易出现这样的设计。
这里我先假想有这样一个业务：游戏玩家通过购买按钮，用铜钱购买宝石。
在实现这个业务的时候，程序逻辑会进一步分化成客户端逻辑和服务端逻辑，客户端逻辑又进一步因为设计方式的不同分化成两种结构：胖客户端结构、瘦客户端结构。
胖客户端结构，有更多的本地数据和懂得更多的业务逻辑，所以在胖客户端结构的应用中，以上的业务会实现成这样：客户端检查缓存中的铜钱数量，铜钱数量足够的时候购买按钮为可用的亮起状态，用户点击购买按钮后客户端发送购买请求到服务端；服务端收到请求后校验用户的铜钱数量，如果铜钱数量不足就抛出异常，终止请求过程并断开客户端的连接，如果铜钱数量足够就进一步完成宝石购买过程，这里不继续描述正常过程。
因为正常的客户端是有一步数据校验的过程的，所以当服务端收到不合理的请求（铜钱不足以购买宝石）时，抛出异常比返回错误更为合理，因为这个请求只可能来自两种客户端：外挂或者有BUG的客户端。如果不通过抛出异常来终止业务过程和断开客户端连接，那么程序的错误就很难被第一时间发现，攻击行为也很难被发现。
我们再回头看瘦客户端结构的设计，瘦客户端不会存有太多状态数据和用户数据也不清楚业务逻辑，所以客户端的设计会是这样：用户点击购买按钮，客户端发送购买请求；服务端收到请求后检查铜钱数量，数量不足就返回数量不足的错误码，数量足够就继续完成业务并返回成功信息；客户端收到服务端的处理结果后，在界面上做出反映。
在这种结构下，铜钱不足就变成了业务逻辑范围内的一种失败情况，但不能提升为异常，否则铜钱不足的用户一点购买按钮都会出错掉线。
所以，异常和错误在不同程序结构下是互相转换的，我们没办法一句话的给所有类型所有结构的程序一个统一的异常和错误分类规则。
但是，异常和错误的分类是有迹可循的。比如上面提到的痩客户端结构，铜钱不足是业务逻辑范围内的一种失败情况，它属于业务错误，再比如程序逻辑上尝试请求某个URL，最多三次，重试三次的过程中请求失败是错误，重试到第三次，失败就被提升为异常了。
所以我们可以这样来归类异常和错误：不会终止程序逻辑运行的归类为错误，会终止程序逻辑运行的归类为异常。
因为错误不会终止逻辑运行，所以错误是逻辑的一部分，比如上面提到的瘦客户端结构，铜钱不足的错误就是业务逻辑处理过程中需要考虑和处理的一个逻辑分支。而异常就是那些不应该出现在业务逻辑中的东西，比如上面提到的胖客户端结构，铜钱不足已经不是业务逻辑需要考虑的一部分了，所以它应该是一个异常。
错误和异常的分类需要通过一定的思维训练来强化分类能力，就类似于面向对象的设计方式一样的，技术实现就摆在那边，但是要用好需要不断的思维训练不断的归类和总结，以上提到的归类方式希望可以作为一个参考，期待大家能发现更多更有效的归类方式。
接下来我们讲一下速错和Go语言里面怎么做到速错。
速错我最早接触是在做的时候就体验到的，当然跟Erlang的速错不完全一致，那时候也没有那么高大上的一个名字，但是对待异常的理念是一样的。
在.NET项目开发的时候，有经验的程序员都应该知道，不能随便re-throw，就是catch错误再抛出，原因是异常的第一现场会被破坏，堆栈跟踪信息会丢失，因为外部最后拿到异常的堆栈跟踪信息，是最后那次throw的异常的堆栈跟踪信息；其次，不能随便try catch，随便catch很容易导出异常暴露不出来，升级为更严重的业务漏洞。
到了Erlang时期，大家学到了速错概念，简单来讲就是：让它挂。只有挂了你才会第一时间知道错误，但是Erlang的挂，只是Erlang进程的异常退出，不会导致整个Erlang节点退出，所以它挂的影响层面比较低。
在Go语言项目中，虽然有类似Erlang进程的Goroutine，但是Goroutine如果panic了，并且没有recover，那么整个Go进程就会异常退出。所以我们在Go语言项目中要应用速错的设计理念，就要对Goroutine做一定的管理。
在我们的游戏服务端项目中，我把Goroutine按挂掉后的结果分为两类：1、挂掉后不影响其他业务或功能的；2、挂掉后业务就无法正常进行的。
第一类Goroutine典型的有：处理各个玩家请求的Goroutine，因为每个玩家连接各自有一个Goroutine，所以挂掉了只会影响单个玩家，不会影响整体业务进行。
第二类Goroutine典型的有：数据库同步用的Goroutine，如果它挂了，数据就无法同步到数据库，游戏如果继续运行下去只会导致数据回档，还不如让整个游戏都异常退出。
这样一分类，就可以比较清楚哪些Goroutine该做recover处理，哪些不该做recover处理了。
那么在做recover处理时，要怎样才能尽量保留第一现场来帮组开发者排查问题原因呢？我们项目中通常是会在最外层的recover中把错误和堆栈跟踪信息记进日志，同时把关键的业务信息，比如：用户ID、来源IP、请求数据等也一起记录进去。
为此，我们还特地设计了一个库，用来格式化输出堆栈跟踪信息和对象信息，项目地址：funny/debug · GitHub
通篇写下来发现比我预期的长很多，所以这里我做一下归纳总结，帮组大家理解这篇文章所要表达的：
错误和异常需要分类和管理，不能一概而论
错误和异常的分类可以以是否终止业务过程作为标准
错误是业务过程的一部分，异常不是
不要随便捕获异常，更不要随便捕获再重新抛出异常
Go语言项目需要把Goroutine分为两类，区别处理异常
在捕获到异常时，需要尽可能的保留第一现场的关键数据
以上仅为一家之言，抛砖引玉，希望对大家有所帮助。
当前名称：关于go语言日志错误堆栈的信息
文章分享：http://scjbc.cn/article/hjsdsj.html
