图1 物理内存条

图2 计算机存储媒介金字塔模型

表1 硬盘与内存对比表

DDR3内存读写速度大概10G/s（10000M）	DDR4内存读写速度大概50G/s（50000M）
固态硬盘速度是300M/s，是内存的三十分之一	固态硬盘速度是300M/s，是内存的二百分之一
机械硬盘的速度是100M/s，是内存的百分之一	机械硬盘的速度是100M/s，是内存的五百分之一

    当存储的东西越来越多，也就发现物理内存的容量依然是不够用，那么对物理内存的利用率和合理的分配，管理就变得非常的重要。

    所以为了降低内存管理的难度，像C、C++这样的编程语言会完全将分配和回收内存的权限交给开发者，而Rust则是通过生命周期限定开发者对非法权限内存的访问来自动回收，因而并没有提供自动管理的一套机制。但是像Golang、Java、Python这类为了完全让开发则关注代码逻辑本身，语言层提供了一套管理模式。因为Golang编程语言给开发者提供了一套内存管理模式，所以开发者有必要了解一下Golang做了哪些助力的功能。

图3 物理内存布局

图4 物理内存分配的困局

    所谓虚拟，类似是假、凭空而造的大致意思。对比上图3.3所示的物理内存布局，虚拟内存的大致表现方式如图5所示。

图5 虚拟内存布局

图6 读时共享，写时复制

图7 虚拟内存从磁盘映射空间

图 8 MMU内存管理单元

1.页

2.页表

[1] PTE是Page Table Entry的缩写，表示页表条目。PTE是由一个有效位和N位地址字段构成，能够有效标识这个虚拟内存地址是否分配了物理内存。

图 9 页、页表、PTE之间的关系

图 10 PTE内部构造

[2]CPU每次访问虚拟内存，虚拟地址都必须转换为对应的物理地址。从概念上说，这个转换需要遍历页表，页表是三级页表，就需要3次内存访问。就是说，每次虚拟内存访问都会导致4次物理内存访问。简单点说，如果一次虚拟内存访问对应了4次物理内存访问，肯定比1次物理访问慢，这样虚拟内存肯定不会发展起来。幸运的是，有一个聪明的做法解决了大部分问题：现代CPU使用一小块关联内存，用来缓存最近访问的虚拟页的PTE。这块内存称为translation lookaside buffer(TLB)，参考《IA-64 Linux Kernel: Design and Implementation》

图 11 CPU、MMU与TLB的交互关系

    对于Golang开发者，对虚拟内存的存储结构了解到此步即可，如果想更深入的了解MMU存储结果可以翻阅其他操作系统或硬件相关书籍或资料。下面来分析一下在访问一次内存的整体流程。

图 12 CPU内存访问的详细流程

[3]一个虚拟地址VA（Virtual Address）= 虚拟页号VPN + 虚拟页偏移量VPO。

[4]一个物理地址PA（Physical Address）= 物理页号PPN * 页长度PageSize+ 物理页号偏移PPO（Physical Page Offset）

    上述了解到内存的命中率实际上是一衡量每次内存访问均能被页直接寻址到而不是产生缺页的指标。所以如果经常在一定范围内的内存则出现缺页的情况就会降低。这就是程序的一种局部性特性的体现。

package MyGolang
func Loop(nums []int, step int) {   l := len(nums)   for i := 0; i < step; i++ {      for j := i; j < l; j += step {         nums[j] = 4 //访问内存，并写入值      }   }}

func Loop(nums []int, step int) {   l := len(nums)   for j := 0; j < l; j += 1 {       nums[j] = 4 //访问内存，并写入值   }}

package MyGolang
import "testing"
func CreateSource(len int) []int {   nums := make([]int, 0, len)
   for i := 0 ; i < len; i++ {      nums = append(nums, i)   }
   return nums}

func BenchmarkLoopStep1(b *testing.B) {   //制作源数据，长度为10000   src := CreateSource(10000)
   b.ResetTimer()   for i:=0; i < b.N; i++ {      Loop(src, 1)   }}

func BenchmarkLoopStep2(b *testing.B) {   //制作源数据，长度为10000   src := CreateSource(10000)
   b.ResetTimer()   for i:=0; i < b.N; i++ {      Loop(src, 2)   }}
func BenchmarkLoopStep3(b *testing.B) {   //制作源数据，长度为10000   src := CreateSource(10000)
   b.ResetTimer()   for i:=0; i < b.N; i++ {      Loop(src, 3)   }}
func BenchmarkLoopStep4(b *testing.B) {   //制作源数据，长度为10000   src := CreateSource(10000)
   b.ResetTimer()   for i:=0; i < b.N; i++ {      Loop(src, 4)   }}
func BenchmarkLoopStep5(b *testing.B) {   //制作源数据，长度为10000   src := CreateSource(10000)
   b.ResetTimer()   for i:=0; i < b.N; i++ {      Loop(src, 5)   }}
func BenchmarkLoopStep6(b *testing.B) {   //制作源数据，长度为10000   src := CreateSource(10000)
   b.ResetTimer()   for i:=0; i < b.N; i++ {      Loop(src, 6)   }}
func BenchmarkLoopStep12(b *testing.B) {   //制作源数据，长度为10000   src := CreateSource(10000)
   b.ResetTimer()   for i:=0; i < b.N; i++ {      Loop(src, 12)   }}
func BenchmarkLoopStep16(b *testing.B) {   //制作源数据，长度为10000   src := CreateSource(10000)
   b.ResetTimer()   for i:=0; i < b.N; i++ {      Loop(src, 16)   }}

$ go test -bench=.  -count=3

goos: darwingoarch: amd64pkg: MyGolangBenchmarkLoopStep1-12            366787      2792 ns/opBenchmarkLoopStep1-12            432235      2787 ns/opBenchmarkLoopStep1-12            428527      2849 ns/opBenchmarkLoopStep2-12            374282      3282 ns/opBenchmarkLoopStep2-12            363969      3263 ns/opBenchmarkLoopStep2-12            361790      3315 ns/opBenchmarkLoopStep3-12            308587      3760 ns/opBenchmarkLoopStep3-12            311551      4369 ns/opBenchmarkLoopStep3-12            289584      4622 ns/opBenchmarkLoopStep4-12            275166      4921 ns/opBenchmarkLoopStep4-12            264282      4504 ns/opBenchmarkLoopStep4-12            286933      4869 ns/opBenchmarkLoopStep5-12            223366      5609 ns/opBenchmarkLoopStep5-12            202597      5655 ns/opBenchmarkLoopStep5-12            214666      5623 ns/opBenchmarkLoopStep6-12            187147      6344 ns/opBenchmarkLoopStep6-12            177363      6397 ns/opBenchmarkLoopStep6-12            185377      6333 ns/opBenchmarkLoopStep12-12           126860      9660 ns/opBenchmarkLoopStep12-12           127557      9741 ns/opBenchmarkLoopStep12-12           126658      9492 ns/opBenchmarkLoopStep16-12            95116     12754 ns/opBenchmarkLoopStep16-12            95175     12591 ns/opBenchmarkLoopStep16-12            92106     12533 ns/opPASSok  MyGolang31.712s

    本节介绍自主实现一个内存管理模块都大致需要哪些基础的开发和组件建设。接下来的一些代码不需要读者去掌握，因为Golang已经给开发者提供的内存管理模式，开发者不需要关心Golang的内存分配情况。但是为了更好的理解Golang的内存管理模型，需要了解如果自己实现一套简单的内存管理模块应该需要关注哪些点和需要实现哪些必要的模块和机制。

    因为Golang语言已经内置的内存管理机制，所以如果用Golang原生的语法结构如Slice、String、Map等都会自动触发Golang的内存管理机制。本案例为了介绍如何实现一个自我管理的内存模型，所以直接使用的C语言的malloc()、free()系统调用来开辟和释放内存空间，使用C语言的memcpy()、memmove()等进行内存的拷贝和移动。至于如何封装Golang语法的Malloc()、Free()、Memcpy()、Memmove()等函数，即是利用的Golang中的Cgo机制。

//zmem/c/memory.go
package c
/*#include <string.h>#include <stdlib.h> */import "C"import "unsafe"
func Malloc(size int) unsafe.Pointer {   return C.malloc(C.size_t(size))}
func Free(data unsafe.Pointer) {   C.free(data)}
func Memmove(dest, src unsafe.Pointer, length int) {   C.memmove(dest, src, C.size_t(length))}
func Memcpy(dest unsafe.Pointer, src []byte, length int) {   srcData := C.CBytes(src)   C.memcpy(dest, srcData, C.size_t(length))}

1.import“C”

2.unsafe.Pointer

#include <stdlib.h>
void *malloc(size_t size);

[5] Man 手册页（Manua pages，缩写man page）是在Linux操作系统在线软件文档的一种普遍形式。内容包括计算机程序库和系统调用等命令的帮助手册。

3.Golang与C的字符串等类型转换

// Go字符串转换为C字符串。C字符串使用malloc分配，因此需要使用C.free以避免内存泄露func C.CString(string) *C.char
// Go byte数组转换为C的数组。使用malloc分配的空间，因此需要使用C.free避免内存泄漏func C.CBytes([]byte) unsafe.Pointer
// C字符串转换为Go字符串func C.GoString(*C.char) string
// C字符串转换为Go字符串，指定转换长度func C.GoStringN(*C.char, C.int) string
// C数据转换为byte数组，指定转换的长度func C.GoBytes(unsafe.Pointer, C.int) []byte

func Memcpy(dest unsafe.Pointer, src []byte, length int) {   srcData := C.CBytes(src)   C.memcpy(dest, srcData, C.size_t(length))}

#include <string.h>
void *memcpy(void *dst, const void *src, size_t n);

package c_test
import (   "zmem/c"   "bytes"   "encoding/binary"   "fmt"   "testing"   "unsafe")
func IsLittleEndian() bool {   var n int32 = 0x01020304
   //下面是为了将int32类型的指针转换成byte类型的指针   u := unsafe.Pointer(&n)   pb := (*byte)(u)
   //取得pb位置对应的值   b := *pb
   //由于b是byte类型，最多保存8位，那么只能取得开始的8位   // 小端: 04 (03 02 01)   // 大端: 01 (02 03 04)   return (b == 0x04)}
func IntToBytes(n uint32) []byte {   x := int32(n)   bytesBuffer := bytes.NewBuffer([]byte{})
   var order binary.ByteOrder   if IsLittleEndian() {      order = binary.LittleEndian   } else {      order = binary.BigEndian   }   binary.Write(bytesBuffer, order, x)
   return bytesBuffer.Bytes()}
func TestMemoryC(t *testing.T) {   data := c.Malloc(4)   fmt.Printf(" data %+v, %T\n", data, data)   myData := (*uint32)(data)   *myData = 5   fmt.Printf(" data %+v, %T\n", *myData, *myData)
   var a uint32 = 100   c.Memcpy(data, IntToBytes(a), 4)   fmt.Printf(" data %+v, %T\n", *myData, *myData)
   c.Free(data)}

=== RUN   TestMemoryCdata 0x9d040a0, unsafe.Pointerdata 5, uint32data 100, uint32--- PASS: TestMemoryC (0.00s)PASS

    在zmem目录下再创建mem文件夹，包mem模块作为内存管理相关代码的包名，然后再mem目下面创建buf.go，作为Buf的代码实现。文件路径结构如下：

zmem/├── README.md├── c/│   ├── memory.go│   └── memory_test.go├── go.mod└── mem/└── buf.go

//zmem/mem/buf.go
package mem
import "unsafe"
type Buf struct {   //如果存在多个buffer，是采用链表的形式链接起来   Next *Buf   //当前buffer的缓存容量大小   Capacity int   //当前buffer有效数据长度   length int   //未处理数据的头部位置索引   head int   //当前buf所保存的数据地址   data unsafe.Pointer}

图 13 Buf的数据结构布局

//zmem/mem/buf.go
//构造，创建一个Buf对象func NewBuf(size int) *Buf {   return &Buf{      Capacity: size,      length: 0,      head: 0,      Next: nil,      data : c.Malloc(size),   }}

//zmem/mem/buf.go
//给一个Buf填充[]byte数据func (b *Buf) SetBytes(src []byte) {   c.Memcpy(unsafe.Pointer(uintptr(b.data)+uintptr(b.head)), src, len(src))   b.length += len(src)}

图 14 SetBytes内存操作

//zmem/mem/buf.go
//获取一个Buf的数据，以[]byte形式展现func (b *Buf) GetBytes() []byte {   data := C.GoBytes(unsafe.Pointer(uintptr(b.data)+uintptr(b.head)), C.int(b.length))   return data}

//zmem/mem/buf.go
//将其他Buf对象数据考本到自己中func (b *Buf) Copy(other *Buf) {   c.Memcpy(b.data, other.GetBytes(), other.length)   b.head = 0   b.length = other.length}

//zmem/mem/buf.go
//处理长度为len的数据，移动head和修正lengthfunc (b *Buf) Pop(len int) {   if b.data == nil {      fmt.Printf("pop data is nil")      return   }   if len > b.length {      fmt.Printf("pop len > length")      return   }   b.length -= len   b.head += len}

图 15 Pop内存操作的head与length偏移

//zmem/mem/buf.go
//将已经处理过的数据，清空,将未处理的数据提前至数据首地址func (b *Buf) Adjust() {   if b.head != 0 {      if (b.length != 0) {         c.Memmove(b.data, unsafe.Pointer(uintptr(b.data) + uintptr(b.head)), b.length)      }      b.head = 0   }}

图 16 Adjust操作的内存平移

//zmem/mem/buf.go
//清空数据func (b *Buf) Clear() {   b.length = 0   b.head = 0}//其他的提供的访问head和length的方法如下：func (b *Buf) Head() int {   return b.head}
func (b *Buf) Length() int {   return b.length}

//zmem/mem/buf_pool.gopackage mem
import (   "sync")
//内存管理池类型type Pool map[int] *Buf
//Buf内存池type BufPool struct {   //所有buffer的一个map集合句柄   Pool Pool   PoolLock sync.RWMutex
   //总buffer池的内存大小单位为KB   TotalMem uint64}

//zmem/mem/buf_pool.go
//单例对象var bufPoolInstance *BufPoolvar once sync.Once
//获取BufPool对象（单例模式）func MemPool() *BufPool{   once.Do(func() {      bufPoolInstance = new(BufPool)      bufPoolInstance.Pool = make(map[int]*Buf)      bufPoolInstance.TotalMem = 0      bufPoolInstance.prev = nil      bufPoolInstance.initPool()   })
   return bufPoolInstance}

图 17 BufPool内存池的内存管理布局

//zmem/mem/buf_pool.go
const (   m4K int = 4096   m16K int = 16384   m64K int = 655535   m256K int = 262144   m1M int = 1048576   m4M int = 4194304   m8M int = 8388608)
/*     初始化内存池主要是预先开辟一定量的空间  这里BufPool是一个hash，每个key都是不同空间容量  对应的value是一个Buf集合的链表
BufPool --> [m4K]  -- Buf-Buf-Buf-Buf...(BufList)              [m16K] -- Buf-Buf-Buf-Buf...(BufList)              [m64K] -- Buf-Buf-Buf-Buf...(BufList)              [m256K]-- Buf-Buf-Buf-Buf...(BufList)              [m1M] -- Buf-Buf-Buf-Buf...(BufList)              [m4M] -- Buf-Buf-Buf-Buf...(BufList)              [m8M] -- Buf-Buf-Buf-Buf...(BufList) */func (bp *BufPool) initPool() {   //----> 开辟4K buf 内存池   // 4K的Buf 预先开辟5000个，约20MB供开发者使用   bp.makeBufList(m4K, 5000)
   //----> 开辟16K buf 内存池   //16K的Buf 预先开辟1000个，约16MB供开发者使用   bp.makeBufList(m16K, 1000)
   //----> 开辟64K buf 内存池   //64K的Buf 预先开辟500个，约32MB供开发者使用   bp.makeBufList(m64K, 500)
   //----> 开辟256K buf 内存池   //256K的Buf 预先开辟200个，约50MB供开发者使用   bp.makeBufList(m256K, 200)
   //----> 开辟1M buf 内存池   //1M的Buf 预先开辟50个，约50MB供开发者使用   bp.makeBufList(m1M, 50)
   //----> 开辟4M buf 内存池   //4M的Buf 预先开辟20个，约80MB供开发者使用   bp.makeBufList(m4M, 20)
   //----> 开辟8M buf 内存池   //8M的io_buf 预先开辟10个，约80MB供开发者使用   bp.makeBufList(m8M, 10)}

其中makeBufList()为每次初始化一种刻度容量的Buf链表，代码实现如下：

//zmem/mem/buf_pool.go
func (bp *BufPool) makeBufList(cap int, num int) {   bp.Pool[cap] = NewBuf(cap)
   var prev *Buf   prev = bp.Pool[cap]   for i := 1; i < num; i ++ {      prev.Next = NewBuf(cap)      prev = prev.Next   }   bp.TotalMem += (uint64(cap)/1024) * uint64(num)}

1.获取Buf

//zmem/mem/buf_pool.go
package mem
import (   "errors"   "fmt"   "sync")


const (   //总内存池最大限制单位是Kb 所以目前限制是 5GB   EXTRA_MEM_LIMIT int = 5 * 1024 * 1024)
/*   开辟一个Buf*/func (bp *BufPool) Alloc(N int) (*Buf, error) {   //1 找到N最接近哪hash 组   var index int   if N <= m4K {      index = m4K   } else if (N <= m16K) {      index = m16K   } else if (N <= m64K) {      index = m64K   } else if (N <= m256K) {      index = m256K   } else if (N <= m1M) {      index = m1M   } else if (N <= m4M) {      index = m4M   } else if (N <= m8M) {      index = m8M   } else {      return nil, errors.New("Alloc size Too Large!");   }
   //2 如果该组已经没有，需要额外申请，那么需要加锁保护   bp.PoolLock.Lock()   if bp.Pool[index] == nil {      if (bp.TotalMem + uint64(index/1024)) >= uint64(EXTRA_MEM_LIMIT) {         errStr := fmt.Sprintf("already use too many memory!\n")         return nil, errors.New(errStr)      }
      newBuf := NewBuf(index)      bp.TotalMem += uint64(index/1024)      bp.PoolLock.Unlock()      fmt.Printf("Alloc Mem Size: %d KB\n", newBuf.Capacity/1024)      return newBuf, nil   }
   //3 如果有该组有Buf内存存在，那么得到一个Buf并返回，并且从pool中摘除该内存块   targetBuf := bp.Pool[index]   bp.Pool[index] = targetBuf.Next   bp.TotalMem -= uint64(index/1024)   bp.PoolLock.Unlock()   targetBuf.Next = nil   fmt.Printf("Alloc Mem Size: %d KB\n", targetBuf.Capacity/1024)   return targetBuf, nil}

2.退还Buf

//当Alloc之后，当前Buf被使用完，需要重置这个Buf,需要将该buf放回pool中func (bp *BufPool) Revert(buf *Buf) error {   //每个buf的容量都是固定的在hash的key中取值   index := buf.Capacity   //重置buf中的内置位置指针   buf.Clear()
   bp.PoolLock.Lock()   //找到对应的hash组 buf首届点地址   if _, ok := bp.Pool[index]; !ok {      errStr := fmt.Sprintf("Index %d not in BufPoll!\n", index)      return errors.New(errStr)   }
   //将buffer插回链表头部   buf.Next = bp.Pool[index]   bp.Pool[index] = buf   bp.TotalMem += uint64(index/1024)   bp.PoolLock.Unlock()   fmt.Printf("Revert Mem Size: %d KB\n",index/1024)
   return nil}

1.TestBufPoolSetGet

//zmem/mem/buf_test.go
package mem_test
import (   "zmem/mem"   "fmt"   "testing")
func TestBufPoolSetGet(t *testing.T) {   pool := mem.MemPool()
   buffer, err := pool.Alloc(1)   if err != nil {      fmt.Println("pool Alloc Error ", err)      return   }
   buffer.SetBytes([]byte("Aceld12345"))   fmt.Printf("GetBytes = %+v, ToString = %s\n", buffer.GetBytes(), string(buffer.GetBytes()))   buffer.Pop(4)   fmt.Printf("GetBytes = %+v, ToString = %s\n", buffer.GetBytes(), string(buffer.GetBytes()))}

$ go test -run TestBufPoolSetGetAlloc Mem Size: 4 KBGetBytes = [65 99 101 108 100 49 50 51 52 53], ToString = Aceld12345GetBytes = [100 49 50 51 52 53], ToString = d12345PASSok      zmem/mem        0.010s

2.TestBufPoolCopy

//zmem/mem/buf_test.go
package mem_test
import (   "zmem/mem"   "fmt"   "testing")
func TestBufPoolCopy(t *testing.T) {   pool := mem.MemPool()
   buffer, err := pool.Alloc(1)   if err != nil {      fmt.Println("pool Alloc Error ", err)      return   }
   buffer.SetBytes([]byte("Aceld12345"))   fmt.Printf("Buffer GetBytes = %+v\n", string(buffer.GetBytes()))
   buffer2, err := pool.Alloc(1)   if err != nil {      fmt.Println("pool Alloc Error ", err)      return   }   buffer2.Copy(buffer)   fmt.Printf("Buffer2 GetBytes = %+v\n", string(buffer2.GetBytes()))}

$ go test -run TestBufPoolCopyAlloc Mem Size: 4 KBBuffer GetBytes = Aceld12345Alloc Mem Size: 4 KBBuffer2 GetBytes = Aceld12345PASSok      zmem/mem        0.008s

3.TestBufPoolAdjust

//zmem/mem/buf_test.go
package mem_test
import (   "zmem/mem"   "fmt"   "testing")
func TestBufPoolAdjust(t *testing.T) {   pool := mem.MemPool()
   buffer, err := pool.Alloc(4096)   if err != nil {      fmt.Println("pool Alloc Error ", err)      return   }
   buffer.SetBytes([]byte("Aceld12345"))   fmt.Printf("GetBytes = %+v, Head = %d, Length = %d\n", buffer.GetBytes(), buffer.Head(), buffer.Length())   buffer.Pop(4)   fmt.Printf("GetBytes = %+v, Head = %d, Length = %d\n", buffer.GetBytes(), buffer.Head(), buffer.Length())   buffer.Adjust()   fmt.Printf("GetBytes = %+v, Head = %d, Length = %d\n", buffer.GetBytes(), buffer.Head(), buffer.Length())}

$ go test -run TestBufPoolAdjustAlloc Mem Size: 4 KBGetBytes = [65 99 101 108 100 49 50 51 52 53], Head = 0, Length = 10GetBytes = [100 49 50 51 52 53], Head = 4, Length = 6GetBytes = [100 49 50 51 52 53], Head = 0, Length = 6PASSok      zmem/mem        0.009s

    前面小结已经基本实现了一个简单的内存池管理，但如果希望更方便的使用，则需要对Buf和BufPool再做一层封装，这里定义新数据结构Zbuf，对Buf的基本操作做已经封装，使内存管理的接口更加友好，在zmem/mem/目录下创建zbuf.go文件，切定义数据类型Zbuf，具体代码如下：

//zmem/mem/zbuf.gopackage mem
//应用层的buffer数据type ZBuf struct {   b *Buf}

1.Clear()方法

//zmem/mem/zbuf.go
//清空当前的ZBuffunc (zb *ZBuf) Clear() {   if zb.b != nil {      //将Buf重新放回到buf_pool中      MemPool().Revert(zb.b)      zb.b = nil   }}

2.Pop()方法

//zmem/mem/zbuf.go
//弹出已使用的有效长度func (zb *ZBuf) Pop(len int) {   if zb.b == nil || len > zb.b.Length() {      return   }
   zb.b.Pop(len)
   //当此时Buf的可用长度已经为0时,将Buf重新放回BufPool中   if zb.b.Length() == 0 {      MemPool().Revert(zb.b)      zb.b = nil   }}

3.Data()方法

//zmem/mem/zbuf.go
//获取Buf中的数据func (zb *ZBuf) Data() []byte {   if zb.b == nil {      return nil   }   return zb.b.GetBytes()}

4.Adjust()方法

//zmem/mem/zbuf.go
//重置缓冲区func (zb *ZBuf) Adjust() {   if zb.b != nil {      zb.b.Adjust()   }}

5.Read()方法

//zmem/mem/zbuf.go
//读取数据到Buf中func (zb *ZBuf) Read(src []byte) (err error){   if zb.b == nil {      zb.b, err = MemPool().Alloc(len(src))      if err != nil {         fmt.Println("pool Alloc Error ", err)      }   } else {      if zb.b.Head() != 0 {         return nil      }      if zb.b.Capacity - zb.b.Length() < len(src) {         //不够存，重新从内存池申请         newBuf, err := MemPool().Alloc(len(src)+zb.b.Length())         if err != nil {            return nil         }         //将之前的Buf拷贝到新申请的Buf中去         newBuf.Copy(zb.b)         //将之前的Buf回收到内存池中         MemPool().Revert(zb.b)         //新申请的Buf成为当前的ZBuf         zb.b = newBuf      }   }
   //将内容写进ZBuf缓冲中   zb.b.SetBytes(src)
   return nil}

6.其他可拓展方法等

//zmem/mem/zbuf.go
//读取数据从Fd文件描述符中func (zb *ZBuf) ReadFromFd(fd int) error {   //...   return nil}
//将数据写入Fd文件描述符中func (zb *ZBuf) WriteToFd(fd int) error {   //...   return nil}
//读取数据从文件中func (zb *ZBuf) ReadFromFile(path string) error {   //...   return nil}
func (zb *ZBuf) WriteToFile(path string) error {   //...   return nil}
//读取数据从网络连接中func (zb *ZBuf) ReadFromConn(conn net.Conn) error {   //...   return nil}
func (zb *ZBuf) WriteToConn(conn net.Conn) error {   //...   return nil}

    在了解Golang的内存管理之前，一定要了解的基本申请内存模式，即TCMalloc（Thread Cache Malloc）。Golang的内存管理就是基于TCMalloc的核心思想来构建的。本节将介绍TCMalloc的基础理念和结构。

    TCMalloc最大优势就是每个线程都会独立维护自己的内存池。在之前章节介绍的自定义实现的Golang内存池版BufPool实则是所有Goroutine或者所有线程共享的内存池，其关系如图18所示。

图 18 BufPool内存池与线程Thread的关系

图 19 TCMalloc内存池与线程Thread的关系

    所以为了解决中对象和大对象的内存申请，TCMalloc依然有一个全局共享内存堆PageHeap，如图20所示。

图 20 TCMalloc中的PageHeap

    在链接TCMalloc的一些内部设计结构时，首要了解的是一些TCMalloc定义的基本名词Page、Span和Size Class。

1.Page

图 21 TCMalloc将虚拟内存平均分层N份Page

2.Span

图 22 TCMalloc中Page与Span的关系

图 23 TCMalloc中Span存储形式

3.Size Class

[6] TCMalloc官方文档称一共划分88个size-classes，“Each small object size maps to one of approximately 88 allocatable size-classes”，参考《TCMalloc : Thread-Caching Malloc》

图 24 TCMalloc中Size Class、Page、Span的结构关系

5.3 ThreadCache

图 25 TCMalloc中ThreadCache

5.4 CentralCache

图 26 TCMalloc中CentralCache

5.5 PageHeap

图 27 TCMalloc中PageHeap

5.6 TCMalloc的小对象分配

图 28 TCMalloc小对象分配流程

5.7 TCMalloc的中对象分配

图 29 TCMalloc中对象分配流程

5.8 TCMalloc的大对象分配

图 30 TCMalloc大对象分配流程

    本章节将介绍Golang的内存管理模型，看本章节之前强烈建议读者将上述章节均阅读理解完成，更有助于理解Golang的内存管理机制。

Golang内存管理模型的逻辑层次全景图，如图31所示。

图 31 Golang内存管理模块关系

    Golang内存管理中依然保留TCMalloc中的Page、Span、Size Class等概念。

1.Page

2.mSpan

3.Size Class相关

图 32 Object Size与Span的关系

图 33 Span Class与Size Class的逻辑结构关系

//usr/local/go/src/runtime/mheap.go
type spanClass uint8 
//……(省略部分代码)
func makeSpanClass(sizeclass uint8, noscan bool) spanClass {return spanClass(sizeclass<<1) | spanClass(bool2int(noscan))}
//……(省略部分代码)

//usr/local/go/src/runtime/sizeclasses.go

package runtime

// 标题Title解释：// [class]: Size Class// [bytes/obj]: Object Size，一次对外提供内存Object的大小// [bytes/span]: 当前Object所对应Span的内存大小// [objects]: 当前Span一共有多少个Object// [tail wastre]: 为当前Span平均分层N份Object，会有多少内存浪费// [max waste]: 当前Size Class最大可能浪费的空间所占百分比

// class  bytes/obj  bytes/span  objects  tail waste  max waste//     1          8        8192     1024           0        87.50%//     2         16        8192      512           0        43.75%//     3         32        8192      256           0        46.88%//     4         48        8192      170          32        31.52%//     5         64        8192      128           0        23.44%//     6         80        8192      102          32        19.07%//     7         96        8192       85          32        15.95%//     8        112        8192       73          16        13.56%//     9        128        8192       64           0        11.72%//    10        144        8192       56         128        11.82%//    11        160        8192       51          32        9.73%//    12        176        8192       46          96        9.59%//    13        192        8192       42         128        9.25%//    14        208        8192       39          80        8.12%//    15        224        8192       36         128        8.15%//    16        240        8192       34          32        6.62%//    17        256        8192       32           0        5.86%//    18        288        8192       28         128        12.16%//    19        320        8192       25         192        11.80%//    20        352        8192       23          96        9.88%//    21        384        8192       21         128        9.51%//    22        416        8192       19         288        10.71%//    23        448        8192       18         128        8.37%//    24        480        8192       17          32        6.82%//    25        512        8192       16           0        6.05%//    26        576        8192       14         128        12.33%//    27        640        8192       12         512        15.48%//    28        704        8192       11         448        13.93%//    29        768        8192       10         512        13.94%//    30        896        8192        9         128        15.52%//    31       1024        8192        8           0        12.40%//    32       1152        8192        7         128        12.41%//    33       1280        8192        6         512        15.55%//    34       1408       16384       11         896        14.00%//    35       1536        8192        5         512        14.00%//    36       1792       16384        9         256        15.57%//    37       2048        8192        4           0        12.45%//    38       2304       16384        7         256       12.46%//    39       2688        8192        3         128        15.59%//    40       3072       24576        8           0        12.47%//    41       3200       16384        5         384        6.22%//    42       3456       24576        7         384        8.83%//    43       4096        8192        2           0        15.60%//    44       4864       24576        5         256        16.65%//    45       5376       16384        3         256        10.92%//    46       6144       24576        4           0        12.48%//    47       6528       32768        5         128        6.23%//    48       6784       40960        6         256        4.36%//    49       6912       49152        7         768        3.37%//    50       8192        8192        1           0        15.61%//    51       9472       57344        6         512        14.28%//    52       9728       49152        5         512        3.64%//    53      10240       40960        4           0        4.99%//    54      10880       32768        3         128        6.24%//    55      12288       24576        2           0        11.45%//    56      13568       40960        3         256        9.99%//    57      14336       57344        4           0        5.35%//    58      16384       16384        1           0        12.49%//    59      18432       73728        4           0        11.11%//    60      19072       57344        3         128        3.57%//    61      20480       40960        2           0        6.87%//    62      21760       65536        3         256        6.25%//    63      24576       24576        1           0        11.45%//    64      27264       81920        3         128        10.00%//    65      28672       57344        2           0        4.91%//    66      32768       32768        1           0        12.50%

下面分别解释一下每一列的含义：

[7] 参考Golang 1.14版本，其中还有扩展到128个size class的对应关系，本书不详细介绍，具体细节参考Golang源码/usr/local/go/src/runtime/sizeclasses.go文件。

图 34 Max Waste最大浪费空间计算公式

// class  bytes/obj  bytes/span  objects  tail waste  max waste
// … …//     6         80        8192      102          32        19.07%//     7         96        8192       85          32        15.95%// … …

(本级Object Size – (上级Object Size + 1)*本级Object数量) / 本级Span Size

图 35 ThreadCache与mcache的绑定关系区别

图 36 MCache内部构造

//usr/local/go/src/runtime/malloc.go
// Al Allocate an object of size bytes.                                     // Sm Small objects are allocated from the per-P cache's free lists.        // La Large objects (> 32 kB) are allocated straight from the heap.         func mallocgc(size uintptr, typ *_type, needzero bool) unsafe.Pointer {                        // ……（省略部分代码）
if size == 0 {return unsafe.Pointer(&zerobase)}
//……（省略部分代码）}

//第一篇/chapter3/MyGolang/zeroBase.gopackage main
import (  "fmt")
func main() {  var (    //0内存对象    a struct{}    b [0]int
    //100个0内存struct{}    c [100]struct{}
    //100个0内存struct{},make申请形式    d = make([]struct{}, 100)  )
  fmt.Printf("%p\n", &a)  fmt.Printf("%p\n", &b)  fmt.Printf("%p\n", &c[50])    //取任意元素  fmt.Printf("%p\n", &(d[50]))  //取任意元素}

$ go run zeroBase.go 0x11aac780x11aac780x11aac780x11aac78

    MCentral与TCMalloc中的Central概念依然相似。向MCentral申请Span是同样是需要加锁的。当MCache中某个Size Class对应的Span被一次次Object被上层取走后，如果出现当前Size Class的Span空缺情况，MCache则会向MCentral申请对应的Span。Goroutine、MCache、MCentral、MHeap互相交换的内存单位是不同，具体如图37所示。

图 37 Golang内存管理各层级内存交换单位

图 38 MCentral的内部构造

//usr/local/go/src/runtime/mcentral.go  , Go V1.14
// Central list of free objects of a given size.// go:notinheaptype mcentral struct {  lock      mutex      //申请MCentral内存分配时需要加的锁
  spanclass spanClass //当前哪个Size Class级别的
  // list of spans with a free object, ie a nonempty free list  // 还有可用空间的Span 链表  nonempty  mSpanList 
  // list of spans with no free objects (or cached in an mcache)  // 没有可用空间的Span链表，或者当前链表里的Span已经交给mcache  empty     mSpanList 
  // nmalloc is the cumulative count of objects allocated from  // this mcentral, assuming all spans in mcaches are  // fully-allocated. Written atomically, read under STW.  // nmalloc是从该mcentral分配的对象的累积计数  // 假设mcaches中的所有跨度都已完全分配。  // 以原子方式书写，在STW下阅读。  nmalloc uint64}

//usr/local/go/src/runtime/mcentral.go  , Go V1.16+
//…
type mcentral struct {  // mcentral对应的spanClass  spanclass spanClass
  partial  [2]spanSet // 维护全部空闲的Span集合  full     [2]spanSet // 维护存在非空闲的Span集合}
//…

图 39 MHeap内部逻辑层级构造

[7] 在Linux64位操作系统上。

图 40 MHeap数据结构引用依赖

    在之前章节的表3-4中可以得到TCMalloc将对象分为了小对象、中对象、和大对象，而Golang内存管理将对象的分类进行了更细的一些划分，具体的划分区别对比如表6所示。

    针对Tiny微小对象的分配，实际上Golang做了比较特殊的处理，之前在介绍MCache的时候并没有提及有关Tiny的存储和分配问题，MCache中不仅保存着各个Span Class级别的内存块空间，还有一个比较特殊的Tiny存储空间，如图41所示。

图 41 MCache中的Tiny空间

图 42 如果微小对象不存在Tiny空间中

图 43 MCache中Tiny微小对象分配流程

图 44 不用Tiny缓冲存储情况

    上节已经介绍了分配在1B至16B的Tiny对象的分配流程，那么对于对象在16B至32B的内存分配，Golang会采用小对象的分配流程。

图 45 Golang小对象内存分配流程

    小对象是在MCache中分配的，而大对象是直接从MHeap中分配。对于不满足MCache分配范围的对象，均是按照大对象分配流程处理。

图 46 Golang大对象内存分配流程

推荐阅读

• 看Go中的struct如何被优化，还有小插曲