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类型,传参时其实会生成一个临时对象的,于是减少对象分配也没做到。

allocatorgolang内存池