探究 Go 语言 defer 语句的三种机制
云栖号:https://yqh.aliyun.com
第一手的上云资讯,不同行业精选的上云企业案例库,基于众多成功案例萃取而成的最佳实践,助力您上云决策!
Golang 的 1.13 版本 与 1.14 版本对 defer 进行了两次优化,使得 defer 的性能开销在大部分场景下都得到大幅降低,其中到底经历了什么原理?
这是因为这两个版本对 defer 各加入了一项新的机制,使得 defer 语句在编译时,编译器会根据不同版本与情况,对每个 defer 选择不同的机制,以更轻量的方式运行调用。
堆上分配
在 Golang 1.13 之前的版本中,所有 defer 都是在堆上分配,该机制在编译时会进行两个步骤:
1.在 defer 语句的位置插入 runtime.deferproc,当被执行时,延迟调用会被保存为一个 _defer 记录,并将被延迟调用的入口地址及其参数复制保存,存入 Goroutine 的调用链表中。
2.在函数返回之前的位置插入 runtime.deferreturn,当被执行时,会将延迟调用从 Goroutine 链表中取出并执行,多个延迟调用则以 jmpdefer 尾递归调用方式连续执行。
这种机制的主要性能问题存在于每个 defer 语句产生记录时的内存分配,以及记录参数和完成调用时参数移动的系统调用开销。
栈上分配
Go 1.13 版本新加入 deferprocStack 实现了在栈上分配的形式来取代 deferproc,相比后者,栈上分配在函数返回后 _defer 便得到释放,省去了内存分配时产生的性能开销,只需适当维护 _defer 的链表即可。
编译器有自己的逻辑去选择使用 deferproc 还是 deferprocStack,大部分情况下都会使用后者,性能会提升约 30%。不过在 defer 语句出现在了循环语句里,或者无法执行更高阶的编译器优化时,亦或者同一个函数中使用了过多的 defer 时,依然会使用 deferproc。
开放编码
Go 1.14 版本继续加入了开发编码(open coded),该机制会将延迟调用直接插入函数返回之前,省去了运行时的 deferproc 或 deferprocStack 操作,在运行时的 deferreturn 也不会进行尾递归调用,而是直接在一个循环中遍历所有延迟函数执行。
这种机制使得 defer 的开销几乎可以忽略,唯一的运行时成本就是存储参与延迟调用的相关信息,不过使用此机制需要一些条件:
1.没有禁用编译器优化,即没有设置 -gcflags "-N";
2.函数内 defer 的数量不超过 8 个,且返回语句与延迟语句个数的乘积不超过 15;
3.defer 不是在循环语句中。
该机制还引入了一种元素 —— 延迟比特(defer bit),用于运行时记录每个 defer 是否被执行(尤其是在条件判断分支中的 defer),从而便于判断最后的延迟调用该执行哪些函数。
延迟比特的原理:同一个函数内每出现一个 defer 都会为其分配 1 个比特,如果被执行到则设为 1,否则设为 0,当到达函数返回之前需要判断延迟调用时,则用掩码判断每个位置的比特,若为 1 则调用延迟函数,否则跳过。
为了轻量,官方将延迟比特限制为 1 个字节,即 8 个比特,这就是为什么不能超过 8 个 defer 的原因,若超过依然会选择堆栈分配,但显然大部分情况不会超过 8 个。
用代码演示如下:
deferBits = 0 // 延迟比特初始值 00000000 deferBits |= 1 << 0 // 执行第一个 defer,设置为 00000001 _f1 = f1 // 延迟函数 _a1 = a1 // 延迟函数的参数 if cond { // 如果第二个 defer 被执行,则设置为 00000011,否则依然为 00000001 deferBits |= 1 << 1 _f2 = f2 _a2 = a2 } ... exit: // 函数返回之前,倒序检查延迟比特,通过掩码逐位进行与运算,来判断是否调用函数 // 假如 deferBits 为 00000011,则 00000011 & 00000010 != 0,因此调用 f2 // 否则 00000001 & 00000010 == 0,不调用 f2 if deferBits & 1 << 1!= 0{ deferBits &^= 1 << 1 // 移位为下次判断准备 _f2(_a2) } // 同理,由于 00000001 & 00000001 != 0,调用 f1 if deferBits && 1 << 0!= 0{ deferBits &^= 1 << 0 _f1(_a1) }
总结
以往 Golang defer 语句的性能问题一直饱受诟病,最近正式发布的 1.14 版本终于为这个争议画上了阶段性的句号。如果不是在特殊情况下,我们不需要再计较 defer 的性能开销。
云栖号:https://yqh.aliyun.com
第一手的上云资讯,不同行业精选的上云企业案例库,基于众多成功案例萃取而成的最佳实践,助力您上云决策!
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
Python数据可视化告诉你:境外的疫情到底有多严重!
云栖号:https://yqh.aliyun.com第一手的上云资讯,不同行业精选的上云企业案例库,基于众多成功案例萃取而成的最佳实践,助力您上云决策! 连日来,在境内的新冠肺炎疫情得到有效的控制之下,境外的疫情却迅速蔓延,除了南极洲之外,世界六大洲已有53个国家发现病毒确诊病例,并且每日不断激增。今天小编就用数据可视化的方式来为大家一一呈现,新冠肺炎在世界其他国家的具体严重程度(数据来自世界卫生组织的最新病情报告)。 从上面的世界疫情图可以到的是,除了中国之外呢,韩国、日本,以及远在欧洲的意大利与中东的伊朗疫情最为严重,已经出现了不少的死亡病例,并且病毒已经在本国范围开始迅速的蔓延。 亚洲 在亚洲,韩国的确诊人数最多,达到了3736例,较此前增加了586例,同时死亡病例已达到17例。为何在韩国,确诊病例会突然增加呢?韩国当局发现,新天地教会是此次疫情爆发的中心,而该教会中的一名成员在上周的检测中对病毒呈现阳性,起初还拒绝到医院检测并且坚持参加了数次教会活动。所以最后导致的结果就是教会之间的成员相互感染,然后开始在全国传播。 而除了韩国之外,日本的确诊人数也已达到230例同时伴有5例死...
- 下一篇
好程序员Java培训分享Java工程师应具备哪些好习惯?
作为当前市场上人才需求最大、应用领域最广的编程语言,Java一直深受企业和转行IT行业人士的青睐。而分析普通Java工程师和高薪Java工程师之间的区别,不难发现编程习惯是一个非常关键的因素。高薪Java工程师具备哪些编程好习惯呢?接下来就给大家分享一下。1、尽量避免过多过常的创建Java对象尽量避免在经常调用的方法,循环中new对象,由于系统不仅要花费时间来创建对象,而且还要花时间对这些对象进行垃圾回收和处理,在我们可以控制的范围内,最大限度的重用对象,最好能用基本的数据类型或数组来替代对象。2、尽量使用final修饰符带有final修饰符的类是不可派生的。在Java核心API中,有许多应用final的例子,例如java.lang.String。为String类指定final防止了使用者覆盖length()方法。另外,如果一个类是final的,则该类所有方法都是final的。Java编译器会寻找机会内联(inline)所有的final方法(这和具体的编译器实现有关)。此举能够使性能平均提高50%。3、尽量使用局部变量调用方法时传递的参数以及在调用中创建的临时变量都保存在栈(Sta...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Hadoop3单机部署,实现最简伪集群
- CentOS8编译安装MySQL8.0.19
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题
- Windows10,CentOS7,CentOS8安装MongoDB4.0.16
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- SpringBoot2整合Thymeleaf,官方推荐html解决方案
- Eclipse初始化配置,告别卡顿、闪退、编译时间过长
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- Mario游戏-低调大师作品
- CentOS6,CentOS7官方镜像安装Oracle11G