【Go学习】Go内存管理与并发控制

内存管理

内存分配原理

1. 前言

编写过C语言程序的肯定知道通过malloc()方法动态申请内存，其中内存分配器使用的是glibc提供的ptmalloc2。
除了glibc，业界比较出名的内存分配器有Google的tcmalloc和Facebook的jemalloc。二者在避免内存碎片和性能上均比glibc有比较大的优势，在多线程环境中效果更明显。

Golang中也实现了内存分配器，原理与tcmalloc类似，简单的说就是维护一块大的全局内存，每个线程(Golang中为P)维护一块小的私有内存，私有内存不足再从全局申请。

另外，内存分配与GC（垃圾回收）关系密切，所以了解GC前有必要了解内存分配的原理。

2. 基础概念

为了方便自主管理内存，做法便是先向系统申请一块内存，然后将内存切割成小块，通过一定的内存分配算法管理内存。
以64位系统为例，Golang程序启动时会向系统申请的内存如下图所示：

预申请的内存划分为spans、bitmap、arena三部分。其中arena即为所谓的堆区，应用中需要的内存从这里分配。其中spans和bitmap是为了管理arena区而存在的。

arena的大小为512G，为了方便管理把arena区域划分成一个个的page，每个page为8KB,一共有512GB/8KB个页；

spans区域存放span的指针，每个指针对应一个或多个page，所以span区域的大小为(512GB/8KB)*指针大小8byte = 512M

bitmap区域大小也是通过arena计算出来，不过主要用于GC。

2.1 span

span是用于管理arena页的关键数据结构，每个span中包含1个或多个连续页，为了满足小对象分配，span中的一页会划分更小的粒度，而对于大对象比如超过页大小，则通过多页实现。

2.1.1 class

根据对象大小，划分了一系列class，每个class都代表一个固定大小的对象，以及每个span的大小。如下表所示：

上表中每列含义如下：

• class： class ID，每个span结构中都有一个class ID, 表示该span可处理的对象类型

• bytes/obj：该class代表对象的字节数

• bytes/span：每个span占用堆的字节数，也即页数*页大小

• objects: 每个span可分配的对象个数，也即（bytes/spans）/（bytes/obj）

• waste bytes: 每个span产生的内存碎片，也即（bytes/spans）%（bytes/obj）

上表可见最大的对象是32K大小，超过32K大小的由特殊的class表示，该class ID为0，每个class只包含一个对象。

2.1.2 span数据结构

span是内存管理的基本单位，每个span用于管理特定的class对象，根据对象大小，span将一个或多个页拆分成多个块进行管理。

src/runtime/mheap.go:mspan定义了其数据结构：

以class 10为例，span和管理的内存如下图所示：

spanclass为10，参照class表可得出npages=1,nelems=56,elemsize为144。其中startAddr是在span初始化时就指定了某个页的地址。allocBits指向一个位图，每位代表一个块是否被分配，本例中有两个块已经被分配，其allocCount也为2。

next和prev用于将多个span链接起来，这有利于管理多个span，接下来会进行说明。

2.2 cache

有了管理内存的基本单位span，还要有个数据结构来管理span，这个数据结构叫mcentral，各线程需要内存时从mcentral管理的span中申请内存，为了避免多线程申请内存时不断地加锁，Golang为每个线程分配了span的缓存，这个缓存即是cache。

src/runtime/mcache.go:mcache定义了cache的数据结构：

type mcache struct {
    
         
    alloc [67*2]*mspan // 按class分组的mspan列表 
    }

alloc为mspan的指针数组，数组大小为class总数的2倍。数组中每个元素代表了一种class类型的span列表，每种class类型都有两组span列表，第一组列表中所表示的对象中包含了指针，第二组列表中所表示的对象不含有指针，这么做是为了提高GC扫描性能，对于不包含指针的span列表，没必要去扫描。

根据对象是否包含指针，将对象分为noscan和scan两类，其中noscan代表没有指针，而scan则代表有指针，需要GC进行扫描。

mcache和span的对应关系如下图所示：

mcache在初始化时是没有任何span的，在使用过程中会动态地从central中获取并缓存下来，根据使用情况，每种class的span个数也不相同。上图所示，class 0的span数比class1的要多，说明本线程中分配的小对象要多一些。

2.3 central

cache作为线程的私有资源为单个线程服务，而central则是全局资源，为多个线程服务，当某个线程内存不足时会向central申请，当某个线程释放内存时又会回收进central。

src/runtime/mcentral.go:mcentral定义了central数据结构：

type mcentral struct {
    
    
    lock      mutex     //互斥锁
    spanclass spanClass // span class ID
    nonempty  mSpanList // non-empty 指还有空闲块的span列表
    empty     mSpanList // 指没有空闲块的span列表

    nmalloc uint64      // 已累计分配的对象个数
}

• lock: 线程间互斥锁，防止多线程读写冲突

• spanclass : 每个mcentral管理着一组有相同class的span列表

• nonempty: 指还有内存可用的span列表

• empty: 指没有内存可用的span列表

• nmalloc: 指累计分配的对象个数

线程从central获取span步骤如下：

1. 加锁

2. 从nonempty列表获取一个可用span，并将其从链表中删除

3. 将取出的span放入empty链表

4. 将span返回给线程

5. 解锁

6. 线程将该span缓存进cache

线程将span归还步骤如下：

1. 加锁

2. 将span从empty列表删除

3. 将span加入noneempty列表

4. 解锁

上述线程从central中获取span和归还span只是简单流程，为简单起见，并未对具体细节展开。

2.4 heap

从mcentral数据结构可见，每个mcentral对象只管理特定的class规格的span。事实上每种class都会对应一个mcentral,这个mcentral的集合存放于mheap数据结构中。

src/runtime/mheap.go:mheap定义了heap的数据结构：

type mheap struct {
    
    
    lock      mutex

    spans []*mspan

    bitmap        uintptr     //指向bitmap首地址，bitmap是从高地址向低地址增长的

    arena_start uintptr        //指示arena区首地址
    arena_used  uintptr        //指示arena区已使用地址位置

    central [67*2]struct {
    
    
        mcentral mcentral
        pad      [sys.CacheLineSize - unsafe.Sizeof(mcentral{
    
    })%sys.CacheLineSize]byte
    }
}

• lock： 互斥锁

• spans: 指向spans区域，用于映射span和page的关系

• bitmap：bitmap的起始地址

• arena_start: arena区域首地址

• arena_used: 当前arena已使用区域的最大地址

• central: 每种class对应的两个mcentral

从数据结构可见，mheap管理着全部的内存，事实上Golang就是通过一个mheap类型的全局变量进行内存管理的。

mheap内存管理示意图如下：

系统预分配的内存分为spans、bitmap、arean三个区域，通过mheap管理起来。接下来看内存分配过程。

3. 内存分配过程

针对待分配对象的大小不同有不同的分配逻辑：

• (0, 16B) 且不包含指针的对象： Tiny分配

• (0, 16B) 包含指针的对象：正常分配

• [16B, 32KB] : 正常分配

• (32KB, -) : 大对象分配
  其中Tiny分配和大对象分配都属于内存管理的优化范畴，这里暂时仅关注一般的分配方法。

以申请size为n的内存为例，分配步骤如下：

1. 获取当前线程的私有缓存mcache

2. 根据size计算出适合的class的ID

3. 从mcache的alloc[class]链表中查询可用的span

4. 如果mcache没有可用的span则从mcentral申请一个新的span加入mcache中

5. 如果mcentral中也没有可用的span则从mheap中申请一个新的span加入mcentral

6. 从该span中获取到空闲对象地址并返回

4. 总结

Golang内存分配是个相当复杂的过程，其中还掺杂了GC的处理，这里仅仅对其关键数据结构进行了说明，了解其原理而又不至于深陷实现细节。

1. Golang程序启动时申请一大块内存，并划分成spans、bitmap、arena区域

2. arena区域按页划分成一个个小块

3. span管理一个或多个页

4. mcentral管理多个span供线程申请使用

5. mcache作为线程私有资源，资源来源于mcentral

垃圾回收原理

1. 前言

所谓垃圾就是不再需要的内存块，这些垃圾如果不清理就没办法再次被分配使用，在不支持垃圾回收的编程语言里，这些垃圾内存就是泄露的内存。

Golang的垃圾回收（GC）也是内存管理的一部分，了解垃圾回收最好先了解前面介绍的内存分配原理。

2. 垃圾回收算法

业界常见的垃圾回收算法有以下几种：

• 引用计数：对每个对象维护一个引用计数，当引用该对象的对象被销毁时，引用计数减1，当引用计数器为0时回收该对象。

• • 优点：对象可以很快地被回收，不会出现内存耗尽或达到某个阀值时才回收。
  • 缺点：不能很好地处理循环引用，而且实时维护引用计数，也有一定的代价。
• • 代表语言：Python、PHP、Swift

• 标记-清除：从根变量开始遍历所有引用的对象，引用的对象标记为”被引用”，没有被标记的进行回收。

• • 优点：解决了引用计数的缺点。
  • 缺点：需要STW，即要暂时停掉程序运行。
• • 代表语言：Golang（其采用三色标记法）

• 分代收集：按照对象生命周期长短划分不同的代空间，生命周期长的放入老年代，而短的放入新生代，不同代有不同的回收算法和回收频率。

• • 优点：回收性能好
  • 缺点：算法复杂
• • 代表语言： JAVA

3. Golang垃圾回收

3.1 垃圾回收原理

简单的说，垃圾回收的核心就是标记出哪些内存还在使用中（即被引用到），哪些内存不再使用了（即未被引用），把未被引用的内存回收掉，以供后续内存分配时使用。

下图展示了一段内存，内存中既有已分配掉的内存，也有未分配的内存，垃圾回收的目标就是把那些已经分配的但没有对象引用的内存找出来并回收掉：

上图中，内存块1、2、4号位上的内存块已被分配（数字1代表已被分配，0 未分配）。变量a, b为一指针，指向内存的1、2号位。内存块的4号位曾经被使用过，但现在没有任何对象引用了，就需要被回收掉。

垃圾回收开始时从root对象开始扫描，把root对象引用的内存标记为”被引用”，考虑到内存块中存放的可能是指针，所以还需要递归的进行标记，全部标记完成后，只保留被标记的内存，未被标记的全部标识为未分配即完成了回收。

3.2 内存标记(Mark)

前面介绍内存分配时，介绍过span数据结构，span中维护了一个个内存块，并由一个位图allocBits表示每个内存块的分配情况。在span数据结构中还有另一个位图gcmarkBits用于标记内存块被引用情况。

如上图所示，allocBits记录了每块内存分配情况，而gcmarkBits记录了每块内存标记情况。标记阶段对每块内存进行标记，有对象引用的的内存标记为1(如图中灰色所示)，没有引用到的保持默认为0.

allocBits和gcmarkBits数据结构是完全一样的，标记结束就是内存回收，回收时将allocBits指向gcmarkBits，则代表标记过的才是存活的，gcmarkBits则会在下次标记时重新分配内存，非常的巧妙。

3.3 三色标记法

前面介绍了对象标记状态的存储方式，还需要有一个标记队列来存放待标记的对象，可以简单想象成把对象从标记队列中取出，将对象的引用状态标记在span的gcmarkBits，把对象引用到的其他对象再放入队列中。

三色只是为了叙述上方便抽象出来的一种说法，实际上对象并没有颜色之分。这里的三色，对应了垃圾回收过程中对象的三种状态：

• 灰色：对象还在标记队列中等待

• 黑色：对象已被标记，gcmarkBits对应的位为1（该对象不会在本次GC中被清理）

• 白色：对象未被标记，gcmarkBits对应的位为0（该对象将会在本次GC中被清理）

例如，当前内存中有A~F一共6个对象，根对象a,b本身为栈上分配的局部变量，根对象a、b分别引用了对象A、B, 而B对象又引用了对象D，则GC开始前各对象的状态如下图所示:

初始状态下所有对象都是白色的。

接着开始扫描根对象a、b:

由于根对象引用了对象A、B,那么A、B变为灰色对象，接下来就开始分析灰色对象，分析A时，A没有引用其他对象很快就转入黑色，B引用了D，则B转入黑色的同时还需要将D转为灰色，进行接下来的分析。如下图所示：

上图中灰色对象只有D，由于D没有引用其他对象，所以D转入黑色。标记过程结束：

最终，黑色的对象会被保留下来，白色对象会被回收掉。

3.4 Stop The World

印度电影《苏丹》中有句描述摔跤的一句台词是：“所谓摔跤，就是把对手控制住，然后摔倒他。”

对于垃圾回收来说，回收过程中也需要控制住内存的变化，否则回收过程中指针传递会引起内存引用关系变化，如果错误的回收了还在使用的内存，结果将是灾难性的。

Golang中的STW（Stop The World）就是停掉所有的goroutine，专心做垃圾回收，待垃圾回收结束后再恢复goroutine。

STW时间的长短直接影响了应用的执行，时间过长对于一些web应用来说是不可接受的，这也是广受诟病的原因之一。

为了缩短STW的时间，Golang不断优化垃圾回收算法，这种情况得到了很大的改善。

4. 垃圾回收优化

4.1 写屏障(Write Barrier)

前面说过STW目的是防止GC扫描时内存变化而停掉goroutine，而写屏障就是让goroutine与GC同时运行的手段。虽然写屏障不能完全消除STW，但是可以大大减少STW的时间。

写屏障类似一种开关，在GC的特定时机开启，开启后指针传递时会把指针标记，即本轮不回收，下次GC时再确定。

GC过程中新分配的内存会被立即标记，用的并不是写屏障技术，也即GC过程中分配的内存不会在本轮GC中回收。

4.2 辅助GC(Mutator Assist)

为了防止内存分配过快，在GC执行过程中，如果goroutine需要分配内存，那么这个goroutine会参与一部分GC的工作，即帮助GC做一部分工作，这个机制叫作Mutator Assist。

5. 垃圾回收触发时机

5.1 内存分配量达到阀值触发GC

每次内存分配时都会检查当前内存分配量是否已达到阀值，如果达到阀值则立即启动GC。

阀值 = 上次GC内存分配量 * 内存增长率

内存增长率由环境变量GOGC控制，默认为100，即每当内存扩大一倍时启动GC。

5.2 定期触发GC

默认情况下，最长2分钟触发一次GC，这个间隔在src/runtime/proc.go:forcegcperiod变量中被声明：

// forcegcperiod is the maximum time in nanoseconds between garbage // collections. If we go this long without a garbage collection, one // is forced to run. // // This is a variable for testing purposes. It normally doesn’t change. var forcegcperiod int64 = 2 * 60 * 1e9

5.3 手动触发

程序代码中也可以使用runtime.GC()来手动触发GC。这主要用于GC性能测试和统计。

6. GC性能优化

GC性能与对象数量负相关，对象越多GC性能越差，对程序影响越大。

所以GC性能优化的思路之一就是减少对象分配个数，比如对象复用或使用大对象组合多个小对象等等。

另外，由于内存逃逸现象，有些隐式的内存分配也会产生，也有可能成为GC的负担。

关于GC性能优化的具体方法，后面单独介绍。

并发控制

Channel

1. 前言

channel一般用于协程之间的通信，channel也可以用于并发控制。比如主协程启动N个子协程，主协程等待所有子协程退出后再继续后续流程，这种场景下channel也可轻易实现。

3. 总结

使用channel来控制子协程的优点是实现简单，缺点是当需要大量创建协程时就需要有相同数量的channel，而且对于子协程继续派生出来的协程不方便控制。

后面继续介绍的WaitGroup、Context看起来比channel优雅一些，在各种开源组件中使用频率比channel高得多。

WaitGroup

1 前言

WaitGroup是Golang应用开发过程中经常使用的并发控制技术。

WaitGroup，可理解为Wait-Goroutine-Group，即等待一组goroutine结束。比如某个goroutine需要等待其他几个goroutine全部完成，那么使用WaitGroup可以轻松实现。

其实WaitGroup也可以实现一组goroutine等待另一组goroutine，这有点像玩杂技，很容出错，如果不了解其实现原理更是如此。实际上，WaitGroup的实现源码非常简单。

2 基础知识

2.1 信号量

信号量是Unix系统提供的一种保护共享资源的机制，用于防止多个线程同时访问某个资源。

可简单理解为信号量为一个数值：

• 当信号量>0时，表示资源可用，获取信号量时系统自动将信号量减1；
• 当信号量==0时，表示资源暂不可用，获取信号量时，当前线程会进入睡眠，当信号量为正时被唤醒；

由于WaitGroup实现中也使用了信号量，在此做个简单介绍。

3 WaitGroup

3.1 数据结构

源码包中src/sync/waitgroup.go:WaitGroup定义了其数据结构：

type WaitGroup struct {
    
    
    state1 [3]uint32
}

state1是个长度为3的数组，其中包含了state和一个信号量，而state实际上是两个计数器：

• counter： 当前还未执行结束的goroutine计数器

• waiter count: 等待goroutine-group结束的goroutine数量，即有多少个等候者

• semaphore: 信号量

考虑到字节是否对齐，三者出现的位置不同，为简单起见，依照字节已对齐情况下，三者在内存中的位置如下所示：

WaitGroup对外提供三个接口：

• Add(delta int): 将delta值加到counter中

• Wait()： waiter递增1，并阻塞等待信号量semaphore

• Done()： counter递减1，按照waiter数值释放相应次数信号量

下面分别介绍这三个函数的实现细节。

3.2 Add(delta int)

Add()做了两件事，一是把delta值累加到counter中，因为delta可以为负值，也就是说counter有可能变成0或负值，所以第二件事就是当counter值变为0时，根据waiter数值释放等量的信号量，把等待的goroutine全部唤醒，如果counter变为负值，则panic.

3.3 Wait()

Wait()方法也做了两件事，一是累加waiter, 二是阻塞等待信号量

3.4 Done()

Done()只做一件事，即把counter减1，我们知道Add()可以接受负值，所以Done实际上只是调用了Add(-1)。

源码如下：

func (wg *WaitGroup) Done() { wg.Add(-1) }

Done()的执行逻辑就转到了Add()，实际上也正是最后一个完成的goroutine把等待者唤醒的。

4 小结

简单说来，WaitGroup通常用于等待一组“工作协程”结束的场景，其内部维护两个计数器，这里把它们称为“工作协程”计数器和“坐等协程”计数器，
WaitGroup对外提供的三个方法分工非常明确：

• Add(delta int)方法用于增加“工作协程”计数，通常在启动新的“工作协程”之前调用；

• Done()方法用于减少“工作协程”计数，每次调用递减1，通常在“工作协程”内部且在临近返回之前调用；

• Wait()方法用于增加“坐等协程”计数，通常在所有”工作协程”全部启动之后调用；

Done()方法除了负责递减“工作协程”计数以外，还会在“工作协程”计数变为0时检查“坐等协程”计数器并把“坐等协程”唤醒。
需要注意的是，Done()方法递减“工作协程”计数后，如果“工作协程”计数变成负数时，将会触发panic，这就要求Add()方法调用要早于Done()方法。

此外，通过Add()方法累加的“工作协程”计数要与实际需要等待的“工作协程”数量一致，否则也会触发panic。
当“工作协程”计数多于实际需要等待的“工作协程”数量时，“坐等协程”可能会永远无法被唤醒而产生列锁，此时，Go运行时检测到死锁会触发panic,
当“工作协程”计数小于实际需要等待的“工作协程”数量时，Done()会在“工作协程”计数变为负数时触发panic。

答疑资料qq群:1007576722