Go1.20最新资讯go arena手动管理内存鸽了
作者:煎鱼
导读
年初有给大家分享 Go1.20 arena 能手动管理内存的事情,当时不论是我们读者,还是社区上的小伙伴们,都是比较激动的。毕竟这是一个有意思的特性。
这不,今年都快过去了。2024 年要来了。有小伙伴问这个最新的进展:
今天这篇文章就是给大家同步目前的情况。第一节是前置知识,如果不太记得背景的同学可以快速看一下。
前置知识
Arena 指的是一种从一个连续的内存区域分配一组内存对象的方式。优点比一般的内存分配更有效率,也可以一次性释放。当然了,它的重点是要手动管理内存。
Go 团队,基于 Google 自身的需求,快速通过了实践。在 Go1.20 支持使用环境变量启用:
GOEXPERIMENT=arenas go run main.go
预计至少会提供以下 API:
- NewArena:创建一个新的 arena 内存空间。
- Free:释放 arena 及其关联对象。
- New:基于 arena,创建新对象。NewSlice 等属于其派生方法,结果是一样的。
- MakeSlice:基于 arena,创建新切片。
- Clone:克隆一个 arena 的对象,并移动到内存堆上。
对应的示例代码如下:
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
方法进行释放。
简单来讲就是可以手动管理内存,就可以做很多事了,当然,也 “容易” 崩。
最新进展
其实这个 arena 提案当时已经快速的进入了实验阶段,大家以为能很快就能正式发布了。(毕竟来自 Google 内部的需求)
但这个特性引发了非常多的讨论,应该有超过 1k+ 条评论。
当前 arena 提案的状态为:自 2023 年 1 月 17 日起,由于严重的 API 问题,该提案被无限期搁置,GOEXPERIMENT=arena 代码可能会随时发生不兼容的更改或删除,我们不建议在生产中使用它。
由于过于繁杂,Go 核心团队成员@Ian Lance Taylor,也表态:目前尚未做出任何决定,也不可能在短期内做出任何决定。
可以认为这个提案基本鸽了,因为已经快一年了,也没有新的破局思路。
争议点
原本如此高歌猛进的 arena 提案,是在哪卡壳阻塞了?从我猛翻 1k 楼层来看,以及官方给出的原因来看。
主要还是有一位同学提出:担心重走上下文(context)的老路!
目前 context 大量的渗透了 Go 所有库的 API,虽然很难评定好与不好。但是纯粹从语言设计的角度来看,上下文并不漂亮。
甚至我经常遇到同学来吐槽,咱们这个 ctx 放在函数第一个参数,或是放结构体里。到底是谁的设计。能不能像 Java 语言一样来个注解。
但 arena 不一样,一旦和 context 一样泛滥,将会带来更大的影响。你永远不知道你正在使用的第三方库,是否使用了手动管理内存 arena,是否会导致各种奇怪的问题。(除非你去翻代码和依赖)
因此 arena 库的出现,将会导致在创建对象时进行的一系列分配行为,将没有明确的界限,完全取决于应用他的库如何使用。同时在内部处理 arena 和非 arena 情况的实现代码,将使得 API 将变得更加污染。
最终大家还是希望 arena 能够在一定的界限范围内明确使用。但这一切均悬而未决。以上是我个人结合讨论所理解的提案阻塞缘由。
总结
Arena,这是一个非常受大家关注的特性,因为他可以在 Go 语言中做到手动管理内存,做更多的一些骚操作。以后就不用另辟蹊径走 CGO 了。
但潘多拉魔盒一旦打开,还是有潜在风险的。因此 arena 库很大概率会在找到更安全的 API 设计后,才会正式转为正式库对外公开。
当然,如果你想自己内部使用,且已经知悉风险。也可以直接在 Go1.20 使用 GOEXPERIMENT=arenas
也能够使用该实验特性。
以上就是Go1.20最新资讯go arena手动管理内存鸽了的详细内容,更多关于Go arena内存管理的资料请关注脚本之家其它相关文章!