大家好，我是炸鱼。大约半年前，我写了一篇文章《Go 要违背初心吗？新提案：手动管理内存》。有兴趣深入了解的同学可以再复习一遍。当时，我们认为Go团队不会接受它，至少不会这么快：如果你懒得看，你可以再看一遍。文中提到的提案《proposal: arena: new package providing memory arenas》，其中竞技场将作为突破道具。QuickBackgroundArena指的是一种从内存的连续区域分配一组内存对象的方式。优点是比一般的内存分配效率更高，也可以一次性释放。当然，它的重点是手动管理内存。Go团队希望增加Go特性，示例代码如下：import("arena"...)typeTstruct{valint}funcmain(){a:=arena.New()varptrT*Ta.New(&ptrT)ptrT.val=1varsliceT[]Ta.NewSlice(&sliceT,100)sliceT[99].val=4a.Free()}手动调用arena.New方法分配arena内存，然后调用Free方法释放。简单点说，可以手动管理内存，可以做很多事情，而且“容易”死机。最新进展这个提议一直是一个中等争议性的问题讨论。@MichaelKnyszek写代码的速度很快，已经直接提交了。。。直到最近才发现让他更新进度。已经明确：Go1.20会支持arena功能，通过GOEXPERIMENT=arena开启，接受大家的审核和使用，阻力很小。实现的API与原始提案的区别在于API使用了泛型，例如：arena.New[int](myArena"int")。Arena的块大小是8MiB而不是64MiB，这似乎在更多情况下提供更好的性能。MSAN和ASAN模式可用于识别不会导致崩溃的释放后使用错误（内存损坏应该仍然是不可能的）。请注意，这些模式对非cgo的Go程序影响不大。竞技场是个例外。另外，根据社区的反馈，竞技场可能会有辅助类型。以下函数签名：//MakeMap使用提供的容量创建一个新的map[K]V。//释放arena后不得使用map[K]V。//释放后访问地图的底层存储可能会导致错误，//但也不一定会出现此错误。funcMakeMap[Kcomparable,Vany](a*Arena,capint"Kcomparable,Vany")map[K]V{...}如果Go1.20发布这个新特性，按照发布周期计划，会在2月左右发布。相信大家很快就能用上，大家多多关注。总结当我第一次了解到这个提案时，我认为Go花了将近10年的时间才采用和推广泛型。这竞技场应该不会这么快吧？毕竟如果加上的话，很多程序都可以写的更复杂一些。没想到……现实给我的耳光打得太快了，进步的很快。正如其他朋友所说，这可以在不削减需求的情况下从代码上优化性能。这也是一个有趣且良好的动力来源！根据八卦，有同学说测试了框架和其他场景，有说变快了，有说没差多少。比较混乱，提案中暂时没有提供测试报告，所以不好下结论。Go1.20Beta将在未来几周内发布（2022年11月结束前），让我们拭目以待：）文章持续更新中，可以微信搜索【脑补炸鱼】阅读，本文GitHubgithub.com/eddycjy/blog已收录，学习Go语言可以查看Go学习地图和路线，欢迎更新Star。推荐阅读Goonlyiferr!=nil?不对，把这些优雅的搬运姿势分享给你！Go错误处理的新思路？用左边的函数和表达式先睹为快，Go2Error的奋斗之路Go书系列Go语言入门系列：实践中的Go项目初探Go语言编程之旅：深入使用Go做项目Go语言设计理念：Go语言进阶之旅：深入了解源码
