go语言编译器分析 go语言 编译
Go语言怎么样?
根据Go趋势报告显示,全球范围内有 110 万专业开发者选择Go作为其主要开发语言。如果把以其他编程语言作为主要开发语言,同时也在使用Go的开发者计算在内,这一数字将高达270万,中国的Go语言开发者排名第一,全球占比超过16%。
措美网站制作公司哪家好,找创新互联公司!从网页设计、网站建设、微信开发、APP开发、自适应网站建设等网站项目制作,到程序开发,运营维护。创新互联公司成立于2013年到现在10年的时间,我们拥有了丰富的建站经验和运维经验,来保证我们的工作的顺利进行。专注于网站建设就选创新互联公司。
Go 语言能够支持并构建与微服务结合的内部工具、架构和后端服务而深受IT企业欢迎,许多IT架构工具由Go构建而成,例如大型的Kubernetes、Docker和Vault等。数据显示,有63%的具有统治力的云原生项目都是用Go构建。
因此,博睿数据在国内首发支持Go语言智能探针,对于提升业务性能,助力企业数字化转型有着非常重要的意义。
SmartAgent探针技术集结主流编程语言
SmartAgent是博睿数据自研的自动化部署的一体化探针,在已支持JAVA,PHP,点虐 ,Nodejs,.NET Core,Python的基础上,新增了对Go语言的支持。
相较而言,传统探针技术需要客户配合修改应用程序代码,风险不可控,需要客户重新编译程序集成探针,耦合度高。
不同于行业内传统探针技术,博睿数据GoAgent探针直接后台安装即可,主动注入和嵌码,降低与客户程序耦合、无需二次修改代码、提高 GoAgent 技术易用性。无论是动态编译还是静态编译的代码,博睿数据Samrt Agent技术都可以在不进行任何修改的情况下进行服务级别和代码级别的分布式链路跟踪,实现业务的可观测性。
GoAgent探针支持六大功能,实现全链路追踪
Go语言编译器TinyGo,基于LLVM,在微控制器和小系统上编译和运行
TinyGo是一个为微控制器、WebAssembly(Wasm)和命令行工具等小型场景设计的Go语言编译器。TinyGo重用了Go语言工具和LLVM使用的库,以编译用Go语言编写的程序。目前,该项目在GitHub上已经积累了10.1k的Star。
如下为一个示例程序,当运行在任何支持的带板载LED的主板上时,则会点亮内置LED。
上述程序可以在单片机、Adafruit ItsyBitsy M0微控制器或任何支持的带内置LED的板上进行编译和不需要修改的运行,只要设置正确的TinyGo编译器目标即可。例如,设置如下目标可以编译和点亮 单片机。
项目概述
TinyGo项目旨在将Go语言引入到具有单进程或核心的微控制器和小系统。TinyGo类似于emgo,但主要的区别在于作者想要保留Go内存模型。另一个区别在于TinyGo在内部使用LLVM,因而可以获得更小更高效的代码以及更高的灵活性。
创建TinyGo项目的初衷是,如果Python可以在微控制器上运行,Go语言当然也应该能够在更低级微设备上运行。
支持设备
你可以为微控制器、WebAssembly和Linux编译TinyGo程序。目前,TinyGo支持以下85种微处理器板。
更多技术细节请参阅原项目。
Go 语言内存管理(三):逃逸分析
Go 语言较之 C 语言一个很大的优势就是自带 GC 功能,可 GC 并不是没有代价的。写 C 语言的时候,在一个函数内声明的变量,在函数退出后会自动释放掉,因为这些变量分配在栈上。如果你期望变量的数据可以在函数退出后仍然能被访问,就需要调用 malloc 方法在堆上申请内存,如果程序不再需要这块内存了,再调用 free 方法释放掉。Go 语言不需要你主动调用 malloc 来分配堆空间,编译器会自动分析,找出需要 malloc 的变量,使用堆内存。编译器的这个分析过程就叫做逃逸分析。
所以你在一个函数中通过 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语言 编译
本文地址:http://scyanting.com/article/ddgipcc.html