关于后端:go系列注释里的黑魔法

背景

最近在看 go 的源码的时候陆续看到很多在正文中应用的 go 指令，看的让人很是懵逼，本文次要是针对 go 源码中的这些正文中应用 go 指令的中央进行具体介绍

常见的正文中应用 go 指令汇合

我在 go 的源码里收罗下关键字统计下有以下几类常见的正文中应用的 go 指令

起源一览

// 起源 src/runtime/internal/atomic/atomic\_wasm.go
// go:linkname Load
// 起源 src/runtime/syscall\_solaris.go
//go:linkname pipe1x runtime.pipe1

// 起源 src/runtime/syscall\_aix.go
//go:cgo\_import\_dynamic libc\_chdir chdir "libc.a/shr\_64.o"

// 起源 src/runtime/sys\_openbsd2.go
//go:build (openbsd && amd64) || (openbsd && arm64)
// 起源 src/runtime/internal/atomic/atomic\_riscv64.go
//go:noescape

// 起源 src/cmd/compile/internal/test/shift\_test.go
//go:noinline

// 起源 src/cmd/go/main.go
//go:generate ./mkalldocs.sh

// 起源 src/embed/internal/embedtest/embed\_test.go
//go:embed testdata/h\*.txt
//go:embed c\*.txt testdata/g\*.txt
var global embed.FS
// 起源 src/runtime/internal/atomic/atomic\_wasm.go
//go:nosplit
//go:noinline
func Load(ptr \*uint32) uint32 {return \*ptr}
// 起源 src/syscall/syscall\_linux.go
//go:nosplit
//go:norace
func (pc \*allThreadsCaller) doSyscall(initial bool) bool {r1, r2, err := RawSyscall(pc.trap, pc.a1, pc.a2, pc.a3)

常见的正文中应用的 go 指令预览

指令名称

应用办法

备注

linkname

//go:linkname local remote

remote 能够没有，此时 remote 应用 local 的值，成果就是 local 被导出

build

//go:build (openbsd && amd64) || (openbsd && arm64)

generate

//go:generate ./mkalldocs.sh

当运行 go generate 时，它将扫描与以后包相干的源代码文件，找出所有蕴含 ”//go:generate” 的非凡正文，提取并执行该非凡正文前面的命令，命令为可执行程序，形同 shell 上面执行

cgo\_import\_dynamic

//go:cgo\_import\_dynamic libc\_res\_search res\_search “/usr/lib/libSystem.B.dylib”

这是一个链接器指令，通知能够从动静库 (LIBC) 中加载某个性能和能力

当链接器在编译后运行时，它将执行此指令。链接器 res\_search 从 libSystem 动静库（在给定门路中找到）中提取例程。而后，该例程将名称命名为在 Go 的汇编代码中可援用的例程 libc\_res\_search。

noinline

//go:noinline

字面意思“不要内联”

InLine，是在编译期间产生的，将函数调用调用处替换为被调用函数主体的一种编译器优化伎俩。

nosplit

//go:nosplit

跳过栈溢出检测

noescape

//go:noescape

禁止逃逸，而且它必须批示一个只有申明没有主体的函数

norace

//go:norace

跳过竞态检测

embed

//go:embed

动态资源嵌入性能 go 1.16 反对的新性能

正文中应用 go 指令办法

// 后不能有空格。有些人可能习惯 // 后不加空格。goland 的 IDE 会在正文前面主动加上空格，这个坑还是有恶心

go:linkname

//go:linkname local remote

• local remote 能够是占位符和函数
• remote 如果缺省的话示意 local 被导出
• local 作为占位符，remote 作为实现者

• local 作为实现者，remote 作为占位符

• 也存在 一个占位符 + 一个汇编函数

go:embed

应用正则规定形容

动态资源嵌入性能, 详情引入规定如下

//go:embed images
这是匹配所有位于 /tmp/proj/images 及其子目录中的文件

//go:embed images/jpg/a.jpg
匹配 /tmp/proj/images/jpg/a.jpg 这一个文件

//go:embed a.txt
匹配 /tmp/proj/a.txt
//go:embed images/jpg/\*.jpg
匹配 /tmp/proj/images/jpg 下所有.jpg 文件

//go:embed images/jpg/a?.jpg
匹配 /tmp/proj/images/jpg 下的 a1.jpg a2.jpg ab.jpg 等

//go:embed images/??g/\*.\*
匹配 /tmp/proj/images 下的 jpg 和 png 文件夹里的所有有后缀名的文件，例如 png/123.png jpg/a.jpeg
//go:embed \*
间接匹配整个 /tmp/proj

//go:embed a.txt
//go:embed \*.png \*.jpg
//go:embed aa.jpg
能够指定多个 //go:embed 指令行，之间不能有空行，也能够用空格在一行里写上对个模式匹配，示意匹配所有这些文件，相当于并集操作
能够蕴含反复的文件或是模式串，golang 对于雷同的文件只会嵌入一次，很智能

如何应用 embed

//go:embed imgs/screenrecord.gif

var gif \[\]byte

//go:embed imgs/png/a.png

var png \[\]byte

func main() {fmt.Println("gif size:", len(gif)) // gif size: 81100466

    fmt.Println("png size:", len(png)) // png size: 4958264

}

go:generate

go generate 命令是 go 1.4 版本外面新增加的一个命令，当运行 go generate 时，它将扫描与以后包相干的源代码文件，找出所有蕴含 ”//go:generate” 的非凡正文，提取并执行该非凡正文前面的命令，命令为可执行程序，形同 shell 上面执行

应用场景

在有些场景下，咱们会应用 go generate：

在 build 之前生成一些特定文件（下文介绍）

yacc：从 .y 文件生成 .go 文件.

protobufs：从 protocol buffer 定义文件（.proto）生成 .pb.go 文件。

Unicode：从 UnicodeData.txt 生成 Unicode 表.

注意事项

必须在.go 源码文件中

每个源码文件能够蕴含多个 generate 非凡正文时

显示运行 go generate 命令时，才会执行非凡正文前面的命令

如果后面的正文执行出错，则终止执行

go:noinline 不要内联

首先搞清楚什么是内联：内联是在编译期间产生的，将函数调用调用处替换为被调用函数主体的一种编译器优化伎俩

应用 InLine 有一些劣势，同样也有一些问题。

应用劣势：

缩小函数调用的开销，进步执行速度。

复制后的更大函数体为其余编译优化带来可能性，如过程间优化

打消分支，并改善空间局部性和指令程序性，同样能够进步性能。

应用问题：

代码复制带来的空间增长。

如果有大量反复代码，反而会升高缓存命中率，尤其对 CPU 缓存是致命的。

所以，在理论应用中，对于是否应用内联，要审慎思考，并做好均衡，以使它施展最大的作用。

简略来说，对于短小而且工作较少的函数，应用内联是有效益的。

go:nosplit 跳过栈溢出检测

栈溢出是什么？

正是因为一个 Goroutine 的起始栈大小是有限度的，且比拟小的，才能够做到反对并发很多 Goroutine，并高效调度。

stack.go 源码中能够看到，\_StackMin 是 2048 字节，也就是 2k，它不是变化无穷的，当不够用时，它会动静地增长。

那么，必然有一个检测的机制，来保障能够及时地晓得栈不够用了，而后再去增长。

回到话题，nosplit 就是将这个跳过这个机制。

优劣

显然地，不执行栈溢出检查，能够进步性能，但同时也有可能产生 stack overflow 而导致编译失败。

go:noescape 禁止逃逸

禁止逃逸，而且它必须批示一个只有申明没有主体的函数

逃逸是什么？

Go 相比 C、C++ 是内存更为平安的语言，次要一个点就体现在它能够主动地将超出本身生命周期的变量，从函数栈转移到堆中，逃逸就是指这种行为

优劣

最不言而喻的益处是，GC 压力变小了。

因为它曾经通知编译器，上面的函数无论如何都不会逃逸，那么当函数返回时，其中的资源也会一并都被销毁。不过，这么做代表会绕过编译器的逃逸查看，一旦进入运行时，就有可能导致重大的谬误及结果。

go:norace 跳过竞态检测

在多线程程序中，难免会呈现数据竞争，失常状况下，当编译器检测到有数据竞争，就会给出提醒

执行 go run -race main.go 利用 -race 来使编译器报告数据竞争问题。

优劣

应用 norace 除了缩小编译工夫，我想不到有其余的长处了。但毛病却很显著，那就是数据竞争会导致程序的不确定性。

go:build

在源代码里增加标注，通常称之为编译标签(build tag)

编译标签是在尽量凑近源代码文件顶部的中央用正文的形式增加

go build 在构建一个包的时候会读取这个包里的每个源文件并且剖析编译便签，这些标签决定了这个源文件是否参加本次编译

//go:build aix || darwin || dragonfly || freebsd || linux || netbsd || openbsd || solaris
…
//go:build !linux

go: cgo\_import\_dynamic

//go:cgo_import_dynamic libc_res_search res_search "/lib/libSystem.B.dylib"

当编辑器在编译后运行时，它将执行此指令。编辑器 res\_search 从 libSystem 动静库（在给定门路中找到）中提取列程。而后，该过程将名称命名为在 Go 的汇编代码中可援用的例程 libc\_res\_search

咱们就可能应用 go tool cgo -dynimport 命令查看所有从 libc 中的导入的性能信息

参考文章

https://www.grant.pizza/blog/…

https://blog.csdn.net/weixin\_44264674/article/details/107780595

https://github.com/golang/go

https://mp.weixin.qq.com/s/4OlbpQwchWwxnQmSOL6xYA