Golang 的内存管理基于 tcmalloc，可以说起点挺高的。但是 Golang 在实现的时候还做了很多优化，我们下面通过源码来看一下 Golang 的内存管理实现。下面的源码分析基于 go1.8rc3。
1.tcmalloc 介绍
关于 tcmalloc 可以参考这篇文章 tcmalloc 介绍，原始论文可以参考 TCMalloc : Thread-Caching Malloc。
2. Golang 内存管理
0. 准备知识
这里先简单介绍一下 Golang 运行调度。在 Golang 里面有三个基本的概念：G, M, P。
G: Goroutine 执行的上下文环境。
M: 操作系统线程。
P: Processer。进程调度的关键，调度器，也可以认为约等于 CPU。
一个 Goroutine 的运行需要 G + P + M 三部分结合起来。好，先简单介绍到这里，更详细的放在后面的文章里面来说。
1. 逃逸分析(escape analysis)
对于手动管理内存的语言，比如 C/C++，我们使用 malloc 或者 new 申请的变量会被分配到堆上。但是 Golang 并不是这样，虽然 Golang 语言里面也有 new。Golang 编译器决定变量应该分配到什么地方时会进行逃逸分析。下面是一个简单的例子。
package mainimport ()func foo() *int { var x int return &x}func bar() int { x := new(int) *x = 1 return *x}func main() {}将上面文件保存为 escape.go，执行下面命令
$ go run -gcflags '-m -l' escape.go./escape.go:6: moved to heap: x./escape.go:7: &x escape to heap./escape.go:11: bar new(int) does not escape上面的意思是 foo() 中的 x 最后在堆上分配，而 bar() 中的 x 最后分配在了栈上。在官网 (golang.org) FAQ 上有一个关于变量分配的问题如下：
如何得知变量是分配在栈(stack)上还是堆(heap)上？
准确地说，你并不需要知道。Golang 中的变量只要被引用就一直会存活，存储在堆上还是栈上由内部实现决定而和具体的语法没有关系。
知道变量的存储位置确实和效率编程有关系。如果可能，Golang 编译器会将函数的局部变量分配到函数栈帧(stack frame)上。然而，如果编译器不能确保变量在函数 return 之后不再被引用，编译器就会将变量分配到堆上。而且，如果一个局部变量非常大，那么它也应该被分配到堆上而不是栈上。
当前情况下，如果一个变量被取地址，那么它就有可能被分配到堆上。然而，还要对这些变量做逃逸分析，如果函数 return 之后，变量不再被引用，则将其分配到栈上。
2. 关键数据结构
几个关键的地方：
1.mcache: per-P cache，可以认为是 local cache。
2.mcentral: 全局 cache，mcache 不够用的时候向 mcentral 申请。
3.mheap: 当 mcentral 也不够用的时候，通过 mheap 向操作系统申请。
可以将其看成多级内存分配器。
2.1 mcache
我们知道每个 Gorontine 的运行都是绑定到一个 P 上面，mcache 是每个 P 的 cache。这么做的好处是分配内存时不需要加锁。mcache 结构如下。
// Per-thread (in Go, per-P) cache for small objects.// No locking needed because it is per-thread (per-P).type mcache struct { // The following members are accessed on every malloc, // so they are grouped here for better caching. next_sample int32 // trigger heap sample after allocating this many bytes local_scan uintptr // bytes of scannable heap allocated // 小对象分配器，小于 16 byte 的小对象都会通过 tiny 来分配。 tiny uintptr tinyoffset uintptr local_tinyallocs uintptr // number of tiny allocs not counted in other stats // The rest is not accessed on every malloc. alloc [_NumSizeClasses]*mspan // spans to allocate from stackcache [_NumStackOrders]stackfreelist // Local allocator stats, flushed during GC. local_nlookup uintptr // number of pointer lookups local_largefree uintptr // bytes freed for large objects (>maxsmallsize) local_nlargefree uintptr // number of frees for large objects (>maxsmallsize) local_nsmallfree [_NumSizeClasses]uintptr // number of frees for small objects (<=maxsmallsize)}我们可以暂时只关注 alloc [_NumSizeClasses]*mspan，这是一个大小为 67 的指针(指针指向 mspan )数组(_NumSizeClasses = 67)，每个数组元素用来包含特定大小的块。当要分配内存大小时，为 object 在 alloc 数组中选择合适的元素来分配。67 种块大小为 0，8 byte, 16 byte, … ，这个和 tcmalloc 稍有区别。
//file: sizeclasses.govar class_to_size = [_NumSizeClasses]uint16{0, 8, 16, 32, 48, 64, 80, 96, 112, 128, 144, 160, 176, 192, 208, 224, 240, 256, 288, 320, 352, 384, 416, 448, 480, 512, 576, 640, 704, 768, 896, 1024, 1152, 1280, 1408, 1536, 1792, 2048, 2304, 2688, 3072, 3200, 3456, 4096, 4864, 5376, 6144, 6528, 6784, 6912, 8192, 9472, 9728, 10240, 10880, 12288, 13568, 14336, 16384, 18432, 19072, 20480, 21760, 24576, 27264, 28672, 32768}这里仔细想有个小问题，上面的 alloc 类似内存池的 freelist 数组或者链表，正常实现每个数组元素是一个链表，链表由特定大小的块串起来。但是这里统一使用了 mspan 结构，那么只有一种可能，就是 mspan 中记录了需要分配的块大小。我们来看一下 mspan 的结构。
2.2 mspan
span 在 tcmalloc 中作为一种管理内存的基本单位而存在。Golang 的 mspan 的结构如下，省略了部分内容。
type mspan struct { next *mspan // next span in list, or nil if none prev *mspan // previous span in list, or nil if none list *mSpanList // For debugging. TODO: Remove. startAddr uintptr // address of first byte of span aka s.base() npages uintptr // number of pages in span stackfreelist gclinkptr // list of free stacks, avoids overloading freelist // freeindex is the slot index between 0 and nelems at which to begin scanning // for the next free object in this span. freeindex uintptr // TODO: Look up nelems from sizeclass and remove this field if it // helps performance. nelems uintptr // number of object in the span. ... // 用位图来管理可用的 free object，1 表示可用 allocCache uint64 ... sizeclass uint8 // size class ... elemsize uintptr // computed from sizeclass or from npages ...}从上面的结构可以看出：
1.next, prev: 指针域，因为 mspan 一般都是以链表形式使用。
2.npages: mspan 的大小为 page 大小的整数倍。
3.sizeclass: 0 ~ _NumSizeClasses 之间的一个值，这个解释了我们的疑问。比如，sizeclass = 3，那么这个 mspan 被分割成 32 byte 的块。
4.elemsize: 通过 sizeclass 或者 npages 可以计算出来。比如 sizeclass = 3, elemsize = 32 byte。对于大于 32Kb 的内存分配，都是分配整数页，elemsize = page_size * npages。
5.nelems: span 中包块的总数目。
6.freeindex: 0 ~ nelemes-1，表示分配到第几个块。
2.3 mcentral
上面说到当 mcache 不够用的时候，会从 mcentral 申请。那我们下面就来介绍一下 mcentral。
type mcentral struct { lock mutex sizeclass int32 nonempty mSpanList // list of spans with a free object, ie a nonempty free list empty mSpanList // list of spans with no free objects (or cached in an mcache)}type mSpanList struct { first *mspan last *mspan}mcentral 分析：
1.sizeclass: 也有成员 sizeclass，那么 mcentral 是不是也有 67 个呢？是的。
2.lock: 因为会有多个 P 过来竞争。
3.nonempty: mspan 的双向链表，当前 mcentral 中可用的 mspan list。
4.empty: 已经被使用的，可以认为是一种对所有 mspan 的 track。
问题来了，mcentral 存在于什么地方？虽然在上面我们将 mcentral 和 mheap 作为两个部分来讲，但是作为全局的结构，这两部分是可以定义在一起的。实际上也是这样，mcentral 包含在 mheap 中。
2.4 mheap
Golang 中的 mheap 结构定义如下。
type mheap struct { lock mutex free [_MaxMHeapList]mSpanList // free lists of given length freelarge mSpanList // free lists length >= _MaxMHeapList busy [_MaxMHeapList]mSpanList // busy lists of large objects of given length busylarge mSpanList // busy lists of large objects length >= _MaxMHeapList sweepgen uint32 // sweep generation, see comment in mspan sweepdone uint32 // all spans are swept // allspans is a slice of all mspans ever created. Each mspan // appears exactly once. // // The memory for allspans is manually managed and can be // reallocated and move as the heap grows. // // In general, allspans is protected by mheap_.lock, which // prevents concurrent access as well as freeing the backing // store. Accesses during STW might not hold the lock, but // must ensure that allocation cannot happen around the // access (since that may free the backing store). allspans []*mspan // all spans out there // spans is a lookup table to map virtual address page IDs to *mspan. // For allocated spans, their pages map to the span itself. // For free spans, only the lowest and highest pages map to the span itself. // Internal pages map to an arbitrary span. // For pages that have never been allocated, spans entries are nil. // // This is backed by a reserved region of the address space so // it can grow without moving. The memory up to len(spans) is // mapped. cap(spans) indicates the total reserved memory. spans []*mspan // sweepSpans contains two mspan stacks: one of swept in-use // spans, and one of unswept in-use spans. These two trade // roles on each GC cycle. Since the sweepgen increases by 2 // on each cycle, this means the swept spans are in // sweepSpans[sweepgen/2%2] and the unswept spans are in // sweepSpans[1-sweepgen/2%2]. Sweeping pops spans from the // unswept stack and pushes spans that are still in-use on the // swept stack. Likewise, allocating an in-use span pushes it // on the swept stack. sweepSpans [2]gcSweepBuf _ uint32 // align uint64 fields on 32-bit for atomics // Proportional sweep pagesInUse uint64 // pages of spans in stats _MSpanInUse; R/W with mheap.lock spanBytesAlloc uint64 // bytes of spans allocated this cycle; updated atomically pagesSwept uint64 // pages swept this cycle; updated atomically sweepPagesPerByte float64 // proportional sweep ratio; written with lock, read without // TODO(austin): pagesInUse should be a uintptr, but the 386 // compiler can't 8-byte align fields. // Malloc stats. largefree uint64 // bytes freed for large objects (>maxsmallsize) nlargefree uint64 // number of frees for large objects (>maxsmallsize) nsmallfree [_NumSizeClasses]uint64 // number of frees for small objects (<=maxsmallsize) // range of addresses we might see in the heap bitmap uintptr // Points to one byte past the end of the bitmap bitmap_mapped uintptr arena_start uintptr arena_used uintptr // always mHeap_Map{Bits,Spans} before updating arena_end uintptr arena_reserved bool // central free lists for small size classes. // the padding makes sure that the MCentrals are // spaced CacheLineSize bytes apart, so that each MCentral.lock // gets its own cache line. central [_NumSizeClasses]struct { mcentral mcentral pad [sys.CacheLineSize]byte } spanalloc fixalloc // allocator for span* cachealloc fixalloc // allocator for mcache* specialfinalizeralloc fixalloc // allocator for specialfinalizer* specialprofilealloc fixalloc // allocator for specialprofile* speciallock mutex // lock for special record allocators.}var mheap_ mheap
mheap_ 是一个全局变量，会在系统初始化的时候初始化(在函数 mallocinit() 中)。我们先看一下 mheap 具体结构。
1.allspans []*mspan: 所有的 spans 都是通过 mheap_ 申请，所有申请过的 mspan 都会记录在 allspans。结构体中的 lock 就是用来保证并发安全的。注释中有关于 STW 的说明，这个之后会在 Golang 的 GC 文章中细说。
2.central [_NumSizeClasses]…: 这个就是之前介绍的 mcentral ，每种大小的块对应一个 mcentral。mcentral 上面介绍过了。pad 可以认为是一个字节填充，为了避免伪共享(false sharing)问题的。False Sharing 可以参考 False Sharing – wikipedia，这里就不细说了。
3.sweepgen, sweepdone: GC 相关。(Golang 的 GC 策略是 Mark & Sweep, 这里是用来表示 sweep 的，这里就不再深入了。)
4.free [_MaxMHeapList]mSpanList: 这是一个 SpanList 数组，每个 SpanList 里面的 mspan 由 1 ~ 127 (_MaxMHeapList – 1) 个 page 组成。比如 free[3] 是由包含 3 个 page 的 mspan 组成的链表。free 表示的是 free list，也就是未分配的。对应的还有 busy list。
5.freelarge mSpanList: mspan 组成的链表，每个元素(也就是 mspan)的 page 个数大于 127。对应的还有 busylarge。
6.spans []*mspan: 记录 arena 区域页号(page number)和 mspan 的映射关系。
7.arena_start, arena_end, arena_used: 要解释这几个变量之前要解释一下 arena。arena 是 Golang 中用于分配内存的连续虚拟地址区域。由 mheap 管理，堆上申请的所有内存都来自 arena。那么如何标志内存可用呢？操作系统的常见做法用两种：一种是用链表将所有的可用内存都串起来；另一种是使用位图来标志内存块是否可用。结合上面一条 spans，内存的布局是下面这样的。
8.spanalloc, cachealloc fixalloc: fixalloc 是 free-list，用来分配特定大小的块。
9.剩下的是一些统计信息和 GC 相关的信息，这里暂且按住不表，以后专门拿出来说。
3. 初始化
在系统初始化阶段，上面介绍的几个结构会被进行初始化，我们直接看一下初始化代码：mallocinit()。
func mallocinit() { //一些系统检测代码，略去 var p, bitmapSize, spansSize, pSize, limit uintptr var reserved bool // limit = runtime.memlimit(); // See https://golang.org/issue/5049 // TODO(rsc): Fix after 1.1. limit = 0 //系统指针大小 PtrSize = 8，表示这是一个 64 位系统。 if sys.PtrSize == 8 && (limit == 0 || limit > 1<<30) { //这里的 arenaSize, bitmapSize, spansSize 分别对应 mheap 那一小节里面提到 arena 区大小，bitmap 区大小，spans 区大小。 arenaSize := round(_MaxMem, _PageSize) bitmapSize = arenaSize / (sys.PtrSize * 8 / 2) spansSize = arenaSize / _PageSize * sys.PtrSize spansSize = round(spansSize, _PageSize) //尝试从不同地址开始申请 for i := 0; i <= 0x7f; i++ { switch { case GOARCH == "arm64" && GOOS == "darwin": p = uintptr(i)<<40 | uintptrMask&(0x0013<<28) case GOARCH == "arm64": p = uintptr(i)<<40 | uintptrMask&(0x0040<<32) default: p = uintptr(i)<<40 | uintptrMask&(0x00c0<<32) } pSize = bitmapSize + spansSize + arenaSize + _PageSize //向 OS 申请大小为 pSize 的连续的虚拟地址空间 p = uintptr(sysReserve(unsafe.Pointer(p), pSize, &reserved)) if p != 0 { break } } }//这里是 32 位系统代码对应的操作，略去。
... p1 := round(p, _PageSize) spansStart := p1 mheap_.bitmap = p1 + spansSize + bitmapSize if sys.PtrSize == 4 { // Set arena_start such that we can accept memory // reservations located anywhere in the 4GB virtual space. mheap_.arena_start = 0 } else { mheap_.arena_start = p1 + (spansSize + bitmapSize) } mheap_.arena_end = p + pSize mheap_.arena_used = p1 + (spansSize + bitmapSize) mheap_.arena_reserved = reserved if mheap_.arena_start&(_PageSize-1) != 0 { println("bad pagesize", hex(p), hex(p1), hex(spansSize), hex(bitmapSize), hex(_PageSize), "start", hex(mheap_.arena_start)) throw("misrounded allocation in mallocinit") } // Initialize the rest of the allocator. mheap_.init(spansStart, spansSize) _g_ := getg() _g_.m.mcache = allocmcache()}上面对代码做了简单的注释，下面详细解说其中的部分功能函数。
3.1 arena 相关
arena 相关地址的大小初始化代码如下。
arenaSize := round(_MaxMem, _PageSize)bitmapSize = arenaSize / (sys.PtrSize * 8 / 2)spansSize = arenaSize / _PageSize * sys.PtrSizespansSize = round(spansSize, _PageSize)_MaxMem = uintptr(1<<_mheapmap_totalbits>首先解释一下变量 _MaxMem ，里面还有一个变量就不再列出来了。简单来说 _MaxMem 就是系统为 arena 区分配的大小：64 位系统分配 512 G；对于 Windows 64 位系统，arena 区分配 32 G。round 是一个对齐操作，向上取 _PageSize 的倍数。实现也很有意思，代码如下。
// round n up to a multiple of a. a must be a power of 2.func round(n, a uintptr) uintptr { return (n + a - 1) &^ (a - 1)}bitmap 用两个 bit 表示一个字的可用状态，那么算下来 bitmap 的大小为 16 G。读过 Golang 源码的同学会发现其实这段代码的注释里写的 bitmap 的大小为 32 G。其实是这段注释很久没有更新了，之前是用 4 个 bit 来表示一个字的可用状态，这真是一个悲伤的故事啊。
spans 记录的 arena 区的块页号和对应的 mspan 指针的对应关系。比如 arena 区内存地址 x，对应的页号就是 page_num = (x – arena_start) / page_size，那么 spans 就会记录 spans[page_num] = x。如果 arena 为 512 G的话，spans 区的大小为 512 G / 8K * 8 = 512 M。这里值得注意的是 Golang 的内存管理虚拟地址页大小为 8k。
_PageSize = 1 << _PageShift_PageShift = 13所以这一段连续的的虚拟内存布局(64 位)如下：
3.2 虚拟地址申请
主要是下面这段代码。
//尝试从不同地址开始申请
for i := 0; i <= 0x7f; i++ { switch { case GOARCH == "arm64" && GOOS == "darwin": p = uintptr(i)<<40 | uintptrMask&(0x0013<<28) case GOARCH == "arm64": p = uintptr(i)<<40 | uintptrMask&(0x0040<<32) default: p = uintptr(i)<<40 | uintptrMask&(0x00c0<<32) } pSize = bitmapSize + spansSize + arenaSize + _PageSize //向 OS 申请大小为 pSize 的连续的虚拟地址空间 p = uintptr(sysReserve(unsafe.Pointer(p), pSize, &reserved)) if p != 0 { break }}初始化的时候，Golang 向操作系统申请一段连续的地址空间，就是上面的 spans + bitmap + arena。p 就是这段连续地址空间的开始地址，不同平台的 p 取值不一样。像 OS 申请的时候视不同的 OS 版本，调用不同的系统调用，比如 Unix 系统调用 mmap (mmap 想操作系统内核申请新的虚拟地址区间，可指定起始地址和长度)，Windows 系统调用 VirtualAlloc (类似 mmap)。
//bsdfunc sysReserve(v unsafe.Pointer, n uintptr, reserved *bool) unsafe.Pointer { if sys.PtrSize == 8 && uint64(n) > 1<<32 || sys.GoosNacl != 0 { *reserved = false return v } p := mmap(v, n, _PROT_NONE, _MAP_ANON|_MAP_PRIVATE, -1, 0) if uintptr(p) < 4096 { return nil } *reserved = true return p}//darwinfunc sysReserve(v unsafe.Pointer, n uintptr, reserved *bool) unsafe.Pointer { *reserved = true p := mmap(v, n, _PROT_NONE, _MAP_ANON|_MAP_PRIVATE, -1, 0) if uintptr(p) < 4096 { return nil } return p}//linuxfunc sysReserve(v unsafe.Pointer, n uintptr, reserved *bool) unsafe.Pointer { ... p := mmap(v, n, _PROT_NONE, _MAP_ANON|_MAP_PRIVATE, -1, 0) if uintptr(p) < 4096 { return nil } *reserved = true return p}//windowsfunc sysReserve(v unsafe.Pointer, n uintptr, reserved *bool) unsafe.Pointer { *reserved = true // v is just a hint. // First try at v. v = unsafe.Pointer(stdcall4(_VirtualAlloc, uintptr(v), n, _MEM_RESERVE, _PAGE_READWRITE)) if v != nil { return v } // Next let the kernel choose the address. return unsafe.Pointer(stdcall4(_VirtualAlloc, 0, n, _MEM_RESERVE, _PAGE_READWRITE))}3.3 mheap 初始化
我们上面介绍 mheap 结构的时候知道 spans, bitmap, arena 都是存在于 mheap 中的，从操作系统申请完地址之后就是初始化 mheap 了。
func mallocinit() { ... p1 := round(p, _PageSize) spansStart := p1 mheap_.bitmap = p1 + spansSize + bitmapSize if sys.PtrSize == 4 { // Set arena_start such that we can accept memory // reservations located anywhere in the 4GB virtual space. mheap_.arena_start = 0 } else { mheap_.arena_start = p1 + (spansSize + bitmapSize) } mheap_.arena_end = p + pSize mheap_.arena_used = p1 + (spansSize + bitmapSize) mheap_.arena_reserved = reserved if mheap_.arena_start&(_PageSize-1) != 0 { println("bad pagesize", hex(p), hex(p1), hex(spansSize), hex(bitmapSize), hex(_PageSize), "start", hex(mheap_.arena_start)) throw("misrounded allocation in mallocinit") } // Initialize the rest of the allocator. mheap_.init(spansStart, spansSize) //获取当前 G _g_ := getg() // 获取 G 上绑定的 M 的 mcache _g_.m.mcache = allocmcache()}p 是从连续虚拟地址的起始地址，先进行对齐，然后初始化 arena，bitmap，spans 地址。mheap_.init()会初始化 fixalloc 等相关的成员，还有 mcentral 的初始化。
func (h *mheap) init(spansStart, spansBytes uintptr) { h.spanalloc.init(unsafe.Sizeof(mspan{}), recordspan, unsafe.Pointer(h), &memstats.mspan_sys) h.cachealloc.init(unsafe.Sizeof(mcache{}), nil, nil, &memstats.mcache_sys) h.specialfinalizeralloc.init(unsafe.Sizeof(specialfinalizer{}), nil, nil, &memstats.other_sys) h.specialprofilealloc.init(unsafe.Sizeof(specialprofile{}), nil, nil, &memstats.other_sys) h.spanalloc.zero = false // h->mapcache needs no init for i := range h.free { h.free[i].init() h.busy[i].init() } h.freelarge.init() h.busylarge.init() for i := range h.central { h.central[i].mcentral.init(int32(i)) } sp := (*slice)(unsafe.Pointer(&h.spans)) sp.array = unsafe.Pointer(spansStart) sp.len = 0 sp.cap = int(spansBytes / sys.PtrSize)}mheap 初始化之后，对当前的线程也就是 M 进行初始化。
//获取当前 G
_g_ := getg()
// 获取 G 上绑定的 M 的 mcache
_g_.m.mcache = allocmcache()
3.4 per-P mcache 初始化
上面好像并没有说到针对 P 的 mcache 初始化，因为这个时候还没有初始化 P。我们看一下 bootstrap 的代码。
func schedinit() { ... mallocinit() ... if procs > _MaxGomaxprocs { procs = _MaxGomaxprocs } if procresize(procs) != nil { ... }}其中 mallocinit() 上面说过了。对 P 的初始化在函数 procresize() 中执行，我们下面只看内存相关的部分。
func procresize(nprocs int32) *p { ... // initialize new P's for i := int32(0); i < nprocs; i++ { pp := allp[i] if pp == nil { pp = new(p) pp.id = i pp.status = _Pgcstop pp.sudogcache = pp.sudogbuf[:0] for i := range pp.deferpool { pp.deferpool[i] = pp.deferpoolbuf[i][:0] } atomicstorep(unsafe.Pointer(&allp[i]), unsafe.Pointer(pp)) } // P mcache 初始化 if pp.mcache == nil { if old == 0 && i == 0 { if getg().m.mcache == nil { throw("missing mcache?") } // P[0] 分配给主 Goroutine pp.mcache = getg().m.mcache // bootstrap } else { // P[0] 之外的 P 申请 mcache pp.mcache = allocmcache() } } ... } ...}所有的 P 都存放在一个全局数组 allp 中，procresize() 的目的就是将 allp 中用到的 P 进行初始化，同时对多余 P 的资源剥离。
4. 内存分配
先说一下给对象 object 分配内存的主要流程：
1.object size > 32K，则使用 mheap 直接分配。
2.object size < 16 byte，使用 mcache 的小对象分配器 tiny 直接分配。 (其实 tiny 就是一个指针，暂且这么说吧。)
3.object size > 16 byte && size <=32K byte 时，先使用 mcache 中对应的 size class 分配。
4.如果 mcache 对应的 size class 的 span 已经没有可用的块，则向 mcentral 请求。
5.如果 mcentral 也没有可用的块，则向 mheap 申请，并切分。
6.如果 mheap 也没有合适的 span，则想操作系统申请。
我们看一下在堆上，也就是 arena 区分配内存的相关函数。
package mainfunc foo() *int { x := 1 return &x}func main() { x := foo() println(*x)}根据之前介绍的逃逸分析，foo() 中的 x 会被分配到堆上。把上面代码保存为 test1.go 看一下汇编代码。
$ go build -gcflags '-l' -o test1 test1.go$ go tool objdump -s "main.foo" test1TEXT main.foo(SB) /Users/didi/code/go/malloc_example/test2.go test2.go:3 0x2040 65488b0c25a0080000 GS MOVQ GS:0x8a0, CX test2.go:3 0x2049 483b6110 CMPQ 0x10(CX), SP test2.go:3 0x204d 762a JBE 0x2079 test2.go:3 0x204f 4883ec10 SUBQ $0x10, SP test2.go:4 0x2053 488d1d66460500 LEAQ 0x54666(IP), BX test2.go:4 0x205a 48891c24 MOVQ BX, 0(SP) test2.go:4 0x205e e82d8f0000 CALL runtime.newobject(SB) test2.go:4 0x2063 488b442408 MOVQ 0x8(SP), AX test2.go:4 0x2068 48c70001000000 MOVQ $0x1, 0(AX) test2.go:5 0x206f 4889442418 MOVQ AX, 0x18(SP) test2.go:5 0x2074 4883c410 ADDQ $0x10, SP test2.go:5 0x2078 c3 RET test2.go:3 0x2079 e8a28d0400 CALL runtime.morestack_noctxt(SB) test2.go:3 0x207e ebc0 JMP main.foo(SB)堆上内存分配调用了 runtime 包的 newobject 函数。
func newobject(typ *_type) unsafe.Pointer { return mallocgc(typ.size, typ, true)}func mallocgc(size uintptr, typ *_type, needzero bool) unsafe.Pointer { ... c := gomcache() var x unsafe.Pointer noscan := typ == nil || typ.kind&kindNoPointers != 0 if size <= maxSmallSize { // object size <= 32K if noscan && size < maxTinySize { // 小于 16 byte 的小对象分配 off := c.tinyoffset // Align tiny pointer for required (conservative) alignment. if size&7 == 0 { off = round(off, 8) } else if size&3 == 0 { off = round(off, 4) } else if size&1 == 0 { off = round(off, 2) } if off+size <= maxTinySize && c.tiny != 0 { // The object fits into existing tiny block. x = unsafe.Pointer(c.tiny + off) c.tinyoffset = off + size c.local_tinyallocs++ mp.mallocing = 0 releasem(mp) return x } // Allocate a new maxTinySize block. span := c.alloc[tinySizeClass] v := nextFreeFast(span) if v == 0 { v, _, shouldhelpgc = c.nextFree(tinySizeClass) } x = unsafe.Pointer(v) (*[2]uint64)(x)[0] = 0 (*[2]uint64)(x)[1] = 0 // See if we need to replace the existing tiny block with the new one // based on amount of remaining free space. if size < c.tinyoffset || c.tiny == 0 { c.tiny = uintptr(x) c.tinyoffset = size } size = maxTinySize } else { // object size >= 16 byte && object size <= 32K byte var sizeclass uint8 if size <= smallSizeMax-8 { sizeclass = size_to_class8[(size+smallSizeDiv-1)/smallSizeDiv] } else { sizeclass = size_to_class128[(size-smallSizeMax+largeSizeDiv-1)/largeSizeDiv] } size = uintptr(class_to_size[sizeclass]) span := c.alloc[sizeclass] v := nextFreeFast(span) if v == 0 { v, span, shouldhelpgc = c.nextFree(sizeclass) } x = unsafe.Pointer(v) if needzero && span.needzero != 0 { memclrNoHeapPointers(unsafe.Pointer(v), size) } } } else { //object size > 32K byte var s *mspan shouldhelpgc = true systemstack(func() { s = largeAlloc(size, needzero) }) s.freeindex = 1 s.allocCount = 1 x = unsafe.Pointer(s.base()) size = s.elemsize }}整个分配过程可以根据 object size 拆解成三部分：size < 16 byte, 16 byte <= size <= 32 K byte, size > 32 K byte。
4.1 size 小于 16 byte
对于小于 16 byte 的内存块，mcache 有个专门的内存区域 tiny 用来分配，tiny 是指针，指向开始地址。
func mallocgc(...) { ... off := c.tinyoffset // 地址对齐 if size&7 == 0 { off = round(off, 8) } else if size&3 == 0 { off = round(off, 4) } else if size&1 == 0 { off = round(off, 2) } // 分配 if off+size <= maxTinySize && c.tiny != 0 { // The object fits into existing tiny block. x = unsafe.Pointer(c.tiny + off) c.tinyoffset = off + size c.local_tinyallocs++ mp.mallocing = 0 releasem(mp) return x } // tiny 不够了，为其重新分配一个 16 byte 内存块 span := c.alloc[tinySizeClass] v := nextFreeFast(span) if v == 0 { v, _, shouldhelpgc = c.nextFree(tinySizeClass) } x = unsafe.Pointer(v) //将申请的内存块全置为 0 (*[2]uint64)(x)[0] = 0 (*[2]uint64)(x)[1] = 0 // See if we need to replace the existing tiny block with the new one // based on amount of remaining free space. // 如果申请的内存块用不完，则将剩下的给 tiny，用 tinyoffset 记录分配了多少。 if size < c.tinyoffset || c.tiny == 0 { c.tiny = uintptr(x) c.tinyoffset = size } size = maxTinySize}如上所示，tinyoffset 表示 tiny 当前分配到什么地址了，之后的分配根据 tinyoffset 寻址。先根据要分配的对象大小进行地址对齐，比如 size 是 8 的倍数，tinyoffset 和 8 对齐。然后就是进行分配。如果 tiny 剩余的空间不够用，则重新申请一个 16 byte 的内存块，并分配给 object。如果有结余，则记录在 tiny 上。
4.2 size 大于 32 K byte
对于大于 32 Kb 的内存分配，直接跳过 mcache 和 mcentral，通过 mheap 分配。
func mallocgc(...) { } else { var s *mspan shouldhelpgc = true systemstack(func() { s = largeAlloc(size, needzero) }) s.freeindex = 1 s.allocCount = 1 x = unsafe.Pointer(s.base()) size = s.elemsize } ...}func largeAlloc(size uintptr, needzero bool) *mspan { ... npages := size >> _PageShift if size&_PageMask != 0 { npages++ } ... s := mheap_.alloc(npages, 0, true, needzero) if s == nil { throw("out of memory") } s.limit = s.base() + size heapBitsForSpan(s.base()).initSpan(s) return s}对于大于 32 K 的内存分配都是分配整数页，先右移然后低位与计算需要的页数。
4.3 size 介于 16 和 32K
对于 size 介于 16 ~ 32K byte 的内存分配先计算应该分配的 sizeclass，然后去 mcache 里面 alloc[sizeclass] 申请，如果 mcache.alloc[sizeclass] 不足以申请，则 mcache 向 mcentral 申请，然后再分配。mcentral 给 mcache 分配完之后会判断自己需不需要扩充，如果需要则想 mheap 申请。
func mallocgc(...) { ... } else { var sizeclass uint8 //计算 sizeclass if size <= smallSizeMax-8 { sizeclass = size_to_class8[(size+smallSizeDiv-1)/smallSizeDiv] } else { sizeclass = size_to_class128[(size-smallSizeMax+largeSizeDiv- 1)/largeSizeDiv] } size = uintptr(class_to_size[sizeclass]) span := c.alloc[sizeclass] //从对应的 span 里面分配一个 object v := nextFreeFast(span) if v == 0 { v, span, shouldhelpgc = c.nextFree(sizeclass) } x = unsafe.Pointer(v) if needzero && span.needzero != 0 { memclrNoHeapPointers(unsafe.Pointer(v), size) } }}我们首先看一下如何计算 sizeclass 的，预先定义了两个数组：size_to_class8 和 size_to_class128。 数组 size_to_class8，其第 i 个值表示地址区间 ( (i-1)*8, i*8 ] (smallSizeDiv = 8) 对应的 sizeclass，size_to_class128 类似。小于 1024 – 8 = 1016 (smallSizeMax=1024)，使用 size_to_class8，否则使用数组 size_to_class128。看一下数组具体的值：0, 1, 2, 3, 3, 4, 4…。举个例子，比如要分配 17 byte 的内存 (16 byte 以下的使用 mcache.tiny 分配)，sizeclass = size_to_calss8[(17+7)/8] = size_to_class8[3] = 3。不得不说这种用空间换时间的策略确实提高了运行效率。
计算出 sizeclass，那么就可以去 mcache.alloc[sizeclass] 分配了，注意这是一个 mspan 指针，真正的分配函数是 nextFreeFast() 函数。如下。
// nextFreeFast returns the next free object if one is quickly available.// Otherwise it returns 0.func nextFreeFast(s *mspan) gclinkptr { theBit := sys.Ctz64(s.allocCache) // Is there a free object in the allocCache? if theBit < 64 { result := s.freeindex + uintptr(theBit) if result < s.nelems { freeidx := result + 1 if freeidx%64 == 0 && freeidx != s.nelems { return 0 } s.allocCache >>= (theBit + 1) s.freeindex = freeidx v := gclinkptr(result*s.elemsize + s.base()) s.allocCount++ return v } } return 0}allocCache 这里是用位图表示内存是否可用，1 表示可用。然后通过 span 里面的 freeindex 和 elemsize 来计算地址即可。
如果 mcache.alloc[sizeclass] 已经不够用了，则从 mcentral 申请内存到 mcache。
// nextFree returns the next free object from the cached span if one is available.// Otherwise it refills the cache with a span with an available object and// returns that object along with a flag indicating that this was a heavy// weight allocation. If it is a heavy weight allocation the caller must// determine whether a new GC cycle needs to be started or if the GC is active// whether this goroutine needs to assist the GC.func (c *mcache) nextFree(sizeclass uint8) (v gclinkptr, s *mspan, shouldhelpgc bool) { s = c.alloc[sizeclass] shouldhelpgc = false freeIndex := s.nextFreeIndex() if freeIndex == s.nelems { // The span is full. if uintptr(s.allocCount) != s.nelems { println("runtime: s.allocCount=", s.allocCount, "s.nelems=", s.nelems) throw("s.allocCount != s.nelems && freeIndex == s.nelems") } systemstack(func() { // 这个地方 mcache 向 mcentral 申请 c.refill(int32(sizeclass)) }) shouldhelpgc = true s = c.alloc[sizeclass] // mcache 向 mcentral 申请完之后，再次从 mcache 申请 freeIndex = s.nextFreeIndex() } ...}// nextFreeIndex returns the index of the next free object in s at// or after s.freeindex.// There are hardware instructions that can be used to make this// faster if profiling warrants it.// 这个函数和 nextFreeFast 有点冗余了func (s *mspan) nextFreeIndex() uintptr { ...}mcache 向 mcentral，如果 mcentral 不够，则向 mheap 申请。func (c *mcache) refill(sizeclass int32) *mspan { ... // 向 mcentral 申请 s = mheap_.central[sizeclass].mcentral.cacheSpan() ... return s}// Allocate a span to use in an MCache.func (c *mcentral) cacheSpan() *mspan { ... // Replenish central list if empty. s = c.grow()}func (c *mcentral) grow() *mspan { npages := uintptr(class_to_allocnpages[c.sizeclass]) size := uintptr(class_to_size[c.sizeclass]) n := (npages << _PageShift) / size //这里想 mheap 申请 s := mheap_.alloc(npages, c.sizeclass, false, true) ... return s}如果 mheap 不足，则想 OS 申请。接上面的代码 mheap_.alloc()func (h *mheap) alloc(npage uintptr, sizeclass int32, large bool, needzero bool) *mspan { ... var s *mspan systemstack(func() { s = h.alloc_m(npage, sizeclass, large) }) ...}func (h *mheap) alloc_m(npage uintptr, sizeclass int32, large bool) *mspan { ... s := h.allocSpanLocked(npage) ...}func (h *mheap) allocSpanLocked(npage uintptr) *mspan { ... s = h.allocLarge(npage) if s == nil { if !h.grow(npage) { return nil } s = h.allocLarge(npage) if s == nil { return nil } } ...}func (h *mheap) grow(npage uintptr) bool { // Ask for a big chunk, to reduce the number of mappings // the operating system needs to track; also amortizes // the overhead of an operating system mapping. // Allocate a multiple of 64kB. npage = round(npage, (64<<10)/_PageSize) ask := npage << _PageShift if ask < _HeapAllocChunk { ask = _HeapAllocChunk } v := h.sysAlloc(ask) ...}整个函数调用链如上所示，最后 sysAlloc 会调用系统调用(mmap 或者 VirtualAlloc，和初始化那部分有点类似)去向操作系统申请。
5. 内存回收
这里只会介绍一些简单的内存回收，更详细的垃圾回收之后会单独写一篇文章来讲。
5.1 mcache 回收
mcache 回收可以分两部分：第一部分是将 alloc 中未用完的内存归还给对应的 mcentral。
func freemcache(c *mcache) { systemstack(func() { c.releaseAll() ... lock(&mheap_.lock) purgecachedstats(c) mheap_.cachealloc.free(unsafe.Pointer(c)) unlock(&mheap_.lock) })}func (c *mcache) releaseAll() { for i := 0; i < _NumSizeClasses; i++ { s := c.alloc[i] if s != &emptymspan { mheap_.central[i].mcentral.uncacheSpan(s) c.alloc[i] = &emptymspan } } // Clear tinyalloc pool. c.tiny = 0 c.tinyoffset = 0}函数 releaseAll() 负责将 mcache.alloc 中各个 sizeclass 中的 mspan 归还给 mcentral。这里需要注意的是归还给 mcentral 的时候需要加锁，因为 mcentral 是全局的。除此之外将剩下的 mcache (基本是个空壳)归还给 mheap.cachealloc，其实就是把 mcache 插入 free list 表头。
func (f *fixalloc) free(p unsafe.Pointer) { f.inuse -= f.size v := (*mlink)(p) v.next = f.list f.list = v}5.2 mcentral 回收
当 mspan 没有 free object 的时候，将 mspan 归还给 mheap。
func (c *mcentral) freeSpan(s *mspan, preserve bool, wasempty bool) bool { ... lock(&c.lock) ... if s.allocCount != 0 { unlock(&c.lock) return false } c.nonempty.remove(s) unlock(&c.lock) mheap_.freeSpan(s, 0) return true}5.3 mheap
mheap 并不会定时向操作系统归还，但是会对 span 做一些操作，比如合并相邻的 span。
6. 总结
tcmalloc 是一种理论，运用到实践中还要考虑工程实现的问题。学习 Golang 源码的过程中，除了知道它是如何工作的之外，还可以学习到很多有趣的知识，比如使用变量填充 CacheLine 避免 False Sharing，利用 debruijn 序列求解 Trailing Zero(在函数中 sys.Ctz64 使用)等等。我想这就是读源码的意义所在吧。
