go语言内联 go语言nil

为什么我不会舍弃Python投奔Go语言

在Go语言中，规定的方式是，函数返回错误信息。这没什么。如果一个文件并不存在，op.Open函数会返回一个错误信息。这没什么。如果你向你一个中断了的网络连接里写数据，net.Conn里的Write方法会返回一个错误。这没什么。这种状况在这种程序中是可以预料到的。这种操作就是容易失败，你知道程序会如何运行，因为API的设计者通过内置了一种错误情况的结果而让这一切显得很清楚。

网站建设哪家好，找成都创新互联！专注于网页设计、网站建设、微信开发、小程序定制开发、集团企业网站建设等服务项目。为回馈新老客户创新互联还提供了双江免费建站欢迎大家使用！

从另一方面讲，有些操作基本上不会出错，所处的环境根本不可能给你提示错误信息，不可能控制错误。这才是让人痛苦的地方。典型的例子；一个程序执行

x[j]，j值超出数组边界，这才痛苦。像这样预料之外的麻烦在程序中是一个严重的bug，一般会弄死程序的运行。不幸的是，由于这种情况的存在，我们很难写出健壮的，具有自我防御的服务器——例如，可以应付偶然出现的有bug的HTTP请求处理器时，不影响其他服务的启动和运行。为解决这个问题，我们引入了恢复机制，它能让一个go例程从错误中恢复，服务余下设定的调用。然而，代价是，至少会丢失一个调用。这是特意而为之的。引用邮件中的原话：“这种设计不同于常见的异常控制结构，这是一个认真思考后的决定。我们不希望像java语言里那样把错误和异常混为一谈。”

我刚开始提到的那篇文章里问“为什么数组越界造成的麻烦会比错误的网址或断掉的网络引出的问题要大？”答案是，我们没有一种内联并行的方法来报告在执行x[j]期间产生的错误，但我们有内联并行的方法报告由错误网址或网络问题造成的错误。

使用Go语言中的错误返回模式的规则很简单：如果你的函数在某种情况下很容易出错，那它就应该返回错误。当我调用其它的程序库时，如果它是这样写的，那我不必担心那些错误的产生，除非有真正异常的状况，我根本没有想到需要处理它们。

有一个你需要记在心里的事情是，Go语言是为大型软件设计的。我们都喜欢程序简洁清晰，但对于一个由很多程序员一起开发的大型软件，维护成本的增加很难让程序简洁。异常捕捉模式的错误处理方式的一个很有吸引力的特点是，它非常适合小程序。但对于大型程序库，如果对于一些普通操作，你都需要考虑每行代码是否会抛出异常、是否有必要捕捉处理，这对于开发效率和程序员的时间来说都是非常严重的拖累。我自己做开发大型Python软件时感受到了这个问题。

Go语言的返回错误方式，不可否认，对于调用者不是很方便，但这样做会让程序中可能会出错的地方显的很明显。对于小程序来说，你可能只想打印出错误，退出程序。对于一些很精密的程序，根据异常的不同，来源的不同，程序会做出不同的反应，这很常见，这种情况中，try

+

catch的方式相对于错误返回模式显得冗长。当然，Python里的一个10行的代码放到Go语言里很可能会更冗长。毕竟，Go语言主要不是针对10行规模的程序的。

就是要说明这一点：Go语言程序员认为，把error作为一种内置的类型是非常重要的。

1.14版本defer性能大幅度提升，内部实现了开放编码优化

GO中的defer会在当前函数返回前执行传入的函数，常用于关闭文件描述符，关闭链接及解锁等操作。

Go语言中使用defer时会遇到两个常见问题：

接下来我们来详细处理这两个问题。

官方有段对defer的解释：

这里我们先来一道经典的面试题

你觉得这个会打印什么？

输出结果：

这里是遵循先入后出的原则，同时保留当前变量的值。

把这道题简化一下：

输出结果

上述代码输出似乎不符合预期，这个现象出现的原因是什么呢？经过分析，我们发现调用defer关键字会立即拷贝函数中引用的外部参数，所以fmt.Println(i)的这个i是在调用defer的时候就已经赋值了，所以会直接打印1。

想要解决这个问题也很简单，只需要向defer关键字传入匿名函数

这里把一些垃圾回收使用的字段忽略了。

中间代码生成阶段cmd/compile/internal/gc/ssa.go会处理程序中的defer，该函数会根据条件不同，使用三种机制来处理该关键字

开放编码、堆分配和栈分配是defer关键字的三种方法，而Go1.14加入的开放编码，使得关键字开销可以忽略不计。

call方法会为所有函数和方法调用生成中间代码，工作内容：

defer关键字在运行时会调用deferproc，这个函数实现在src/runtime/panic.go里，接受两个参数：参数的大小和闭包所在的地址。

编译器不仅将defer关键字转成deferproc函数，还会通过以下三种方式为所有调用defer的函数末尾插入deferreturn的函数调用

1、在cmd/compile/internal/gc/walk.go的walkstmt函数中，在遇到ODEFFER节点时会执行Curfn.Func.SetHasDefer(true)，设置当前函数的hasdefer属性

2、在ssa.go的buildssa会执行s.hasdefer = fn.Func.HasDefer()更新hasdefer

3、在exit中会根据hasdefer在函数返回前插入deferreturn的函数调用

runtime.deferproc为defer创建了一个runtime._defer结构体、设置它的函数指针fn、程序计数器pc和栈指针sp并将相关参数拷贝到相邻的内存空间中

最后调用的return0是唯一一个不会触发延迟调用的函数，可以避免deferreturn的递归调用。

newdefer的分配方式是从pool缓存池中获取：

这三种方式取到的结构体_defer，都会被添加到链表的队头，这也是为什么defer按照后进先出的顺序执行。

deferreturn就是从链表的队头取出并调用jmpdefer传入需要执行的函数和参数。

该函数只有在所有延迟函数都执行后才会返回。

如果我们能够将部分结构体分配到栈上就可以节约内存分配带来的额外开销。

在call函数中有在栈上分配

在运行期间deferprocStack只需要设置一些未在编译期间初始化的字段，就可以将栈上的_defer追加到函数的链表上。

除了分配的位置和堆的不同，其他的大致相同。

Go语言在1.14中通过开放编码实现defer关键字，使用代码内联优化defer关键的额外开销并引入函数数据funcdata管理panic的调用，该优化可以将 defer 的调用开销从 1.13 版本的 ~35ns 降低至 ~6ns 左右。

然而开放编码作为一种优化 defer 关键字的方法，它不是在所有的场景下都会开启的，开放编码只会在满足以下的条件时启用：

如果函数中defer关键字的数量多于8个或者defer处于循环中，那么就会禁用开放编码优化。

可以看到这里，判断编译参数不用-N，返回语句的数量和defer数量的乘积小于15，会启用开放编码优化。

延迟比特deferBitsTemp和延迟记录是使用开放编码实现defer的两个最重要的结构，一旦使用开放编码，buildssa会在栈上初始化大小为8个比特的deferBits

延迟比特中的每一个比特位都表示该位对应的defer关键字是否需要被执行。延迟比特的作用就是标记哪些defer关键字在函数中被执行，这样就能在函数返回时根据对应的deferBits确定要执行的函数。

而deferBits的大小为8比特，所以该优化的条件就是defer的数量小于8.

而执行延迟调用的时候仍在deferreturn

这里做了特殊的优化，在runOpenDeferFrame执行开放编码延迟函数

1、从结构体_defer读取deferBits，执行函数等信息

2、在循环中依次读取执行函数的地址和参数信息，并通过deferBits判断是否要执行

3、调用reflectcallSave执行函数

1、新加入的defer放入队头，执行defer时是从队头取函数调用，所以是后进先出

2、通过判断defer关键字、return数量来判断是否开启开放编码优化

3、调用deferproc函数创建新的延迟调用函数时，会立即拷贝函数的参数，函数的参数不会等到真正执行时计算

bpftrace动态追踪golang应用-函数内联问题

在上一篇文章的golang代码中，函数add的上一行，增加了一条注释语句： //go:noinline 。在bpftrace追踪时，是否可以去掉？有什么作用？

为了说明该问题，设计一个例子。

golang代码中，有两个求和函数。其中，add1加上 //go:noinline ，另一个add2不加。代码如下：

bpftrace程序分别对函数add1和add2的输入参数、返回值进行追踪，代码如下：

执行程序后，可以看到bpftrace程序能够正常追踪到函数add1，但是无法追踪到函数add2。

通过上文中的示例代码，可以看到，没有加 //go:noinline 的函数无法被bpftrace程序追踪到。通过查阅golang相关文档，可以知道， //go:noinline 表示该函数在编译时，不会被内联。

使用 objump -S 生成golang程序的汇编代码如下：

通过汇编代码，我们可以看到，主函数中，地址 0x498e52 处 callq 498e00 调用了add1函数，地址 0x498ebb 处 movq $0x4,(%rsp) 直接计算求值。

因此，golang编译器在编译代码时，会对代码进行分析，并按照内联规则，将某些函数生成内联代码。一旦函数被内联，bpftrace将无法追踪到对应函数。也就是，上文中函数 add2 无法被追踪到。

针对golang程序中编译器内联的问题，可以通过禁止内联的方式来解决。禁止内联的方式有：

在实践中，可以通过 go build -gcflags="-m -m" 来查看，哪些函数会在编译时执行内联，如：

从输出中，可以看到：

关于golang编译器进行内联的场景，可以参考golang源码：。

由于golang编译器内联优化，bpftrace可能无法正常追踪golang程序。在编写bpftrace脚本时，可以先使用 nm 命令查看一下可执行程序，是否存在需要追踪的函数的符号信息。如果没有则bpftrace将不能对其进行追踪。

前面的示例中，都是对 int 类型的参数进行追踪，那对于 string 类型的参数，是否也可以用同样的方式进行追踪？将在下一篇中进行讨论。