查看原文
其他

打脸了兄弟们,Go1.20 arena 来了!

陈煎鱼 脑子进煎鱼了 2022-12-13

大家好,我是煎鱼。

大概半年前,我写过一篇文章《Go 要违背初心吗?新提案:手动管理内存》。有兴趣了深入解的同学,可以再回顾一下。

当时我们还想着 Go 团队应该不会接纳,至少不会那么快:


没想到,计划赶不上变化。


懒得翻也可以看我再次道来,本文提到的提案《proposal: arena: new package providing memory arenas[1]》,这其中的 Arena 将会是一个突破项。

快速背景

Arena 指的是一种从一个连续的内存区域分配一组内存对象的方式。优点比一般的内存分配更有效率,也可以一次性释放。当然了,它的重点是要手动管理内存

Go 团队希望加进 Go 特性中,示例代码如下:

import (
 “arena”
 …
)

type T struct {
 val int
}

func main() {
 a := arena.New()
 var ptrT *T
 a.New(&ptrT)
 ptrT.val = 1

 var sliceT []T
 a.NewSlice(&sliceT, 100)
 sliceT[99].val = 4

 a.Free()
}

手动调用 arena.New 方法分配 arena 内存,再调用 Free 方法进行释放。

简单来讲就是可以手动管理内存,就可以做很多事了,因为可以乱来,所以也 “容易” 崩。

最新进展

这个提案一直在 issues 上适度的争议讨论,@Michael Knyszek 大佬代码写的很快,已经直接提交上去了...直到最近被人发现,让他更新进度。

已经明确:Go1.20 将会支持 arena 特性,通过 GOEXPERIMENT=arena 来打开,接受大家的 review 和使用,社区当前抗阻较小。

已实现 API 和原提案不同的地方有:

  • API 使用了泛型,例如:arena.New[int](myArena "int")
  • Arena 的 块大小是 8 MiB 而不是 64 MiB,似乎在更多情况下提供了更好的性能。
  • MSAN 和 ASAN 模式可用于识别不会导致崩溃的 use-after-free 错误(内存损坏应该仍然是不可能的)。需注意,这些模式对非 cgo 的 Go 程序几乎没有作用。Arena 是个例外。

另外根据社区的反馈,可能还会出现配套类型的 Arena。如下函数签名:

// MakeMap creates a new map[K]V with the provided capacity.
// The map[K]V must not be used after the arena is freed.
// Accessing the underlying storage of the map after free may result in a fault,
// but this fault is also not guaranteed.
func MakeMap[K comparable, V any](a *Arena, cap int "K comparable, V any") map[K]V { ... }

在 Go1.20 发布该新特性的话,按照发布周期计划,是 2 月份左右发布,相信大家很快就能用上,可以多多关注。

总结

一开始了解这个提案时,还想着 Go 搞了快 10 年才采纳和推进泛型。这 Arena 应该不至于这么快吧?毕竟加进去了,许多程序都可以写的复杂起来。

没想到...现实打脸来的太快,推进的很快。

就像其他小伙伴说的,这可以直接从代码侧优化性能,而不需要砍需求。也是一个有意思且不错的源动力!

据小道消息,某些同学表示在框架和其它场景测过,有说变得快了,有说没差多少。比较迷,提案内暂时未提供测试报告,不好定论。

Go 1.20 Beta 将在未来几周内(2022.11 月底前)发布,让我们拭目以待:

推荐阅读

参考资料

[1]

proposal: arena: new package providing memory arenas: https://github.com/golang/go/issues/51317

关注和加煎鱼微信,

获取一手业内消息和知识,拉你进交流群👇

你好,我是煎鱼,出版过 Go 畅销书《Go 语言编程之旅》,再到获得 GOP(Go 领域最有观点专家)荣誉,点击蓝字查看我的出书之路

日常分享高质量文章,输出 Go 面试、工作经验、架构设计,加微信拉读者交流群,和大家交流!

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存