接口类型是Golang中是一种非常非常常见的数据类型，每个开发人员都很有必要知道它到底是如何使用的，如果了解了它的底层实现就对开发就更有帮助了。

接口的定义

在Golang中 interface 通常是指实现了一 组抽象方法的集合，它提供了一种无侵入式的方式。当你实现了一个接口中指定的所有方法的时候，那么就实现了这个接口，在Golang中对它的实现并不需要 implements 关键字。

有时候我们称这种模型叫做鸭子模型（Duck typing），维基百科对鸭子模型的定义是

”If it looks like a duck, swims like a duck, and quacks like a duck, then it probably is a duck.“

翻译过来就是 ”如果它看起来像鸭子，像鸭子一样游泳，像鸭子一样嘎嘎叫，那他就可以认为是鸭子“。

Go 不同版本之间interface的结构可能不太一样，但整体都差不多，这里使用的Go版本为 1.15.6。

数据结构

Go 中 interface 在运行时可分 eface 和 iface 两种数据结构，我们先看一下对它们的定义：

一种是 eface， 表示空接口，指未包含任何方法的接口。如定义一个变量 var x interface{}，还有我们经常使用的标准库中的 func Println(a ...interface{}) (n int, err error) {} 都必于 eface 类型，标准库中有许多这类的接口。

另一种是 iface，表示包含至少一个方法的接口。

根据两者的定义可知 iface 是 eface 的一个子集，那么为什么不直接使用eface呢? 主要原因还是为了做一些性能优化。

Go Runtime 在启动程序的时候，会创建一个独立的 M 作为监控线程，称为 sysmon，它是一个系统级的 daemon 线程。这个sysmon 独立于 GPM 之外，也就是说不需要P就可以运行，因此官方工具 go tool trace 是无法追踪分析到此线程（ 源码）。sysmon

在程序执行期间 sysmon 每隔 20us~10ms 轮询执行一次（ 源码），监控那些长时间运行的 G 任务, 然后设置其可以被强占的标识符，这样别的 Goroutine 就可以抢先进来执行。

// src/runtime/proc.go

// 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

// Always runs without a P, so write barriers are not allowed.
//
//go:nowritebarrierrec
func sysmon() {
	......

	for {
		if idle == 0 { // start with 20us sleep...
			delay = 20
		} else if idle > 50 { // start doubling the sleep after 1ms...
			delay *= 2
		}
		if delay > 10*1000 { // up to 10ms
			delay = 10 * 1000
		}
		usleep(delay)

		......
	}

	......
}

说明一下，在 sysmon() 函数里有一个[sched](https://github.com/golang/go/blob/go1.15.6/src/runtime/runtime2.go#L1041) 变量，这个是全局变量，它是整个调度器调度必须使用的一个全局变量，对应结构体为 [schedt](https://github.com/golang/go/blob/go1.15.6/src/runtime/runtime2.go#L698-L781), 对应字段注释我们 golang中G、P、M 和 sched 三者的数据结构 文章里已介绍过。

在上篇 《golang中G、P、M 和 sched 三者的数据结构》文章中，我们介绍了G、M 和 P 的数据结构，其中M结构体中第一个字段是 g0，这个字段也是一个 goroutine，但和普通的 goroutine 有一些区别，它主要用来实现对 goroutine 进行调度，下面我们将介绍它是如何实现调度goroutine的。

另外还有一个 m0 , 它是一个全局变量，与 g0 的区别如下M0 与 g0的区别

本文主要翻译自 Go: g0, Special Goroutine 一文，有兴趣的可以查阅原文，作者有一系列高质量的文章推荐大家都阅读一遍。ℹ️ 本文基于 Go 1.13。

我们知道在Golang中所有的goroutine的运行都是由调度器来负责管理的，go调度器尝试为所有的goroutine来分配运行时间，当有goroutine被阻塞或终止时，调度器会通过对goroutine 进行调度以此来保证所有CPU都处于忙碌状态，避免有CPU空闲状态浪费时间。

goroutine 切换规则

在此之前我们需要记住一些goroutine切换规则。runtime源码

// src/runtime/stubs.go

// mcall switches from the g to the g0 stack and invokes fn(g),
// where g is the goroutine that made the call.
// mcall saves g's current PC/SP in g->sched so that it can be restored later.
// It is up to fn to arrange for that later execution, typically by recording
// g in a data structure, causing something to call ready(g) later.
// mcall returns to the original goroutine g later, when g has been rescheduled.
// fn must not return at all; typically it ends by calling schedule, to let the m
// run other goroutines.
//
// mcall can only be called from g stacks (not g0, not gsignal).
//
// This must NOT be go:noescape: if fn is a stack-allocated closure,
// fn puts g on a run queue, and g executes before fn returns, the
// closure will be invalidated while it is still executing.
func mcall(fn func(*g))

对 mcall() 函数注释的翻译请参考文章 Runtime: 当一个goroutine 运行结束后会发生什么

GODEBUG 是 golang中一个控制runtime调度变量的变量，其值为一个用逗号隔开的 name=val对列表，常见有以下几个命名变量。

allocfreetrace

设置allocfreetrace = 1会导致对每个分配进行概要分析，并在每个对象的分配上打印堆栈跟踪并释放它们。

clobberfree

设置 clobberfree=1会使垃圾回收器在释放对象的时候，对象里的内存内容可能是错误的。

cgocheck

cgo相关。

设置 cgocheck=0 将禁用当包使用cgo非法传递给go指针到非go代码的检查。如果值为1(默认值)会启用检测，但可能会丢失有一些错误。如果设置为2的话，则不会丢失错误。但会使程序变慢。

efence

设置 efence=1会使回收器运行在一个模式。每个对象都在一个唯一的页和地址，且永远也不会被回收。

gccheckmark

GC相关。

设置 gccheckmark=1 启用验证垃圾回收器的并发标记，通过在STW时第二个标记阶段来实现，如果在第二阶段的时候，找到一个可达对象，但未找到并发标记，则GC会发生Panic。

gcpacertrace

GC相关。

设置 gcpacertrace=1可使gc打印关于并发 pacer 内部状态的信息

gcshrinkstackoff

GC相关。

设置 gcshrinkstackoff=1可禁止goroutine移动到小stack。这种模式下，goroutine stack只能增长。简单来说就是一个关闭收缩的开关。

gcstoptheworld

GC 相关。

设置 gcstoptheworld=1可禁止并发垃圾回收，使每个gc就是一个事件。设置 gcstoptheworld=2 会在垃圾回收后进行并发扫描。

gctrace

GC 相关。

设置 gctrade=1 会使垃圾回收器在每次GC打印单行标准错误，汇总收集的内存量和暂停的时间。格式可能会更换。

如果输出行以(forced)结尾，则说明此GC是通过调用 runtime.GC 来触发的。这个调试变量非常常见。如 GODEBUG=gotrace=1 go run main.go

输出字段意义:
	gc # @#s #%: #+#+# ms clock, #+#/#/#+# ms cpu, #->#-># MB, # MB goal, # P
where the fields are as follows:
	gc #        the GC number, incremented at each GC
	@#s         time in seconds since program start
	#%          percentage of time spent in GC since program start
	#+...+#     wall-clock/CPU times for the phases of the GC
	#->#-># MB  heap size at GC start, at GC end, and live heap
	# MB goal   goal heap size
	# P         number of processors used
The phases are stop-the-world (STW) sweep termination, concurrent
mark and scan, and STW mark termination. The CPU times
for mark/scan are broken down in to assist time (GC performed in
line with allocation), background GC time, and idle GC time.
If the line ends with "(forced)", this GC was forced by a
runtime.GC() call.

➜  gotest GODEBUG=gctrace=1 go run main.go
gc 1 @0.115s 0%: 0.067+0.92+0.003 ms clock, 0.26+0.41/0.78/0.011+0.015 ms cpu, 4->4->0 MB, 5 MB goal, 4 P
gc 2 @0.194s 0%: 0.056+1.5+0.003 ms clock, 0.22+1.3/0.27/1.6+0.012 ms cpu, 4->4->0 MB, 5 MB goal, 4 P
gc 3 @0.303s 0%: 0.24+1.5+0.004 ms clock, 0.98+0.20/0.32/1.5+0.016 ms cpu, 4->4->0 MB, 5 MB goal, 4 P
gc 4 @0.344s 0%: 0.12+0.45+0.003 ms clock, 0.51+0/0.41/0.81+0.012 ms cpu, 4->4->0 MB, 5 MB goal, 4 P

字段解释

平时在开发中，有时间需要通过查看内存使用情况来分析程序的性能问题，经常会使用到 MemStats 这个结构体。但平时用到的都是一些最基本的方法，今天我们全面认识一下MemStas。

相关文件为 src/runtime/mstats.go ，本文章里主要是与内存统计相关。

MemStats 结构体

// MemStats记录有关内存分配器的统计信息
type MemStats struct {
	// General statistics.
	Alloc uint64
	TotalAlloc uint64
	Sys uint64
	Lookups uint64
	Mallocs uint64
	Frees uint64

	// Heap memory statistics.
	HeapAlloc uint64
	HeapSys uint64
	HeapIdle uint64
	HeapInuse uint64
	HeapReleased uint64
	HeapObjects uint64

	// Stack memory statistics.
	StackInuse uint64
	StackSys uint64

	// Off-heap memory statistics.
	MSpanInuse uint64
	MSpanSys uint64
	MCacheInuse uint64
	MCacheSys uint64
	BuckHashSys uint64
	GCSys uint64
	OtherSys uint64

	// Garbage collector statistics.
	NextGC uint64
	LastGC uint64
	PauseTotalNs uint64
	PauseNs [256]uint64
	PauseEnd [256]uint64
	NumGC uint32
	NumForcedGC uint32
	GCCPUFraction float64
	EnableGC bool
	DebugGC bool

	// BySize reports per-size class allocation statistics.
	BySize [61]struct {
		Size uint32
		Mallocs uint64
		Frees uint64
	}

}

可以清楚的看到，统计信息共分了五类

栈的演变

在 Go1.13之前的版本，Golang 栈管理是使用的分段栈（Segment Stacks）机制来实现的，由于sgement stack 存在 热分裂（hot split）的问题，后面版本改为采用连续栈（ [Contiguous stacks](https://docs.google.com/document/d/1wAaf1rYoM4S4gtnPh0zOlGzWtrZFQ5suE8qr2sD8uWQ/pub)）机制( 说明)。

分段栈（Segment Stack）

分段栈是指开始时只有一个stack，当需要更多的 stack 时，就再去申请一个，然后将多个stack 之间用双向链接连接在一起。当使用完成后，再将无用的 stack 从链接中删除释放内存。segment stack

可以看到这样确实实现了stack 按需增长和收缩，在增加新stack时不需要拷贝原来的数据，系统使用率挺高的。但在一定特别的情况下会存在 热分裂（hot split) 的问题。

当一个 stack 即将用完的时候，任意一个函数都会导致堆栈的扩容，当函数执行完返回后，又要触发堆栈的收缩。如果这个操作是在一个for语句里执行的话，则过多的 malloc 和 free 重复操作将导致系统资源开销非常的大。

如果你对 Stack Frame 不了解的话，可能先阅读一下 Go 语言机制之栈和指针

连续栈（Contiguous stacks） Contiguous stacks 扩容与收缩

连续栈使用了另一种管理机制，每当一个stack 空间不够的时候，直接再申请一个2倍大小的空间，然后再将stack数据拷贝过去，同时修改指向原来stack 的指针到新stack，最后再将旧stack删除。

这种机制可以在当stack 空间快用尽的时候，避免在for语句里频繁触发扩容的问题。也正是官方采用这种机制的原因。

栈的初始化

在上篇文章《 Golang 的底层引导流程/启动顺序》中介绍过，在应用启动时会有一系列的初始化工作，其中就包括对栈的初始化 (源码），调用函数 [stackinit()](https://github.com/golang/go/blob/go1.15.6/src/runtime/stack.go#L158-L170)。

func stackinit() {
	if _StackCacheSize&_PageMask != 0 {
		throw("cache size must be a multiple of page size")
	}
	for i := range stackpool {
		stackpool[i].item.span.init()
		lockInit(&stackpool[i].item.mu, lockRankStackpool)
	}
	for i := range stackLarge.free {
		stackLarge.free[i].init()
		lockInit(&stackLarge.lock, lockRankStackLarge)
	}
}

这里有两个很重要的栈变量，一个是 stackpool，另一个是 stackLarge，两者均为 global pool 级别，实现为对stack的复用。前者是为每一种规格的大小以链接的形式存储可复用stack信息，共有 _NumStackOrders 类。后者为 large stack ，即大小>32K的全局栈。

在Golang中，程序的执行入口为 main() 函数，那么底层又是如何工作的呢? 这个问题的答案我们可以在runtime源码找到。对它的解释主要在 [src/runtime/proc.go](https://github.com/golang/go/blob/go1.15.6/src/runtime/proc.go) 文件，下面我们看一下它是如何一步一步开始执行的。go version 1.15.6

在文件头部有一段对 [Goroutine scheduler](https://github.com/golang/go/blob/go1.15.6/src/runtime/proc.go#L19) 的介绍，我们先了解一下。

调度器的工作是分发goroutines到工作线程让其运行。一句话指明了调度器的存在意义，就是指挥协调GPM干活。

主要包含三部分 G 指的是 goroutine M 工作线程，也叫machine P 处理器（逻辑CPU)，执行 Go code 的一种资源。这里的Go code 其实就是 goroutine里的代码。

M必须被指派给P去执行 Go code, 但可以被阻塞或通过P进行系统调用。

设计文档 https://golang.org/s/go11sched

再往下会发现一段注释说明

// src/runtime/proc.go

// The bootstrap sequence is:
//
//	call osinit
//	call schedinit
//	make & queue new G
//	call runtime·mstart
//
// The new G calls runtime·main.

不错，这个说的就是我们今天的重点。共分四大阶段, 在第三阶段创建新G是通过调用 [runtime.main()](https://github.com/golang/go/blob/go1.15.6/src/runtime/proc.go#L113-L231) 函数实现的,主要用来创建一个main goroutine，然后再运行 [runtime.mstart](https://github.com/golang/go/blob/go1.15.6/src/runtime/proc.go#L1106-L1148) 并启动m0。整个流程如图所示runtime.main

M0 是启动程序后的编号为``的主线程，这个M对应的实例会在全局变量 [runtime.m0](https://github.com/golang/go/blob/go1.15.6/src/runtime/proc.go#L83) 中，不需要在heap上分配，M0负责执行初始化操作和启动第一个G， 在之后M0就和其他的M一样了。

G、P、M 三者是golang实现高并发能的最为重要的概念，runtime 通过 调度器 来实现三者的相互调度执行，通过 p 将用户态的 g 与内核态资源 m 的动态绑定来执行，以减少以前通过频繁创建内核态线程而产生的一系列的性能问题，充分发挥服务器最大有限资源。GPM 协作

调度器的工作是将一个 G（需要执行的代码）、一个 M（代码执行的地方）和一个 P（代码执行所需要的权限和资源）结合起来。

所有的 g、m 和 p 对象都是分配在堆上且永不释放的，所以它们的内存使用是很稳定的。得益于此，runtime 可以在调度器实现中避免写屏障。当一个G执行完成后，可以放入pool中被再次使用，避免重复申请资源。

本节主要通过阅读runtime源码来认识这三个组件到底长的是什么样子，以此加深对 GPM 的理解。go version go1.15.6

理解下文前建议先阅读一下 src/runtime/HACKING.md 文件，中文可阅读 这里，这个文件内容是面向开发者理解runtime的很值得看一看。

本文若没有指定源码文件路径，则默认为 src/runtime/runtime2.go。

G

G是英文字母goroutine的缩写，一般称为“协程”，其实这个词还是无法完整表达它的意思的，但这用的人的多了就成了统称。注意它与线程和进程的区别，这个应该很容易理解，每个gopher应该都知道。

每个 Goroutine 对应一个 g 结构体，它有自己的栈内存, G 存储 Goroutine 的运行堆栈、状态以及任务函数，可重复用，

Goroutine数据结构位于 src/runtime/runtime2.go 文件，注意此文件里有太多重要的底层数据结构，对于我们理解底层runtime非常的重要，建议大量多看看。不需要记住每一个数据结构，但需要的时候要能第一时间想到在哪里查找。

当一个 goroutine 退出时，g 对象会被放到一个空闲的 g 对象池中以用于后续的 goroutine 的使用， 以减少内存分配开销。

Goroutine 字段非常的多，我们这里分段来理解

type g struct {
	// Stack parameters.
	// stack describes the actual stack memory: [stack.lo, stack.hi).
	// stackguard0 is the stack pointer compared in the Go stack growth prologue.
	// It is stack.lo+StackGuard normally, but can be StackPreempt to trigger a preemption.
	// stackguard1 is the stack pointer compared in the C stack growth prologue.
	// It is stack.lo+StackGuard on g0 and gsignal stacks.
	// It is ~0 on other goroutine stacks, to trigger a call to morestackc (and crash).
	stack       stack   // offset known to runtime/cgo

	// 检查栈空间是否足够的值, 低于这个值会扩张栈, 0是go代码使用的
	stackguard0 uintptr // offset known to liblink

	// 检查栈空间是否足够的值, 低于这个值会扩张栈, 1是原生代码使用的
	stackguard1 uintptr // offset known to liblink
}

stack 描述了当前 Goroutine 的栈内存范围[stack.lo, stack.hi)，其中stack 的数据结构为

channel是golang中特有的一种数据结构，通常与goroutine一起使用，下面我们就介绍一下这种数据结构。

channel数据结构

channel 是Golang 中最重要的一个数据结构，源码里对应的结构体是hchan，当我们创建一个channel 的时候，实际上是创建了一个hchan结构体。

hchan结构体

// src/runtime/chan.go

type hchan struct {
	qcount   uint           // total data in the queue
	dataqsiz uint           // size of the circular queue
	buf      unsafe.Pointer // points to an array of dataqsiz elements
	elemsize uint16
	closed   uint32
	elemtype *_type // element type
	sendx    uint   // send index
	recvx    uint   // receive index
	recvq    waitq  // list of recv waiters
	sendq    waitq  // list of send waiters

	// lock protects all fields in hchan, as well as several
	// fields in sudogs blocked on this channel.
	//
	// Do not change another G's status while holding this lock
	// (in particular, do not ready a G), as this can deadlock
	// with stack shrinking.
	lock mutex
}

字段说明

go version 1.15.6

map作为一种常见的 key-value 数据结构，不同语言的实现原理基本差不多。首先在系统里分配一段连接的内存地址作为数组，然后通过对map键进行hash算法(最终将键转换成了一个整型数字)定位到不同的桶bucket(数组的索引位置)，然后将值存储到对应的bucket里

理想的情况下是一个bucket存储一个值，即数组的形式，时间复杂度为O(1)。

如果存在键值碰撞的话，可以通过 链表法 或者 开放寻址法 来解决。

链表法

开放寻址法

对于开放寻址法有多种算法，常见的有线性探测法，线性补偿探测法，随机探测法等，这里不再介绍。

map基本数据结构

hmap结构体

map的核心数据结构定义在 /runtime/map.go

// A header for a Go map.
type hmap struct {
	// Note: the format of the hmap is also encoded in cmd/compile/internal/gc/reflect.go.
	// Make sure this stays in sync with the compiler's definition.
	count     int // # live cells == size of map.  Must be first (used by len() builtin)
	flags     uint8
	B         uint8  // log_2 of # of buckets (can hold up to loadFactor * 2^B items)
	noverflow uint16 // approximate number of overflow buckets; see incrnoverflow for details
	hash0     uint32 // hash seed

	buckets    unsafe.Pointer // array of 2^B Buckets. may be nil if count==0.
	oldbuckets unsafe.Pointer // previous bucket array of half the size, non-nil only when growing
	nevacuate  uintptr        // progress counter for evacuation (buckets less than this have been evacuated)

	extra *mapextra // optional fields
}

在源码中表示 map 的结构体是 hmap，即 hash map 的缩写。

在现实世界中，经常有一些工作是属于流水线类型的，它们的每一个步骤都是紧密关联的，第一步先做什么，再做什么，最后做什么。特别是制造业这个行业，基本全是流水线生产车间。在我们开发中也经常遇到这类的业务场景。

假如我们有个流水线共分三个步骤，分别是 job1、job2和job3。代码： https://play.golang.org/p/e7ZlP9ofXB3

package main

import (
	"fmt"
	"time"
)

func job1(count int) <-chan int {
	outCh := make(chan int, 2)

	go func() {
		defer close(outCh)
		for i := 0; i < count; i++ {
			time.Sleep(time.Second)
			fmt.Println("job1 finish:", 1)
			outCh <- 1
		}
	}()

	return outCh
}

func job2(inCh <-chan int) <-chan int {
	outCh := make(chan int, 2)

	go func() {
		defer close(outCh)
		for val := range inCh {
			// 耗时2秒
			time.Sleep(time.Second * 2)
			val++
			fmt.Println("job2 finish:", val)
			outCh <- val
		}
	}()

	return outCh
}

func job3(inCh <-chan int) <-chan int {
	outCh := make(chan int, 2)

	go func() {
		defer close(outCh)
		for val := range inCh {
			val++
			fmt.Println("job3 finish:", val)
			outCh <- val
		}
	}()

	return outCh
}

func main() {
	t := time.Now()

	firstResult := job1(10)
	secondResult := job2(firstResult)
	thirdResult := job3(secondResult)

	for v := range thirdResult {
		fmt.Println(v)
	}

	fmt.Println("all finish")
	fmt.Println("duration:", time.Since(t).String())
}

输出结果为

1. 认识空结构体
2. 低层实现原理
3. 空结构体之内存对齐
4. 应用场景

在golang中，如果我们想实现一个set集合的话，一般会使用map来实现，其中将set的值作为map的键，对于map的值一般使用一个空结构体来实现，当然对map值也可以使用一个bool类型或者数字类型等，只要符合一个键值对应关系即可。但我们一般推荐使用struct{}来实现，为什么呢?

package main

import "fmt"

func main() {
	m := make(map[int]struct{})
	m[1] = struct{}{}
	m[2] = struct{}{}

	if _, ok := m[1]; ok {
		fmt.Println("exists")
	}

}

上面这段代码是一个很简单的使用map实现的set功能，这里是采用空结构体struct{}来实现。

在分析为什么使用struct{}以前，我看先认识一个struct。

认识空结构体 struct

我们先看一个这段代码

package main

import (
	"fmt"
	"unsafe"
)

type emptyStruct struct{}

func main() {
	a := struct{}{}
	b := struct{}{}

	c := emptyStruct{}

	fmt.Println(a)
	fmt.Printf("%pn", &a)
	fmt.Printf("%pn", &b)
	fmt.Printf("%pn", &c)

	fmt.Println(a == b)

	fmt.Println(unsafe.Sizeof(a))
}

{} // 值
0x586a00 // a 内存地址
0x586a00 // b 内存地址, 同a一样
0x586a00 // c 内存地址，别名类型变量，同a一样
true // 丙个结构体是否相等,很显示，上面打印的是同一个内存地址
0 // 占用内存大小

从打印结果里我们可以得出以下结论

什么是内存重排

内存重排指的是内存的读/写指令重排。

为什么要内存重排

为了提升程序执行效率，减少一些IO操作，一些硬件或者编译器会对程序进行一些指令优化，优化后的结果可能会导致程序编码时的顺序与代码编译后的先后顺序不一致。

就拿做饭场景来说吧，是先蒸米还是先炒菜，这两者是没有冲突的，编译器在编译时有可能与你要求的顺序不一样。

编译器重排

如下面这段代码

X = 0
for i in range(100):
    X = 1
    print X

要实现打印100次1，很显示在for里面每次都执行X=1语句有些浪费资源，如果将初始变量值修改为1，是不是要快的多。编译器也分析到了这一点，于是在编译时对代码做了以下优化

X = 1
for i in range(100):
    print X

最终输出结果是一样的，两段代码功能也一样。

但是如果此时有另一个线程里执行了一个 X=0 的赋值语句的话（两个线程同时运行），那么输出结果就可能与我们想要的不一样了。

优化前情况：第一个线程执行到了第3次print X 后，第二个线程执行了X=0,把X 的值进行了修改，结果就有可能是1110 1111（在线程执行第5次时，重新执行了X=1，而且之后一直都是 1）。这就有问题了。

优化后情况：按上面的逻辑来执行的话，结果就是11100000…, 后面全是0，再也没有机会将X贬值为1了

由此我们可以得出一个结果，在多线程下，是无法保证编译前后的代码功能是“待价”的。

所以要开发时，这一点我们一定要小心。搞不好在单线程运行没有问题的程序在多线程下会出现各种各样的问题。

每当我们提到内存重排的时候，其实真实在讨论的主题是 内存屏障Memory barrier。指令重排无法逾越内存屏障。

CPU 重排

参考： https://www.w3xue.com/exp/article/20196/40758.html

CPU 架构 Figure 1. CPU ArchitectureFigure 2. Store BufferFigure 3. MESI Protocol

MESI 可参考 https://mp.weixin.qq.com/s/vnm9yztpfYA4w-IM6XqyIA

相关话题

• 锁、内存屏障与缓存一致性

• memory barrier

• [译] 什么是缓存 false sharing 以及如何解决(Golang 示例)

在Golang中有一个并发原语是 Singleflight，好像知道的开发者并不多。其中著名的 https://github.com/golang/groupcache 就用到了这个并发原语。

Golang版本

go1.15.5

相关知识点

map、Mutex、channel、

使用场景

一般用在对指定资源频繁操作的情况下，如高并发下的“缓存击穿”问题。

缓存击穿：一个存在的key，在缓存过期的瞬间，同时有大量的请求过来，造成所有请求都去DB读取数据，这些请求都会击穿缓存到DB，造成瞬时DB请求量大、压力瞬间骤增，导致数据库负载过高，影响整个系统正常运行。（缓存击穿不同于 缓存雪崩 和 缓存穿透）

怎么理解这个原语呢，简单的讲就是将对同一个资源的多个请求合并为一个请求。

举例说明，假如当有10万个请求来获取同一个key的值的时候，正常情况下会执行10万次get操作。而使用singleflight并发语后，只需要首次的地个请求执行一次get操作就可以了，其它请求再过来时，只需要只需要等待即可。待执行结果返回后，再把结果分别返回给等待中的请求，每个请求再返回给客户端，由此看看，在一定的高并发场景下可以大大减少系统的负载，节省大量的资源。

注意这个与 sync.Once是不一样的，sync.Once 是全局只能有一个，但本并发原语则是根据key来划分的，并且可以根据需求来决定什么情况下共用一个。

实现原理

主要使用 Mutext 和 Map 来实现，以 key 为键，值为 *call。每个*call中存储有一个请求 chans 字段，用来存储所有请求此key的客户端，等有返回结果的时候，再从chans字段中读取出来，分别写入即可。

源文件为 /src/internal/singleflight/singleflight.go

Singleflight 数据结构如下

1. Do() 这个方法是一个执行函数并返回执行结果 参数 key 要请求的key，多个请求可能请求的是同一个key，同时也只有一个函数在执行 fn 对应执行函数，此函数有三个返回值v, err, shared。其中shared表示当前返回结果是否为多个请求结果
2. DoChan() 类型与Do()方法，但返回的是个 ch 类型，等函数 fn 执行后，可以通过读取返回的ch来获取函数结果
3. Forget() 在官方库internal/singleflight/singleflight.go中这个名字是ForgetUnshared， 告诉 Group 忘记请求的这个key，下次再请求时，直接当作新的key来处理就可以了。其实就是将这个key从map中删除，后续再有这个key的操作的话，即视为新一轮的处理逻辑。

其中Do() 和 DoChan() 的功能一样，只是获取数据的方式有所区别，开发者可以根据自己的情况来选择使用哪一个。另外还包含一个由Do()方法调用的私有方法 doCall()，直接执行key处理方法的函数

func (g *Group) doCall(c *call, key string, fn func() (interface{}, error)) {...}

实现数据结构

实现内部主要的数据结构一共三个，分别是 call、Group 和 Result。

protobuf是Google开源的一款支持跨平台、语言中立的结构化数据描述和高性能序列化协议，此协议完全基于二进制，所以性能要远远高于JSON/XML。由于出色的传输性能因此常见于微服务之间的通讯，其中最为著名的是Google开源的 gRPC 框架。

那么protobuf是如何实现高性能的，又是如何实现数据的编码和解码的呢？

protobuf协议原理

基于128bits的数据存储方式(Base 128 Varints)

Varint 是一种紧凑的表示数字的方法。它用一个或多个字节来表示一个数字，值越小的数字使用越少的字节数。这能减少用来表示数字的字节数。

比如对于 int32 类型的数字，一般需要 4 个 byte 来表示。但是采用 Varint，对于很小的 int32 类型的数字，则可以用 1 个 byte 来表示。当然凡事都有好的也有不好的一面，采用 Varint 表示法，大的数字则需要 5 个 byte 来表示。从统计的角度来说，一般不会所有的消息中的数字都是大数，因此大多数情况下，采用 Varint 后，可以用更少的字节数来表示数字信息

Varint 中的每个 byte 的最高位 bit 有特殊的含义，如果该位为 1，表示后续的 byte 也是该数字的一部分；如果该位为 0，则结束。其他的 7 个 bit 都用来表示数字。因此小于 128 的数字都可以用一个 byte 表示。大于 128 的数字，比如 300，会用两个字节来表示：

1010 1100 0000 0010。

另外如果从数据大小角度来看，这种表示方式比真正要代表的数据多了一个bit, 所以其实际传输大小就多14%（1/7 = 0.142857143），对于这一点我们需要有所了解。

下面我们看一个例子：

数字1表示方式：0000 0001

对于小的数据比较好理解，正常情况下1的二进制是 0000 0001,使用128bits表示的话，首位结束标识位也是0，所以两者结果是一样的 000 0001。

上面是对小数据(<=128)的表示方法，我们再看一下非小数据(>128)的表示方法

数字 300 表示方式：1010 1100 0000 0010