前置知识
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 也能够使用该实验特性。
