Golang

关注公众号 jb51net

关闭
首页 > 脚本专栏 > Golang > Go arena内存管理

Go1.20最新资讯go arena手动管理内存鸽了

作者:煎鱼

由于过于繁杂,Go 核心团队成员@Ian Lance Taylor,也表态:目前尚未做出任何决定,也不可能在短期内做出任何决定,可以认为这个提案基本鸽了,今天这篇文章就是给大家同步目前的情况

导读

年初有给大家分享 Go1.20 arena 能手动管理内存的事情,当时不论是我们读者,还是社区上的小伙伴们,都是比较激动的。毕竟这是一个有意思的特性。

这不,今年都快过去了。2024 年要来了。有小伙伴问这个最新的进展:

今天这篇文章就是给大家同步目前的情况。第一节是前置知识,如果不太记得背景的同学可以快速看一下。

前置知识

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

Go 团队,基于 Google 自身的需求,快速通过了实践。在 Go1.20 支持使用环境变量启用:

GOEXPERIMENT=arenas go run main.go

预计至少会提供以下 API:

对应的示例代码如下:

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内存管理的资料请关注脚本之家其它相关文章!

您可能感兴趣的文章:
阅读全文