Go中实现手动内存分配的坑
2016-07-10
你一定想到过，分配一块大的内存，然后从里面切小的对象出来，手动管理对象分配。分配的开销非常小，就是offset加一下。尤其是有些场景，释放时直接把offset重置，就可以重用这块空间了。实现手动内存分配的好处是，减少小对象数目，从而减少垃圾回收时的扫描开销，降低延迟和提升整个性能。
想到不代表做过，做过会踩坑，这篇文章会把你可能要踩的坑都说一遍。不过先说结论：别这么干，不作死就不会死！
TL;DR
扩容
开始很容易想用make([]byte)分配空间，如果大小不够时，还可以进行扩容。这是第一个陷阱。
不要append，别让它扩容。一旦发生扩容，会分配一块新的空间，而旧的slice将不再有任何变量引用它，于是会被垃圾回收掉。等等！之前分配的对象还在里面呢，被回收掉岂不傻逼了？
所以建议直接用固定大小的数组，而不是slice。如果想做成可增长的，用一个链表串起来。
const blockSize = 32*1024*1024 - 16
type node struct {
block [blockSize]byte
off int
next *node
}
type Allocator {
head *node
tail *node
}
初始化
初始化是很容易漏掉的地方。重用之前的内存空间，如果忘记了初始化，分配出来的对象不是干净的。
一种方式是C的malloc语义，分配的对象空间就是不初始化的，用户自己去处理。比如：
t := (*T)(ac.Alloc(sizeT))
*t = T{a:3, b:5}
另一种做法可以在Reset的时候把整块空间清除一遍，这样分配出去的都是初始化为零的。
对象内部存在引用
现在分配器的接口是这样子的：
func (ac *Allocator) Alloc(size int) unsafe.Pointer
你觉得没什么问题了，拿它来分配对象，结果使用时却遇到莫名奇妙的内存错误。为什么呢？
假设用它来分配对象T：
type T struct {
s *S
}
t := (*T)(ac.Alloc(sizeT))
t.s = &S{}
T对象的空间是从一块数组里面划出来的，垃圾回收其实并不知道T这个对象。不过只要Allocator里面的大块内存不被回收，T对象还是安全的。但是，对于T里面的S，它是标准方式分配的，这就会有问题了。
假设发生垃圾回收了，GC会以为那块内存空间就是一个大的数组，而不会被扫描对象T，那么t.s的空间未被任何对象引用到，它会被清理掉。最后t.s就变成一个悬挂指针了！
这样实现的分配器只能处理两种情况，一种是用于分配对象里面不包含其它引用。另一种，对象里包含引用，但引用的对象空间也是在这个分配器里面。
string的处理
我们的分配器不能分配包含引用的对象，这条限制是很严格的。假设T是：
type T struct {
name string
}
这样子都是不行的！string其实就是典型引用类型，它是一个指针加一个长度，指针指向实现的数据。你明白了吧，这样的约束之后分配器几乎就不可用了。
为了能处理引用，需要改造一下。我们加一个Prevent接口：
func (ac *Allocator) Prevent(v interface{}) {
ac.ref = append(ac.ref, v)
}
在Allocator里面加一个ref []interface，把引用的对象都加进去，这样子垃圾回收就不会把引用到的数据清掉了。
slice的处理
slice也是引用类型，处理起来更复杂一些。坑也更深，留点空间给大家去想了。
最后，当你把这些都考虑足够充分后，就发现跟初衷相违了。
本希望是一个简单的分配器来手动管理内存，可以减少对象分配，可以减少垃圾回收的扫描----但是不扫描就可能把还在使用的对象回收掉。为了处理，我们必须把对象的引用再加回去，减少对象扫描的努力成了无用功。再注意到Prevent的接口是interface类型，传参时其实会生成一个临时对象的，于是减少对象分配也没做到。
