Go tip 是 Go 语言的实验分支，包含了很多尚在讨论，但很有可能会加入 stable 分支的特性。“Go tip 在做什么”（原文地址：What's happening in Go tip）分析总结了 Go 语言尚在开发中的一些重要特性。
本文译自：What's happening in Go tip (2014-01-10)
现在是 2014 年了，刚刚经历了圣诞和新年前夜，Go 团队就已经开始为下一个发布版本而工作了。也因此，“Go tip 在做什么”系列也重开了。
作为这个系列的最新一篇，这篇文章将会有些小调整。最重要的调整是，不会再遵循每周一篇文章的发布周期。一周里可能有几篇文章，也可能一篇都没有。这个调整，一部分由于个人原因，一部分也因为这样可以更灵活的追踪 Go 的改变。这样做的结果是，每篇文章可能会比以前更短，以便能紧跟最新的开发变化。
另一个调整是，将会覆盖一些关于没有变化的代码的形成原因和讨论。这是因为 Go 1.3 将会有重大改变（主要是计划用 Go 重写整个编译器），有些代码需要及早被大家了解。
这篇文章我们将会关注类型sync.Pool。这个类型是 Go 1.3 标准库新添加的第一个重要功能。
做了什么
添加了
sync.Pool类型开发流程的小改变
添加了sync.Pool类型
相关 CL：CL 41860043, CL 43990043, CL 37720047, CL 44080043, CL 44150043, CL 44060044, CL 44050044,CL 44680043, CL 46010043
像 JVM 这种项目，花了很多的精力来改进垃圾收集系统，来保证其所要处理回收的众多垃圾。另一方面 Go，大致上采用了在第一时间避免垃圾的设计方法，需要一个不那么时髦的垃圾收集系统，来保证将内存的控制权交还给程序员。
由于这点，标准库里一些包分别实现了重用对象的池，来避免产生过多的垃圾。regexp包为了保证并发时使用同一个正则，而维护了一组状态机，fmt包有众多的打印实例，其他包也有各自的池，或者可以采用这种技术。
不过，这种方法有两个问题。最明显的问题是代码重复：即便重要的代码大都相同，所有的包也需要实现一份自己的池。比较细微的问题是，没有办法回收池持有的空间。这种简单的实现从来不会释放内存，违反了使用垃圾回收的语言的原则，导致过高但不必要的内存使用。
因为这些问题，Brad Fizpatrick曾建议在sync包里加入一个公开的Cache类型。这个建议引发了一长串的讨论。Go 语言应该在标准库里提供一个这个样子的类型，还是应当将这个类型作为私下的实现？这个实现应该真的释放内存么？如果释放，什么时候释放？这个类型应当叫做Cache，或者更应该叫做Pool？
我先解释一下缓存（cache）和池（pool）的区别，以及为什么这个区别对讨论很重要。Brad Fizpatrick 建议的类型实际上是一种池：一组可以互换的值，取出时并不关心具体的值是什么，因为每个值都是刚被初始化的状态，值是相同的。你甚至分不出来刚刚拿到的值是从池里取出来的，还是新创建的。另一方面，缓存是一些相呼映射的键和值。一个明显的例子是磁盘缓存。磁盘缓存将慢速存储中的文件缓存在系统主内存里，以便提高访问速度。如果缓存里有对应键 A 和 B 的值（磁盘缓存的例子里，就是文件名），而你请求了与 A 对应的值，你显然不想得到 B 所对应的值。实际上，缓存里的值是互不相同的，增加了缓存清除机制的复杂性，就是说到底哪个值应该被清除出缓存。维基百科上关于缓存算法的页面，列举了 13 种不同的清除缓存的算法，从著名的 LRU 缓存到更复杂的比如LIRS 缓存算法。
按照这种方式，我们的池真正要关心的问题，只是什么时候回收池占有的空间。而且大家提到了几乎各种可能性：一些在 GC 前回收，一些在 GC 后，基于时钟或者采用弱引用指针。所有的建议都有其弊病。
在经历了漫长的讨论后，Russ Cox 最终提议的 API 和回收策略非常简单：在垃圾收集时回收池空间。这个建议提醒我们，类型Pool的目的是在垃圾收集之间重用内存。它不应该避免垃圾回收，而是让垃圾回收变得更有效。
实现了这个提议，并在几次讨论后，提交到 Go 的代码库。当然，这个 CL 不是最终结果。首先，所有的池都要改写为sync.Pool。这些改写由CL 43990043，CL 37720047，CL 44080043，CL 44150043，CL 44060044追踪，但不包括CL 44050044。CL 44050044关注在尝试将encoding/gob包里使用的本地释放链表替换为sync.Pool。本地是个关键词。一个释放链表会和一个解码器（decoder）的生存时期一样长，直到这个解码器被销毁，才会释放这个链表。Russ Cox回复了这个 CL，明确了sync.Pool的目的，以及它不能用来做什么。直到这时，Rob Pike 提交并回复了CL 44680043，扩展了sync.Pool类型的文档，将其目的描述得更清楚。
Pool设计用意是在全局变量里维护的释放链表，尤其是被多个 goroutine 同时访问的全局变量。使用Pool代替自己写的释放链表，可以让程序运行的时候，在恰当的场景下从池里重用某项值。sync.Pool一种合适的方法是，为临时缓冲区创建一个池，多个客户端使用这个缓冲区来共享全局资源。另一方面，如果释放链表是某个对象的一部分，并由这个对象维护，而这个对象只由一个客户端使用，在这个客户端工作完成后释放链表，那么用Pool实现这个释放链表是不合适的。
从回复（和更早的讨论）来看，加入sync.Pool还是一种试验，如果Pool没有实现它的功能，有可能发布 Go 1.3 之前将其完全移除。这件事情由Issue 6984跟踪。
虽然本文对sync.Pool的探索结束了，但是关于池的讨论还没有结束。还有CL 46010043，为了更适合并发时使用，改进了非常简单的初始化实现。但这个 CL 在目前还没有通过审核。
开发流程的小改变
从 Go 1.3 的周期开始，开发的流程有一些小的变化。这些变化只会影响到直接参与开发流程的人，以及像我一样，紧跟最新变动的人。
启用了一个新的邮件列表，golang-coderreviews，并作为新 CL 的默认抄送对象，替代了原有的golang-dev。这个想法是为了降低 golang-dev 里的噪音，以便让其关注真正的讨论。
同时也启用了一个新的信息板，允许提交者更容易的跟踪还在开放的 Issue 和 CL。任何对 Go 团队的工作方式感兴趣的人，都可以在这个新的信息板上找到有用的说明。
来源：oschina
链接：https://my.oschina.net/u/115763/blog/282376