标签 C 下的文章

一文搞懂Go语言的plugin

本文永久链接 – https://tonybai.com/2021/07/19/understand-go-plugin

要历数Go语言中还有哪些我还没用过的特性,在Go 1.8版本中引入的go plugin算一个。近期想给一个网关类平台设计一个插件系统,于是想起了go plugin^_^。

Go plugin支持将Go包编译为共享库(.so)的形式单独发布,主程序可以在运行时动态加载这些编译为动态共享库文件的go plugin,从中提取导出(exported)变量或函数的符号并在主程序的包中使用。Go plugin的这种特性为Go开发人员提供更多的灵活性,我们可以用之实现支持热插拔的插件系统。

但不得不提到的一个事实是:go plugin自诞生以来已有4年多了,但它依旧没有被广泛地应用起来。究其原因,(我猜)一方面Go自身支持静态编译,可以将应用编译为一个完全不需要依赖操作系统运行时库(一般为libc)的可执行文件,这是Go的优势,而支持go plugin则意味着你只能对主程序进行动态编译,与静态编译的优势相悖;而另外一方面原因占比更大,那就是Go plugin自身有太多的对使用者的约束,这让很多Go开发人员望而却步。

只有亲历,才能体会到其中的滋味。在这篇文章中,我们就一起来看看go plugin究竟是何许东东,它对使用者究竟有着怎样的约束,我们究竟要不要使用它。

1. go plugin的基本使用方法

截至Go 1.16版本,Go官方文档明确说明go plugin只支持Linux, FreeBSD和macOS,这算是go plugin的第一个约束。在处理器层面,go plugin以支持amd64(x86-64)为主,对arm系列芯片的支持似乎没有明确说明(我翻看各个Go版本release notes也没看到,也许是我漏掉了),但我在华为的泰山服务器(鲲鹏arm64芯片)上使用Go 1.16.2(for arm64)版本构建plugin包以及加载动态共享库.so文件的主程序都顺利通过编译,运行也一切正常。

主程序通过plugin包加载.so并提取.so文件中的符号的过程与C语言应用运行时加载动态链接库并调用库中函数的过程如出一辙。下面我们就来看一个直观的例子。

下面是这个例子的结构布局:

// github.com/bigwhite/experiments/tree/master/go-plugin

├── demo1
│   ├── go.mod
│   ├── main.go
│   └── pkg
│       └── pkg1
│           └── pkg1.go
└── demo1-plugins
    ├── Makefile
    ├── go.mod
    └── plugin1.go

其中demo1代表主程序工程,demo1-plugins是主程序的plugins工程。下面是插件工程的代码:

// github.com/bigwhite/experiments/tree/master/go-plugin/demo1-plugins/plugin1.go

package main

import (
    "fmt"
    "log"
)

func init() {
    log.Println("plugin1 init")
}

var V int

func F() {
    fmt.Printf("plugin1: public integer variable V=%d\n", V)
}

type foo struct{}

func (foo) M1() {
    fmt.Println("plugin1: invoke foo.M1")
}

var Foo foo

plugin包和普通的Go包没太多区别,只是plugin包有一个约束:其包名必须为main,我们使用下面命令编译该plugin:

$go build -buildmode=plugin -o plugin1.so plugin1.go

如果plugin源代码没有放置在main包下面,我们在编译plugin时会遭遇如下编译器错误:

-buildmode=plugin requires exactly one main package

接下来,我们来看主程序(demo1):

package main

import (
    "fmt"

    "github.com/bigwhite/demo1/pkg/pkg1"
)

func main() {
    err := pkg1.LoadAndInvokeSomethingFromPlugin("../demo1-plugins/plugin1.so")
    if err != nil {
        fmt.Println("LoadAndInvokeSomethingFromPlugin error:", err)
        return
    }
    fmt.Println("LoadAndInvokeSomethingFromPlugin ok")
}

下面是主程序demo1工程中的关键代码:

// github.com/bigwhite/experiments/tree/master/go-plugin/demo1/main.go
package main

import (
    "fmt"

    "github.com/bigwhite/demo1/pkg/pkg1"
)

func main() {
    err := pkg1.LoadAndInvokeSomethingFromPlugin("../demo1-plugins/plugin1.so")
    if err != nil {
        fmt.Println("LoadAndInvokeSomethingFromPlugin error:", err)
        return
    }
    fmt.Println("LoadAndInvokeSomethingFromPlugin ok")
}

我们在main函数中调用pkg1包的LoadAndInvokeSomethingFromPlugin函数,该函数会加载main函数传入的go plugin、查找plugin中相应符号并通过这些符号使用plugin中的导出变量、函数等。下面是LoadAndInvokeSomethingFromPlugin函数的实现:

// github.com/bigwhite/experiments/tree/master/go-plugin/demo1/pkg/pkg1/pkg1.go

package pkg1

import (
    "errors"
    "plugin"
    "log"
)

func init() {
    log.Println("pkg1 init")
}

type MyInterface interface {
    M1()
}

func LoadAndInvokeSomethingFromPlugin(pluginPath string) error {
    p, err := plugin.Open(pluginPath)
    if err != nil {
        return err
    }

    // 导出整型变量
    v, err := p.Lookup("V")
    if err != nil {
        return err
    }
    *v.(*int) = 15

    // 导出函数变量
    f, err := p.Lookup("F")
    if err != nil {
        return err
    }
    f.(func())()

    // 导出自定义类型变量
    f1, err := p.Lookup("Foo")
    if err != nil {
        return err
    }
    i, ok := f1.(MyInterface)
    if !ok {
        return errors.New("f1 does not implement MyInterface")
    }
    i.M1()

    return nil
}

在LoadAndInvokeSomethingFromPlugin函数中,我们通过plugin包提供的Plugin类型提供的Lookup方法在加载的.so中查找相应的导出符号,比如上面的V、F和Foo等。Lookup方法返回plugin.Symbol类型,而Symbol类型定义如下:

// $GOROOT/src/plugin/plugin.go
type Symbol interface{}

我们看到Symbol的底层类型(underlying type)是interface{},因此它可以承载从plugin中找到的任何类型的变量、函数(得益于函数是一等公民)的符号。而plugin中定义的类型则是不能被主程序查找的,通常主程序也不会依赖plugin中定义的类型。

一旦Lookup成功,我们便可以将符号通过类型断言(type assert)获取到其真实类型的实例,通过这些实例(变量或函数),我们可以调用plugin中实现的逻辑。编译plugin后,运行上述主程序,我们可以看到如下结果:

$go run main.go
2021/06/15 10:05:22 pkg1 init
try to LoadAndInvokeSomethingFromPlugin...
2021/06/15 10:05:22 plugin1 init
plugin1: public integer variable V=15
plugin1: invoke foo.M1
LoadAndInvokeSomethingFromPlugin ok

那么,主程序是如何知道导出的符号究竟是函数还是变量呢?这取决于主程序插件系统的设计,因为主程序与plugin间必然要有着某种“契约”或“约定”。就像上面主程序定义的MyInterface接口类型,它就是一个主程序与plugin之间的约定,plugin中只要暴露实现了该接口的类型实例,主程序便可以通过MyInterface接口类型实例与其建立关联并调用plugin中的实现 。

2. plugin中包的初始化

在上面的例子中我们看到,插件的初始化(plugin1 init)发生在主程序open .so文件时。按照官方文档的说法:“当一个插件第一次被open时,plugin中所有不属于主程序的包的init函数将被调用,但一个插件只被初始化一次,而且不能被关闭”。

我们来验证一下在主程序中多次加载同一个plugin的情况,这次我们将程序升级为demo2和demo2-plugins:

主程序代码如下:

// github.com/bigwhite/experiments/tree/master/go-plugin/demo2/main.go

package main

import (
    "fmt"

    "github.com/bigwhite/demo2/pkg/pkg1"
)

func main() {
    fmt.Println("try to LoadPlugin...")
    err := pkg1.LoadPlugin("../demo2-plugins/plugin1.so")
    if err != nil {
        fmt.Println("LoadPlugin error:", err)
        return
    }
    fmt.Println("LoadPlugin ok")
    err = pkg1.LoadPlugin("../demo2-plugins/plugin1.so")
    if err != nil {
        fmt.Println("Re-LoadPlugin error:", err)
        return
    }
    fmt.Println("Re-LoadPlugin ok")
}

package pkg1

import (
    "log"
    "plugin"
)

func init() {
    log.Println("pkg1 init")
}

func LoadPlugin(pluginPath string) error {
    _, err := plugin.Open(pluginPath)
    if err != nil {
        return err
    }
    return nil
}

由于仅是验证初始化,我们去掉了查找符号和调用的环节。plugin的代码如下:

// github.com/bigwhite/experiments/tree/master/go-plugin/demo2-plugins/plugin1.go
package main

import (
    "log"

    _ "github.com/bigwhite/common"
)

func init() {
    log.Println("plugin1 init")
}

在demo2的plugin中,我们同样仅保留初始化相关的代码,这里我们在demo2的plugin1中还增加了一个外部依赖:github.com/bigwhite/common。

运行上述代码:

$go run main.go
2021/06/15 10:50:47 pkg1 init
try to LoadPlugin...
2021/06/15 10:50:47 common init
2021/06/15 10:50:47 plugin1 init
LoadPlugin ok
Re-LoadPlugin ok

通过这个输出结果,我们验证了两点说法:

  • 重复加载同一个plugin,不会触发多次plugin包的初始化,上述结果中仅输出一次:“plugin1 init”;
  • plugin中依赖的包,但主程序中没有的包,在加载plugin时,这些包会被初始化,如:“commin init”。

如果主程序也依赖github.com/bigwhite/common包,我们在主程序的main包中增加一行:

// github.com/bigwhite/experiments/tree/master/go-plugin/demo2/main.go
import (
    "fmt"   

    _ "github.com/bigwhite/common"    // 增加这一行
    "github.com/bigwhite/demo2/pkg/pkg1"
)

那么我们再执行demo2,输出如下结果:

2021/06/15 11:00:00 common init
2021/06/15 11:00:00 pkg1 init
try to LoadPlugin...
2021/06/15 11:00:00 plugin1 init
LoadPlugin ok
Re-LoadPlugin ok

我们看到common包在demo2主程序中已经做了初始化,这样当加载plugin时,common包不会再进行初始化了。

3. go plugin的使用约束

开篇我们就提到了,go plugin应用不甚广泛的一个主因是其约束较多,这里我们来看一下究竟go plugin都有哪些约束:

1) 主程序与plugin的共同依赖包的版本必须一致

在上面demo2中,主程序和plugin依赖的github.com/bigwhite/common包是一个本地module,我们在go.mod中使用replace指向本地路径:

// github.com/bigwhite/experiments/tree/master/go-plugin/demo2/go.mod

module github.com/bigwhite/demo2

replace github.com/bigwhite/common => /Users/tonybai/go/src/github.com/bigwhite/experiments/go-plugin/common

require github.com/bigwhite/common v0.0.0-20180202201655-eb2c6b5be1b6 // 这个版本号是自行“伪造”的

go 1.16

如果我clone一份common包,将其放在common1目录下,并在plugin的go.mod中将replace github.com/bigwhite/common语句指向common1目录,我们重新编译主程序和plugin后,运行主程序,我们将得到如下结果:

$go run main.go
2021/06/15 14:09:07 common init
2021/06/15 14:09:07 pkg1 init
try to LoadPlugin...
LoadPlugin error: plugin.Open("../demo2-plugins/plugin1"): plugin was built with a different version of package github.com/bigwhite/common

我们看到因common的版本不同,plugin加载失败,这是plugin使用的一个约束:主程序与plugin的共同依赖包的版本必须一致

我们再来看一个主程序与plugin有共同以来包的例子。我们建立demo3,在这个版本中,主程序和plugin都依赖了logrus日志包,但主程序使用的是logrus 1.8.1版本,而plugin使用的是logrus 1.8.0版本,分别编译后,我们运行主程序:

// github.com/bigwhite/experiments/tree/master/go-plugin/demo3

2021/06/15 14:18:35 pkg1 init
try to LoadPlugin...
LoadPlugin error: plugin.Open("../demo3-plugins/plugin1"): plugin was built with a different version of package github.com/sirupsen/logrus

我们看到主程序运行报错,和前面的例子提示一样,都是因为使用了版本不一致的第三方包。要想解决这个问题,我们只需让两者使用的logrus包版本保持一致即可,比如将主程序的logrus从v1.8.1降级为v1.8.0:

$go get github.com/sirupsen/logrus@v1.8.0
go get: downgraded github.com/sirupsen/logrus v1.8.1 => v1.8.0
$go run main.go
2021/06/15 14:19:09 pkg1 init
try to LoadPlugin...
2021/06/15 14:19:09 plugin1 init
LoadPlugin ok

我们看到降级logrus版本后,主程序便可以正常加载plugin了。

还有一种情况,那就是主程序与plugin使用了同一个module的不同major版本的包,由于major版本不同,虽然是同一module,但实则是两个不同的包,这不会影响主程序对plugin的加载。但问题在于这个被共同依赖的module也会有自己的依赖包,当其不同major版本所依赖的某个包的版本不同时,同样会导致主程序加载plugin出现问题。 比如:主程序依赖go-redis/redis的v6.15.9+incompatible版本,而plugin依赖的是go-redis/redis/v8版本,当我们使用这样的主程序去加载plugin时,我们会遇到如下错误:

// github.com/bigwhite/experiments/tree/master/go-plugin/demo3

$go run main.go
2021/06/15 14:32:11 pkg1 init
try to LoadPlugin...
LoadPlugin error: plugin.Open("../demo3-plugins/plugin1"): plugin was built with a different version of package golang.org/x/sys/unix

我们看到redis版本并未出错,但问题出在redis与redis/v8所依赖的golang.org/x/sys的版本不同,这种间接依赖的module的版本的不一致同样会导致go plugin加载失败,这同样是go plugin的使用约束之一。

2) 如果采用mod=vendor构建,那么主程序和plugin必须基于同一个vendor目录构建

基于vendor构建是go 1.5版本引入的特性,go 1.11版本引入go module构建模式后,vendor构建的方式得以保留。那么问题来了,如果主程序或plugin采用vendor构建或同时采用vendor构建,那么主程序是否可以正常加载plugin呢?我们来用示例demo4验证一下。(demo4和demo3大同小异,这里就不列出具体代码了)。

首先我们分别为主程序(demo4)和plugin(demo4-plugins)生成vendor目录:

// github.com/bigwhite/experiments/tree/master/go-plugin/demo4
$go mod vendor

// github.com/bigwhite/experiments/tree/master/go-plugin/demo4-plugins
$go mod vendor

我们测试如下三种情况(go 1.16版本默认在有vendor的情况下,优先使用vendor构建。所以要基于mod构建需要显式的传入-mod=mod):

  • 主程序基于mod构建,插件基于vendor构建
// github.com/bigwhite/experiments/tree/master/go-plugin/demo4-plugins
$go build -mod=vendor -buildmode=plugin -o plugin1.so plugin1.go

// github.com/bigwhite/experiments/tree/master/go-plugin/demo4
$go build -mod=mod -o main.mod main.go

$main.mod
2021/06/15 15:41:21 pkg1 init
try to LoadPlugin...
LoadPlugin error: plugin.Open("../demo4-plugins/plugin1"): plugin was built with a different version of package golang.org/x/sys/unix
  • 主程序基于vendor构建,插件基于mod构建
// github.com/bigwhite/experiments/tree/master/go-plugin/demo4-plugins
$go build -mod=mod -buildmode=plugin -o plugin1.so plugin1.go

// github.com/bigwhite/experiments/tree/master/go-plugin/demo4
$go build -mod=vendor -o main.vendor main.go

$./main.vendor
2021/06/15 15:44:15 pkg1 init
try to LoadPlugin...
LoadPlugin error: plugin.Open("../demo4-plugins/plugin1"): plugin was built with a different version of package golang.org/x/sys/unix
  • 主程序和插件分别基于各自的vendor构建
// github.com/bigwhite/experiments/tree/master/go-plugin/demo4-plugins
$go build -mod=vendor -buildmode=plugin -o plugin1.so plugin1.go

// github.com/bigwhite/experiments/tree/master/go-plugin/demo4
$go build -mod=vendor -o main.vendor main.go

$./main.vendor
2021/06/15 15:45:11 pkg1 init
try to LoadPlugin...
LoadPlugin error: plugin.Open("../demo4-plugins/plugin1"): plugin was built with a different version of package golang.org/x/sys/unix

从上面的测试,我们看到无论是哪一方采用vendor构建,或者双方都基于各自vendor构建,主程序加载plugin都会失败。如何解决这一问题呢?让主程序和plugin基于同一个vendor构建!

我们将plugin1.go拷贝到demo4中,然后分别用vendor构建构建主程序和plugin1.go:

// github.com/bigwhite/experiments/tree/master/go-plugin/demo4
$go build -mod=vendor -o main.vendor main.go

// github.com/bigwhite/experiments/tree/master/go-plugin/demo4
$go build -mod=vendor -buildmode=plugin -o plugin1.so plugin1.go

将编译生成的plugin1.so拷贝到demo4-plugins中,然后运行main.vendor:

// github.com/bigwhite/experiments/tree/master/go-plugin/demo4
$cp plugin1.so ../demo4-plugins
$main.vendor
2021/06/15 15:48:56 pkg1 init
try to LoadPlugin...
2021/06/15 15:48:56 plugin1 init
LoadPlugin ok

我们看到基于同一vendor的主程序与plugin是可以相容的。下面的表格总结了主程序与plugin采用不同构建模式时是否相容:

插件构建方式\主程序构建方式 基于mod 基于自己的vendor
基于mod 加载成功 加载失败
基于基于自己的vendor 加载失败 加载失败

在vendor构建模式下,只有基于同一个vendor目录构建时,plugin才能被主程序加载成功

3) 主程序与plugin使用的编译器版本必须一致

如果我们使用不同版本的Go编译器分别编译主程序以及plugin,那么这两者是否能相容呢?我们还拿demo4来验证一下。我在主机上准备了go 1.16.5和go 1.16两个版本的Go编译器,go 1.16.5是go 1.16的patch维护版本,其区别与go 1.16与go 1.15相比则不是一个量级的,我们用go 1.16编译主程序,用go 1.16.5编译plugin:

// github.com/bigwhite/experiments/tree/master/go-plugin/demo4-plugins
$go version
go version go1.16.5 darwin/amd64
$go build -buildmode=plugin -o plugin1.so plugin1.go

// github.com/bigwhite/experiments/tree/master/go-plugin/demo4
$go version
go version go1.16 darwin/amd64

$go run main.go
2021/06/15 15:58:44 pkg1 init
try to LoadPlugin...
LoadPlugin error: plugin.Open("../demo4-plugins/plugin1"): plugin was built with a different version of package runtime/internal/sys

我们看到即便用patch版本编译,plugin与主程序也是不兼容的。我们将demo4升级到用go 1.16.5版本编译:

$go version
go version go1.16.5 darwin/amd64
$go run main.go
2021/06/15 15:59:05 pkg1 init
try to LoadPlugin...
2021/06/15 15:59:05 plugin1 init
LoadPlugin ok

我们看到只有主程序与plugin采用完全相同的版本(patch版本也要相同)编译时,它们才是相容的,主程序才能正常加载plugin。

那么操作系统版本是否影响主程序和plugin的相容性呢?这个没有官方说明,我亲测了一下。我在centos 7.6(amd64, go 1.16.5)上构建了demo4-plugin(基于mod=mod),然后将其拷贝到一台ubuntu 18.04(amd64, go1.16.5)的主机上,ubuntu主机上的demo4主程序可以与centos上编译出来的plugin相容。

4) 使用plugin的主程序仅能使用动态链接

Go以静态编译便于分发和部署著称,但使用plugin的主程序仅能使用动态链接。不信?那我们来挑战一下静态编译demo4中的主程序。

先来看看默认编译的情况:

// github.com/bigwhite/experiments/tree/master/go-plugin/demo4
$go build main.go
$ldd main
    linux-vdso.so.1 (0x00007ffc05b73000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f6a9fa3f000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f6a9f820000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6a9f42f000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f6a9fc43000)

我们看到默认编译的情况下,demo4主程序被编译为一个需要在运行时动态链接的可执行文件,它依赖诸多linux系统运行时库,比如:libc等。

这一切的原因都是我们在demo4中使用了一些通过cgo实现的标准库,比如plugin包:

// $GOROOT/src/plugin/plugin_dlopen.go

// +build linux,cgo darwin,cgo freebsd,cgo

package plugin

/*
#cgo linux LDFLAGS: -ldl
#include <dlfcn.h>
#include <limits.h>
#include <stdlib.h>
#include <stdint.h>

#include <stdio.h>

static uintptr_t pluginOpen(const char* path, char** err) {
    void* h = dlopen(path, RTLD_NOW|RTLD_GLOBAL);
    if (h == NULL) {
        *err = (char*)dlerror();
    }
    return (uintptr_t)h;
}
... ...
*/

我们看到plugin_dlopen.go的头部有build指示符,它仅在cgo开启的前提下才会被编译,如果我们去掉cgo,比如利用下面这行命令:

// github.com/bigwhite/experiments/tree/master/go-plugin/demo4
$ CGO_ENABLED=0 go build main.go
$ ldd main
    not a dynamic executable

我们确实编译出一个静态链接的可执行文件,但当我们执行该文件时,我们得到如下结果:

$ ./main
2021/06/15 17:01:51 pkg1 init
try to LoadPlugin...
LoadPlugin error: plugin: not implemented

我们看到由于cgo被关闭,plugin包的一些函数并没有被编译到最终可执行文件中,于是报了”not implemented”的错误!

在CGO开启的情况下,我们依旧可以让外部链接器使用静态链接,我们再来试一下:

// github.com/bigwhite/experiments/tree/master/go-plugin/demo4

$ go build -o main-static -ldflags '-linkmode "external" -extldflags "-static"' main.go
# command-line-arguments
/tmp/go-link-638385712/000001.o: In function `pluginOpen':
/usr/local/go/src/plugin/plugin_dlopen.go:19: warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
$ ldd main-static
    not a dynamic executable

我们的确得到了一个静态编译的二进制文件,但编译器也给出了warning。

执行这个文件:

$ ./main-static
2021/06/15 17:02:35 pkg1 init
try to LoadPlugin...
fatal error: runtime: no plugin module data

goroutine 1 [running]:
runtime.throw(0x5d380a, 0x1e)
    /usr/local/go/src/runtime/panic.go:1117 +0x72 fp=0xc000091b50 sp=0xc000091b20 pc=0x435712
plugin.lastmoduleinit(0xc000076210, 0x1001, 0x1001, 0xc000010040, 0x24db1f0)
    /usr/local/go/src/runtime/plugin.go:20 +0xb50 fp=0xc000091c48 sp=0xc000091b50 pc=0x466750
plugin.open(0x5d284c, 0x18, 0xc0000788f0, 0x0, 0x0)
    /usr/local/go/src/plugin/plugin_dlopen.go:77 +0x4ef fp=0xc000091ec0 sp=0xc000091c48 pc=0x4dad8f
plugin.Open(...)
    /usr/local/go/src/plugin/plugin.go:32
github.com/bigwhite/demo4/pkg/pkg1.LoadPlugin(0x5d284c, 0x1b, 0xc000091f48, 0x1)
    /root/test/go/plugin/demo4/pkg/pkg1/pkg1.go:13 +0x35 fp=0xc000091ef8 sp=0xc000091ec0 pc=0x4dbbb5
main.main()
    /root/test/go/plugin/demo4/main.go:12 +0xa5 fp=0xc000091f88 sp=0xc000091ef8 pc=0x4ee805
runtime.main()
    /usr/local/go/src/runtime/proc.go:225 +0x256 fp=0xc000091fe0 sp=0xc000091f88 pc=0x438196
runtime.goexit()
    /usr/local/go/src/runtime/asm_amd64.s:1371 +0x1 fp=0xc000091fe8 sp=0xc000091fe0 pc=0x46a841

warning最终演变为运行时的panic,看来使用plugin的主程序只能编译为动态链接的可执行程序了。目前go项目有多个issue与此有关:

  • https://github.com/golang/go/issues/33072
  • https://github.com/golang/go/issues/17150
  • https://github.com/golang/go/issues/18123

4. plugin版本管理

使用动态链接实现插件系统,一个更大的问题就是插件的版本管理问题。

linux上的动态链接库采用soname的方式进行版本管理。soname的关键功能是它提供了兼容性的标准,当要升级系统中的一个库时,并且新库的soname和老库的soname一样,用旧库链接生成的程序使用新库依然能正常运行。这个特性使得在Linux下,升级使得共享库的程序和定位错误变得十分容易。

什么是soname呢? 在/lib和/usr/lib等集中放置共享库的目录下,你总是会看到诸如下面的情况:

2019-12-10 12:28 libfoo.so -> libfoo.so.0.0.0*
2019-12-10 12:28 libfoo.so.0 -> libfoo.so.0.0.0*
2019-12-10 12:28 libfoo.so.0.0.0*

关于libfoo.so居然有三个文件入口,其中libfoo.so.0.0.0是真正的共享库文件,而其他两个文件入口则是指向libfoo.so.0.0.0的符号链接。为何会出现这个情况呢?这与共享库的命名惯例和版本管理不无关系。

共享库的惯例中每个共享库都有多个名字属性,包括real name、soname和linker name:

  • real name

real name指的是实际包含共享库代码的那个文件的名字(如上面例子中的libfoo.so.0.0.0),也是在共享库编译命令行中-o后面的那个参数;

  • soname

soname则是shared object name的缩写,也是这三个名字中最重要的一个,无论是在编译阶段还是在运行阶段,系统链接器都是通过共享库的soname(如上面例子中的libfoo.so.0)来唯一识别共享库的。即使real name相同但soname不同,也会被链接器认为是两个不同的库。共享库的soname可在编译期间通过传给链接器的参数来指定,如我们可以通过”gcc -shared -Wl,-soname -Wl,libfoo.so.0 -o libfoo.so.0.0.0 libfoo.o”来指定libfoo.so.0.0.0的soname为libfoo.so.0。ldconfig -n directory_with_shared_libraries命令会根据共享库的soname自动生成一个名为soname的符号链接指向real name文件,当然你也可以通过ln命令自己来创建这个符号链接。另外在linux下我们可通过readelf -d查看共享库的soname,ldd输出的ELF文件依赖的共享库列表中显示的也是共享库的soname及所在路径。

  • linker name

linker name是编译阶段提供给编译器的名字(如上面例子中的libfoo.so)。如果你构建的共享库的real name是类似于上例中libfoo.so.0.0.0那样的带有版本号的样子,那么你在编译器命令中直接使用-L path -lfoo是无法让链接器找到对应的共享库文件的,除非你为libfoo.so.0.0.0提供了一个linker name(如libfoo.so,一个指向libfoo.so.0.0.0的符号链接)。linker name一般在共享库安装时手工创建。

那么go plugin是否可以用soname的方式来做版本管理呢?基于demo1我们创建demo5,并来做一下试验。

在demo5-plugins中,我们为构建出的.so增加版本信息:

// github.com/bigwhite/experiments/tree/master/go-plugin/demo5-plugins

$go build -buildmode=plugin -o plugin1.so.1.1 plugin1.go
$ln -s plugin1.so.1.1 plugin1.so.1
$ls -l
lrwxr-xr-x  1 tonybai  staff       14  7 16 05:42 plugin1.so.1@ -> plugin1.so.1.1
-rw-r--r--  1 tonybai  staff  2888408  7 16 05:42 plugin1.so.1.1

我们通过ln命令为构建出的plugin1.so.1.1创建了一个符号链接plugin1.so.1,plugin1.so.1作为我们插件的soname传给demo5:

// github.com/bigwhite/experiments/tree/master/go-plugin/demo5/main.go

func main() {
    fmt.Println("try to LoadAndInvokeSomethingFromPlugin...")
    err := pkg1.LoadAndInvokeSomethingFromPlugin("../demo5-plugins/plugin1.so.1")
    if err != nil {
        fmt.Println("LoadAndInvokeSomethingFromPlugin error:", err)
        return
    }
    fmt.Println("LoadAndInvokeSomethingFromPlugin ok")
}

运行demo5:

// github.com/bigwhite/experiments/tree/master/go-plugin/demo5

$go run main.go
2021/07/16 05:58:33 pkg1 init
try to LoadAndInvokeSomethingFromPlugin...
2021/07/16 05:58:33 plugin1 init
plugin1: public integer variable V=15
plugin1: invoke foo.M1
LoadAndInvokeSomethingFromPlugin ok

我们看到以soname传入的插件被顺利加载并提取符号。

后续如果plugin发生变更,比如打了patch,我们只需要升级plugin为plugin1.so.1.2,然后soname依旧保持不变,主程序也无需变动。

注意:如果插件名相同,内容相同,主程序多次加载不会出现问题;但插件名相同,但内容不同,主程序运行时多次load会导致runtime panic,并且是无法恢复的panic。所以务必做好插件的版本管理

5. 小结

go plugin是go语言原生提供的一种go插件方案(非go插件方案,可以使用c shared library等)。但经过上面的实验和学习,我们我们看到了plugin使用的诸多约束,这的确给go plugin的推广使用造成的很大障碍,导致目前go plugin应用不甚广泛。

根据上面看到的种种约束,如果要应用go plugin,必须要做到:

  • 构建环境一致
  • 对第三方包的版本一致。

因此,业内在使用go plugin时多利用builder container(用来构建程序的容器)来保证主程序和plugin使用相同的构建环境。

在go plugin为数不多的用户中,有三个比较知名的开源项目值得后续认真研究:

  • gosh: https://github.com/vladimirvivien/gosh
  • tyk api gateway: https://github.com/TykTechnologies/tyk
  • tidb : https://github.com/pingcap/tidb

尤其是tidb,还给出了其插件系统使用go plugin的完整设计方案:https://github.com/pingcap/tidb/blob/master/docs/design/2018-12-10-plugin-framework.md,值得大家细致品读。

本文涉及的所有源码可以在这里下载:https://github.com/bigwhite/experiments/tree/master/go-plugin 。

6. 参考资料

  • https://golang.org/pkg/plugin/
  • https://golang.org/cmd/go/#hdr-Build_modes
  • https://golang.org/doc/go1.8
  • https://www.reddit.com/r/golang/comments/b6h8qq/is_anyone_actually_using_go_plugins/
  • https://medium.com/@alperkose/things-to-avoid-while-using-golang-plugins-f34c0a636e8
  • https://medium.com/learning-the-go-programming-language/writing-modular-go-programs-with-plugins-ec46381ee1a9

“Gopher部落”知识星球正式转正(从试运营星球变成了正式星球)!“gopher部落”旨在打造一个精品Go学习和进阶社群!高品质首发Go技术文章,“三天”首发阅读权,每年两期Go语言发展现状分析,每天提前1小时阅读到新鲜的Gopher日报,网课、技术专栏、图书内容前瞻,六小时内必答保证等满足你关于Go语言生态的所有需求!部落目前虽小,但持续力很强。在2021年上半年,部落将策划两个专题系列分享,并且是部落独享哦:

  • Go技术书籍的书摘和读书体会系列
  • Go与eBPF系列

欢迎大家加入!

Go技术专栏“改善Go语⾔编程质量的50个有效实践”正在慕课网火热热销中!本专栏主要满足广大gopher关于Go语言进阶的需求,围绕如何写出地道且高质量Go代码给出50条有效实践建议,上线后收到一致好评!欢迎大家订
阅!

img{512x368}

我的网课“Kubernetes实战:高可用集群搭建、配置、运维与应用”在慕课网热卖中,欢迎小伙伴们订阅学习!

img{512x368}

我爱发短信:企业级短信平台定制开发专家 https://51smspush.com/。smspush : 可部署在企业内部的定制化短信平台,三网覆盖,不惧大并发接入,可定制扩展; 短信内容你来定,不再受约束, 接口丰富,支持长短信,签名可选。2020年4月8日,中国三大电信运营商联合发布《5G消息白皮书》,51短信平台也会全新升级到“51商用消息平台”,全面支持5G RCS消息。

著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格5$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式:

  • 微博:https://weibo.com/bigwhite20xx
  • 微信公众号:iamtonybai
  • 博客:tonybai.com
  • github: https://github.com/bigwhite
  • “Gopher部落”知识星球:https://public.zsxq.com/groups/51284458844544

微信赞赏:
img{512x368}

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

通过实例理解Go逃逸分析

本文永久链接 – https://tonybai.com/2021/05/24/understand-go-escape-analysis-by-example

翻看了一下自己的Go文章归档,发现自己从未专门写过有关Go逃逸分析(escape analysis)的文章。关于Go变量的逃逸分析,大多数Gopher其实并不用关心,甚至可以无视。但是如果你将Go应用于性能敏感的领域,要完全压榨出Go应用的性能,那么理解Go逃逸分析就大有裨益了。在本文,我们就一起来理解一下Go的逃逸分析。

1. 逃逸分析(escape analysis)要解决的问题

C/C++语言出身的程序员对堆内存(heap)和栈内存(stack)都有着“泾渭分明”的理解。在操作系统演化出现进程虚拟内存地址(virtual memory address)的概念后,如下图所示,应用程序的虚拟内存地址空间就被划分为堆内存区(如图中的heap)和栈内存区(如图中的stack):


图:一个进程的虚拟内存地址空间(图来自https://dave.cheney.net/2014/06/07/five-things-that-make-go-fast)

在x86平台linux操作系统下,如上图,一般将栈内存区放在高地址,栈向下延伸;而堆内存去放在低地址,堆向上延伸,这样做的好处就是便于堆和栈可动态共享那段内存区域。

这是否意味着所有分配在堆内存区域的内存对象地址一定比分配在栈内存区域的内存对象地址要小呢?在C/C++中是这样的,但是在Go语言中,这是不一定的,因为go堆内存所使用的内存页(page)与goroutine的栈所使用的内存页是交织在一起的

无论是栈内存还是堆内存,对于应用而言都是合法可用的内存地址空间。之所以将其区分开,是因为应用程序的内存分配和管理的需要。

栈内存上的对象的存储空间是自动分配和销毁的,无需开发人员或编程语言运行时过多参与,比如下面的这段C代码(用C代码更能体现栈内存与堆内存的差别):

// github.com/bigwhite/experiments/blob/master/go-escape-analysis/c/cstack.c

#include <stdio.h>

void bar() {
    int e = 31;
    int f = 32;
    printf("e = %d\n", e);
    printf("f = %d\n", f);
}

void foo() {
    int c = 21;
    int d = 22;
    printf("c = %d\n", c);
    printf("d = %d\n", d);
}

int main() {
    int a = 11;
    int b = 12;
    printf("a = %d\n", a);
    printf("b = %d\n", b);
    foo();
    bar();
}

上面这段c程序算上main函数共有三个函数,每个函数中都有两个整型变量,C编译器自动为这些变量在栈内存上分配空间,我们无需考虑它什么时候被创建以及何时被销毁,我们只需在特定的作用域(其所在函数内部)使用它即可,而无需担心其内存地址不合法,因此这些被分配在栈内存上的变量也被称为“自动变量”。但是如果将其地址返回到函数的外部,那么函数外部的代码通过解引用而访问这些变量时便会出错,如下面示例:

// github.com/bigwhite/experiments/blob/master/go-escape-analysis/c/cstack_coredump.c

#include <stdio.h>

int *foo() {
    int c = 11;
    return &c;
}

int main() {
    int *p = foo();
    printf("the return value of foo = %d\n", *p);
}

如代码所示,在上面这个例子中,我们将foo函数内的自动变量c的地址通过函数返回值返回给foo函数的调用者(main)了,这样当我们在main函数中引用该地址输出该变量值的时候,我们就会收到异常,比如在ubuntu上运行上述程序,我们会得到如下结果(在macos上运行,gcc会给出相同的警告,但程序运行不会dump core):

# gcc cstack_dumpcore.c
cstack_dumpcore.c: In function ‘foo’:
cstack_dumpcore.c:5:12: warning: function returns address of local variable [-Wreturn-local-addr]
     return &c;
            ^~
# ./a.out
Segmentation fault (core dumped)

这样一来我们就需要一种内存对象,可以在全局(跨函数间)合法使用,这就是堆内存对象。但是和位于栈上的内存对象由程序自行创建销毁不同,堆内存对象需要通过专用API手工分配和释放,在C中对应的分配和释放方法就是malloc和free:

// github.com/bigwhite/experiments/blob/master/go-escape-analysis/c/cheap.c

#include <stdio.h>
#include <stdlib.h>

int *foo() {
    int *c = malloc(sizeof(int));
    *c = 12;
    return c;
}

int main() {
    int *p = foo();
    printf("the return value of foo = %d\n", *p);
    free(p);
}

在这个示例中我们使用malloc在foo函数中分配了一个堆内存对象,并将该对象返回给main函数,main函数使用完该对象后调用了free函数手工释放了该堆内存块。

显然和自动变量相比,堆内存对象的生命周期管理将会给开发人员带来很大的心智负担。为了降低这方面的心智负担,带有GC(垃圾回收)的编程语言出现了,比如Java、Go等。这些带有GC的编程语言会对位于堆上的对象进行自动管理。当某个对象不可达时(即没有其对象引用它时),它将会被回收并被重用。

但GC的出现虽然降低了开发人员在内存管理方面的心智负担,但GC不是免费的,它给程序带来的性能损耗是不可忽视的,尤其是当堆内存上有大量待扫描的堆内存对象时,将会给GC带来过大的压力,从而使得GC占用更多本应用于处理业务逻辑的计算和存储资源。于是人们开始想方法尽量减少在堆上的内存分配,可以在栈上分配的变量尽量留在栈上。

逃逸分析(escape analysis)就是在程序编译阶段根据程序代码中的数据流,对代码中哪些变量需要在栈上分配,哪些变量需要在堆上分配进行静态分析的方法。一个理想的逃逸分析算法自然是能将那些人们认为需要分配在栈上的变量尽可能保留在栈上,尽可能少的“逃逸”到堆上的算法。但这太过理想,各种语言都有自己的特殊情况,各种语言的逃逸算法的精确度实际都会受到这方面的影响。

2. Go语言的逃逸分析

Go从诞生那天起,逃逸分析就始终伴随其左右。正如上面说到的逃逸分析的目标,Go编译器使用逃逸分析来决定哪些变量应该在goroutine的栈上分配,哪些变量应该在堆上分配。

截至目前,Go一共有两个版本的逃逸分析实现,分水岭在Go 1.13版本。Go 1.13版本之前是Go逃逸分析的第一版实现,位于Go源码的src/cmd/compile/internal/gc/esc.go中(以go 1.12.7版本为例),代码规模2400多行;Go 1.13版本中加入了由Matthew Dempsky重写的第二版逃逸分析,并默认开启,可以通过-gcflags=”-m -newescape=false”恢复到使用第一版逃逸分析。之所以重写,主要是考虑第一版代码的可读性和可维护性问题,新版代码主要位于Go项目源码的src/cmd/compile/internal/gc/escape.go中,它将逃逸分析代码从上一版的2400多行缩减为1600多行,并作了更为完整文档和注释。但注意的是新版代码在算法精确性上并没有质的变化

但即便如此,经过了这么多年的“修修补补”,Dmitry Vyukov 2015年提出的那些“Go Escape Analysis Flaws”多数已经fix了。Go项目中内置了对逃逸分析的详尽的测试代码(位于Go项目下的test/escape*.go文件中)。

在新版逃逸分析实现的注释中($GOROOT/src/cmd/compile/internal/gc/escape.go),我们可以大致了解逃逸分析的实现原理。注释中的原理说明中提到了算法基于的两个不变性:

  1. 指向栈对象的指针不能存储在堆中(pointers to stack objects cannot be stored in the heap);
  2. 指向栈对象的指针不能超过该栈对象的存活期(即指针不能在栈对象被销毁后依旧存活)(pointers to a stack object cannot outlive that object)。

源码注释中也给出Go逃逸分析的大致原理和过程。Go逃逸分析的输入是Go编译器解析了Go源文件后所获得的整个程序的抽象语法树(Abstract syntax tree,AST):

源码解析后得到的代码AST的Node切片为xtop:

// $GOROOT/src/cmd/compile/internal/gc/go.go
var xtop []*Node

在Main函数中,xtop被传入逃逸分析的入口函数escapes:

// $GOROOT/src/cmd/compile/internal/gc/main.go

// Main parses flags and Go source files specified in the command-line
// arguments, type-checks the parsed Go package, compiles functions to machine
// code, and finally writes the compiled package definition to disk.
func Main(archInit func(*Arch)) {
    ... ...
    // Phase 6: Escape analysis.
    // Required for moving heap allocations onto stack,
    // which in turn is required by the closure implementation,
    // which stores the addresses of stack variables into the closure.
    // If the closure does not escape, it needs to be on the stack
    // or else the stack copier will not update it.
    // Large values are also moved off stack in escape analysis;
    // because large values may contain pointers, it must happen early.
    timings.Start("fe", "escapes")
    escapes(xtop)
    ... ...
}

下面是escapes函数的实现:

// $GOROOT/src/cmd/compile/internal/gc/esc.go
func escapes(all []*Node) {
    visitBottomUp(all, escapeFuncs)
}

// $GOROOT/src/cmd/compile/internal/gc/scc.go
// 强连接node - 一个数据结构
func visitBottomUp(list []*Node, analyze func(list []*Node, recursive bool)) {
    var v bottomUpVisitor
    v.analyze = analyze
    v.nodeID = make(map[*Node]uint32)
    for _, n := range list {
        if n.Op == ODCLFUNC && !n.Func.IsHiddenClosure() {
            v.visit(n)
        }
    }
}

// $GOROOT/src/cmd/compile/internal/gc/escape.go

// escapeFuncs performs escape analysis on a minimal batch of
// functions.
func escapeFuncs(fns []*Node, recursive bool) {
    for _, fn := range fns {
        if fn.Op != ODCLFUNC {
            Fatalf("unexpected node: %v", fn)
        }
    }

    var e Escape
    e.heapLoc.escapes = true

    // Construct data-flow graph from syntax trees.
    for _, fn := range fns {
        e.initFunc(fn)
    }
    for _, fn := range fns {
        e.walkFunc(fn)
    }
    e.curfn = nil

    e.walkAll()
    e.finish(fns)
}

根据注释,escapes的大致原理是(直译):

  • 首先,构建一个有向加权图,其中顶点(称为”location”,由gc.EscLocation表示)代表由语句和表达式分配的变量,而边(gc.EscEdge)代表变量之间的赋值(权重代表寻址/取地址次数)。
  • 接下来,遍历(visitBottomUp)该有向加权图,在图中寻找可能违反上述两个不变量条件的赋值路径。 违反上述不变量的赋值路径。如果一个变量v的地址是储存在堆或其他可能会超过它的存活期的地方,那么v就会被标记为需要在堆上分配。
  • 为了支持函数间的分析,算法还记录了从每个函数的参数到堆的数据流以及到其结果的数据流。算法将这些信息称为“参数标签(parameter tag)”。这些标签信息在静态调用时使用,以改善对函数参数的逃逸分析。

当然即便看到这,你可能依旧一头雾水,没关系,这里不是讲解逃逸分析原理,如果想了解原理,那就请认真阅读那2400多行代码。

注:有一点需要明确,那就是静态逃逸分析也无法确定的对象会被放置在堆上,后续精确的GC会处理这些对象,这样最大程度保证了代码的安全性。

3. Go逃逸分析的示例

Go工具链提供了查看逃逸分析过程的方法,我们可以通过在-gcflags中使用-m来让Go编译器输出逃逸分析的过程,下面是一些典型的示例。

1) 简单原生类型变量的逃逸分析

我们来看一个原生整型变量的逃逸分析过程,下面是示例的代码:

// github.com/bigwhite/experiments/blob/master/go-escape-analysis/go/int.go
     1  package main
     2
     3  import "testing"
     4
     5  func foo() {
     6      a := 11
     7      p := new(int)
     8      *p = 12
     9      println("addr of a is", &a)
    10      println("addr that p point to is", p)
    11  }
    12
    13  func bar() (*int, *int) {
    14      m := 21
    15      n := 22
    16      println("addr of m is", &m)
    17      println("addr of n is", &n)
    18      return &m, &n
    19  }
    20
    21  func main() {
    22      println(int(testing.AllocsPerRun(1, foo)))
    23      println(int(testing.AllocsPerRun(1, func() {
    24          bar()
    25      })))
    26  }

我们通过-gcflags “-m -l”来执行逃逸分析,之所以传入-l是为了关闭inline,屏蔽掉inline对这个过程以及最终代码生成的影响:

// go 1.16版本 on MacOS
$go build -gcflags "-m -l" int.go
# command-line-arguments
./int.go:7:10: new(int) does not escape
./int.go:14:2: moved to heap: m
./int.go:15:2: moved to heap: n
./int.go:23:38: func literal does not escape

逃逸分析的结果与我们手工分析的一致:函数bar中的m、n逃逸到heap(对应上面输出的有moved to heap: xx字样的行),这两个变量将在heap上被分配存储空间。而函数foo中的a以及指针p指向的内存块都在栈上分配(即便我们是调用的new创建的int对象,Go中new出来的对象可不一定分配在堆上,逃逸分析的输出日志中还专门提及new(int)没有逃逸)。我们执行一下该示例(执行时同样传入-l关闭inline):

$go run -gcflags "-l" int.go
addr of a is 0xc000074860
addr that p point to is 0xc000074868
addr of a is 0xc000074860
addr that p point to is 0xc000074868
0
addr of m is 0xc0000160e0
addr of n is 0xc0000160e8
addr of m is 0xc0000160f0
addr of n is 0xc0000160f8
2

首先,我们看到未逃逸的a和p指向的内存块的地址区域在0xc000074860~0xc000074868;而逃逸的m和n被分配到了堆内存空间,从输出的结果来看在0xc0000160e0~0xc0000160e8。我们可以明显看到这是两块不同的内存地址空间;另外通过testing包的AllocsPerRun的输出,我们同样印证了函数bar中执行了两次堆内存分配动作。

我们再来看看这个代码对应的汇编代码:

$go tool compile -S int.go |grep new
    0x002c 00044 (int.go:14)    CALL    runtime.newobject(SB)
    0x004d 00077 (int.go:15)    CALL    runtime.newobject(SB)
    rel 45+4 t=8 runtime.newobject+0
    rel 78+4 t=8 runtime.newobject+0

我们看到在对应源码的14和15行,汇编调用了runtime.newobject在堆上执行了内存分配动作,这恰是逃逸的m和n声明的位置。从下面newobject代码的实现我们也能看到,它实际上在gc管理的内存上执行了malloc动作:

// $GOROOT/src/runtime/malloc.go

// implementation of new builtin
// compiler (both frontend and SSA backend) knows the signature
// of this function
func newobject(typ *_type) unsafe.Pointer {
    return mallocgc(typ.size, typ, true)
}

2) 切片变量自身和切片元素的逃逸分析

了解过切片实现原理的gopher都知道,切片变量实质上是一个三元组:

//$GOROOT/src/runtime/slice.go

type slice struct {
    array unsafe.Pointer
    len   int
    cap   int
}

其中这个三元组的第一个字段array指向的是切片底层真正存储元素的指针。这样当为一个切片变量分配内存时,便既要考虑切片本身(即上面的slice结构体)在哪里分配,也要考虑切片元素的存储在哪里分配。我们看下面示例:

// github.com/bigwhite/experiments/blob/master/go-escape-analysis/go/slice.go

     1  package main
     2
     3  import (
     4      "reflect"
     5      "unsafe"
     6  )
     7
     8  func noEscapeSliceWithDataInHeap() {
     9      var sl []int
    10      println("addr of local(noescape, data in heap) slice = ", &sl)
    11      printSliceHeader(&sl)
    12      sl = append(sl, 1)
    13      println("append 1")
    14      printSliceHeader(&sl)
    15      println("append 2")
    16      sl = append(sl, 2)
    17      printSliceHeader(&sl)
    18      println("append 3")
    19      sl = append(sl, 3)
    20      printSliceHeader(&sl)
    21      println("append 4")
    22      sl = append(sl, 4)
    23      printSliceHeader(&sl)
    24  }
    25
    26  func noEscapeSliceWithDataInStack() {
    27      var sl = make([]int, 0, 8)     28      println("addr of local(noescape, data in stack) slice = ", &sl)
    29      printSliceHeader(&sl)
    30      sl = append(sl, 1)
    31      println("append 1")
    32      printSliceHeader(&sl)
    33      sl = append(sl, 2)
    34      println("append 2")
    35      printSliceHeader(&sl)
    36  }
    37
    38  func escapeSlice() *[]int {
    39      var sl = make([]int, 0, 8)     40      println("addr of local(escape) slice = ", &sl)
    41      printSliceHeader(&sl)
    42      sl = append(sl, 1)
    43      println("append 1")
    44      printSliceHeader(&sl)
    45      sl = append(sl, 2)
    46      println("append 2")
    47      printSliceHeader(&sl)
    48      return &sl
    49  }
    50
    51  func printSliceHeader(p *[]int) {
    52      ph := (*reflect.SliceHeader)(unsafe.Pointer(p))
    53      println("slice data =", unsafe.Pointer(ph.Data))
    54  }
    55
    56  func main() {
    57      noEscapeSliceWithDataInHeap()
    58      noEscapeSliceWithDataInStack()
    59      escapeSlice()
    60  }

对上述示例运行逃逸分析:

$go build -gcflags "-m -l" slice.go
# command-line-arguments
./slice.go:51:23: p does not escape
./slice.go:27:15: make([]int, 0, 8) does not escape
./slice.go:39:6: moved to heap: sl
./slice.go:39:15: make([]int, 0, 8) escapes to heap

我们从输出的信息中看到:

  • 位于39行的escapeSlice函数中的sl逃逸到堆上了;
  • 位于39行的escapeSlice函数中的切片sl的元素也逃逸到堆上了;
  • 位于27行的切片sl的元素没有逃逸。

由于很难看到三个函数中各个切片的元素是否逃逸,我们通过运行该示例来看一下:

$go run -gcflags " -l" slice.go
addr of local(noescape, data in heap) slice =  0xc00006af48
slice data = 0x0
append 1
slice data = 0xc0000160c0
append 2
slice data = 0xc0000160d0
append 3
slice data = 0xc0000140c0
append 4
slice data = 0xc0000140c0

addr of local(noescape, data in stack) slice =  0xc00006af48
slice data = 0xc00006af08
append 1
slice data = 0xc00006af08
append 2
slice data = 0xc00006af08

addr of local(escape) slice =  0xc00000c030
slice data = 0xc00001a100
append 1
slice data = 0xc00001a100
append 2
slice data = 0xc00001a100

注:我们利用reflect包的SliceHeader输出切片三元组中的代表底层数组地址的字段,这里是slice data。

我们看到:

  • 第一个函数noEscapeWithDataInHeap声明了一个空slice,并在后面使用append向切片附加元素。从输出结果来看,slice自身是分配在栈上的,但是运行时在动态扩展切片时,选择了将其元素存储在heap上;
  • 第二个函数noEscapeWithDataInStack直接初始化了一个包含8个元素存储空间的切片,切片自身没有逃逸,并且在附加(append)的元素个数小于等于8个的时候,元素直接使用了为其分配的栈空间;但如果附加的元素超过8个,那么运行时会在堆上分配一个更大的空间并将原栈上的8个元素复制过去,后续该切片的元素就都存储在了堆上。这也是为什么强烈建议在创建 slice 时带上预估的cap参数的原因,不仅减少了堆内存的频繁分配,在切片变量未逃逸的情况下,在cap容量之下,所有元素都分配在栈上,这将提升运行性能。
  • 第三个函数escapeSlice则是切片变量自身以及其元素的存储都在堆上。

3) fmt.Printf系列函数让变量逃逸到堆(heap)上了?

很多人在go项目的issue中反馈fmt.Printf系列函数让变量逃逸到堆上了,情况真的是这样么?我们通过下面示例来看一下:

// github.com/bigwhite/experiments/blob/master/go-escape-analysis/go/printf1.go
     1  package main
     2
     3  import "fmt"
     4
     5  func foo() {
     6      var a int = 66666666
     7      var b int = 77
     8      fmt.Printf("a = %d\n", a)
     9      println("addr of a in foo =", &a)
    10      println("addr of b in foo =", &b)
    11  }
    12
    13  func main() {
    14      foo()
    15  }

注:println和print两个预定义函数并没有像fmt.Printf系列函数的“副作用”,不会影响变量的逃逸性。所以这里使用println来输出变量的实际分配内存地址。

对上面的代码运行逃逸分析:

$go build -gcflags "-m -l" printf1.go
# command-line-arguments
./printf1.go:8:12: ... argument does not escape
./printf1.go:8:13: a escapes to heap

我们看到逃逸分析输出第8行的变量“a escapes to heap”,不过这个“逃逸”有些奇怪,因为按照之前的经验,如果某个变量真实逃逸了,那么逃逸分析会在其声明的那行输出:“moved to heap: xx”字样。而上面这个输出既不是在变量声明的那一行,也没有输出“moved to heap: a”字样,变量a真的逃逸了么?我们运行一下上面示例,看看变量a的地址究竟是在堆上还是栈上:

$go run -gcflags "-l" printf1.go
a = 66666666
addr of a in foo = 0xc000092f50
addr of b in foo = 0xc000092f48

我们看到变量a的地址与未逃逸的变量b的地址都在同一个栈空间,变量a并未逃逸!如果你反编译为汇编,你肯定也看不到runtime.newobject的调用。

那么“./printf1.go:8:13: a escapes to heap”这句的含义究竟是什么呢?显然逃逸分析在这一行是对进入fmt.Printf的数据流的分析,我们修改一下go标准库源码,然后build -a重新编译一下printf1.go,看看在fmt.Printf内部变量的分布情况:

// $GOROOT/src/fmt/print.go

func Printf(format string, a ...interface{}) (n int, err error) {
    // 添加下面四行代码
    for i := 0; i < len(a); i++ {
        println(a[i])
        println(&a[i])
    }
    return Fprintf(os.Stdout, format, a...)
}

重新编译printf1.go并运行编译后的可执行文件(为了避免):

$go build -a -gcflags "-l" printf1.go
$./printf1
(0x10af200,0xc0000160c8)
0xc00006cf58
a = 66666666
addr of a in foo = 0xc00006cf50
addr of b in foo = 0xc00006cf48

我们看到fmt.Printf的实参a在传入后被装箱到一个interface{}类型的形参变量中,而这个形参变量自身则是被分配在栈上的(0xc00006cf58),而通过println输出的该interface{}类型形参变量的类型部分和值部分分别指向0x10af200和0xc0000160c8。显然值部分是在堆内存上分配的。那么“./printf1.go:8:13: a escapes to heap”是否指的是装箱后的值部分在堆上分配呢?这里也不确定。

我们再来看一个例子来对比一下:

// github.com/bigwhite/experiments/blob/master/go-escape-analysis/go/printf2.go
     1  package main
     2
     3  import "fmt"
     4
     5  func foo() {
     6      var a int = 66666666
     7      var b int = 77
     8      fmt.Printf("addr of a in bar = %p\n", &a)
     9      println("addr of a in bar =", &a)
    10      println("addr of b in bar =", &b)
    11  }
    12
    13  func main() {
    14      foo()
    15  }

在printf2.go这个例子中,与printf1.go不同的是我们在foo函数中使用fmt.Printf输出的是变量a的地址:&a。我们运行一下新版逃逸分析:

// go 1.16

$go build -gcflags "-m -l" printf2.go
# command-line-arguments
./printf2.go:6:6: moved to heap: a
./printf2.go:8:12: ... argument does not escape

我们看到位于第6行声明的变量a居然真的逃逸到了堆上。我们运行一下printf2.go:

$go build -a -gcflags "-l" printf2.go
$./printf2
(0x10ab4a0,0xc0000160c8)
0xc00006cf58
addr of a in bar = 0xc0000160c8
addr of a in bar = 0xc0000160c8
addr of b in bar = 0xc00006cf48

我们看到变量a的地址果然与位于栈上的变量b相差很大,应该就是在堆上,那么这样看那些在go项目中提issue的gopher所言不虚。变量a的地址以实参的形式传入fmt.Printf后被装箱到一个interface{}形参变量中,而从结果来看,fmt.Printf真的要求装箱的形参变量的值部分要在堆上分配,但根据逃逸分析不变性,堆上的对象不能存储一个栈上的地址,而这次存储的是a的地址,于是将a判定为逃逸,于是a自身也就被分配到了堆上(0xc0000160c8)。

我们用go 1.12.7运行一下老版的逃逸分析:

// go 1.12.7
$go build -gcflags "-m -l" printf2.go
# command-line-arguments
./printf2.go:8:40: &a escapes to heap
./printf2.go:8:40: &a escapes to heap
./printf2.go:6:6: moved to heap: a
./printf2.go:8:12: foo ... argument does not escape
./printf2.go:9:32: foo &a does not escape
./printf2.go:10:32: foo &b does not escape

老版的逃逸分析给出了更详细的输出,比如:“&a escapes to heap”,其所指想必就是&a被装箱到堆内存上;而println输出&a则无需&a被装箱。但此后对变量a的最终判定为逃逸。

Go核心团队成员Keith Randall对逃逸分析输出的日志给过一个解释,大致意思是:当逃逸分析输出“b escapes to heap”时,意思是指存储在b中的值逃逸到堆上了(当b为指针变量时才有意义),即任何被b引用的对象必须分配在堆上,而b自身则不需要;如果b自身也逃逸到堆上,那么逃逸分析会输出“&b escapes to heap”。

这个问题目前已经没有fix,其核心问题在8618这个issue中。

5. 手动强制避免逃逸

对于printf2.go中的例子,我们确定一定以及肯定:a不需要逃逸。但若使用fmt.Printf,我们无法阻拦a的逃逸。那是否有一种方法可以干扰逃逸分析,使逃逸分析认为需要在堆上分配的内存对象而我们确定认为不需要逃逸的对象避免逃逸呢?在Go运行时代码中,我们发现了一个函数:

// $GOROOT/src/runtime/stubs.go
func noescape(p unsafe.Pointer) unsafe.Pointer {
    x := uintptr(p)
    return unsafe.Pointer(x ^ 0) // 任何数值与0的异或都是原数
}

并且在Go标准库和运行时实现中,该函数得到大量使用。该函数的实现逻辑使得我们传入的指针值与其返回的指针值是一样的。该函数只是通过uintptr做了一次转换,而这次转换将指针转换成了数值,这“切断”了逃逸分析的数据流跟踪,导致传入的指针避免逃逸。

我们看一下下面例子:

// github.com/bigwhite/experiments/blob/master/go-escape-analysis/go/printf3.go
package main

import (
    "fmt"
    "unsafe"
)

func noescape(p unsafe.Pointer) unsafe.Pointer {
    x := uintptr(p)
    return unsafe.Pointer(x ^ 0)
}

func foo() {
    var a int = 66666666
    var b int = 77
    fmt.Printf("addr of a in bar = %p\n", (*int)(noescape(unsafe.Pointer(&a))))
    println("addr of a in bar =", &a)
    println("addr of b in bar =", &b)
}

func main() {
    foo()
}

对该代码实施统一分析:

$go build -gcflags "-m -l" printf3.go

# command-line-arguments
./printf3.go:8:15: p does not escape
./printf3.go:16:12: ... argument does not escape

我们看到a这次没有逃逸。运行一下编译后的可执行文件:

$./printf3
(0x10ab4c0,0xc00009af50)
0xc00009af58
addr of a in bar = 0xc00009af50
addr of a in bar = 0xc00009af50
addr of b in bar = 0xc00009af48

我们看到a没有像printf2.go那样被放在堆上,这次和b一样都是在栈上分配的。并且在fmt.Printf执行的过程中a的栈地址始终是有效的。

曾有一篇通过逃逸分析优化性能的论文《Escape from Escape Analysis of Golang》使用的就是上述noescape函数的思路,有兴趣的童鞋可以自行下载阅读。

6. 小结

通过这篇文章,我们了解到了逃逸分析要解决的问题、Go逃逸分析的现状与简单原理、一些Go逃逸分析的实例以及对逃逸分析输出日志的说明。最后,我们给出一个强制避开逃逸分析的方案,但要谨慎使用。

日常go开发过程,绝大多数情况无需考虑逃逸分析,除非性能敏感的领域。在这些领域,对系统执行热点路径做一次逃逸分析以及相应的优化,可能回带来程序性能的一定提升。

本文涉及的源码可以在这里下载:https://github.com/bigwhite/experiments/blob/master/go-escape-analysis


“Gopher部落”知识星球正式转正(从试运营星球变成了正式星球)!“gopher部落”旨在打造一个精品Go学习和进阶社群!高品质首发Go技术文章,“三天”首发阅读权,每年两期Go语言发展现状分析,每天提前1小时阅读到新鲜的Gopher日报,网课、技术专栏、图书内容前瞻,六小时内必答保证等满足你关于Go语言生态的所有需求!部落目前虽小,但持续力很强。在2021年上半年,部落将策划两个专题系列分享,并且是部落独享哦:

  • Go技术书籍的书摘和读书体会系列
  • Go与eBPF系列

欢迎大家加入!

Go技术专栏“改善Go语⾔编程质量的50个有效实践”正在慕课网火热热销中!本专栏主要满足广大gopher关于Go语言进阶的需求,围绕如何写出地道且高质量Go代码给出50条有效实践建议,上线后收到一致好评!欢迎大家订阅!

img{512x368}

我的网课“Kubernetes实战:高可用集群搭建、配置、运维与应用”在慕课网热卖中,欢迎小伙伴们订阅学习!

img{512x368}

我爱发短信:企业级短信平台定制开发专家 https://51smspush.com/。smspush : 可部署在企业内部的定制化短信平台,三网覆盖,不惧大并发接入,可定制扩展; 短信内容你来定,不再受约束, 接口丰富,支持长短信,签名可选。2020年4月8日,中国三大电信运营商联合发布《5G消息白皮书》,51短信平台也会全新升级到“51商用消息平台”,全面支持5G RCS消息。

著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格5$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式:

  • 微博:https://weibo.com/bigwhite20xx
  • 微信公众号:iamtonybai
  • 博客:tonybai.com
  • github: https://github.com/bigwhite
  • “Gopher部落”知识星球:https://public.zsxq.com/groups/51284458844544

微信赞赏:
img{512x368}

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! 图片广告位1 图片广告位2 图片广告位3 商务合作请联系bigwhite.cn AT aliyun.com

欢迎使用邮件订阅我的博客

输入邮箱订阅本站,只要有新文章发布,就会第一时间发送邮件通知你哦!

这里是 Tony Bai的个人Blog,欢迎访问、订阅和留言! 订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠 ,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:

以太币:

如果您喜欢通过微信浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机,即可获得10美元现金充值,可 免费使用两个月哟! 著名主机提供商Linode 10$优惠码:linode10,在 这里注册即可免费获 得。阿里云推荐码: 1WFZ0V立享9折!


View Tony Bai's profile on LinkedIn

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats