工作池gcWork

工作缓存池（work pool）实现了生产者和消费者模型，用于指向灰色对象。一个灰色对象在工作队列中被扫描标记，一个黑色对象表示已被标记不在队列中。

写屏障、根发现、栈扫描和对象扫描都会生成一个指向灰色对象的指针。扫描消费时会指向这个灰色对象，从而将先其变为黑色，再扫描它们，此时可能会产生一个新的指针指向灰色对象。这个就是三色标记法的基本知识点，应该很好理解。

gcWork 是为垃圾回收器提供的一个生产和消费工作接口。

它可以用在stack上，如

(preemption must be disabled)
gcw := &getg().m.p.ptr().gcw
.. call gcw.put() to produce and gcw.tryGet() to consume ..

在标记阶段使用gcWork可以防止垃圾收集器转换到标记终止，这一点很重要，因为gcWork可能在本地持有GC工作缓冲区。可以通过禁用抢占（systemstack 或 acquirem）来实现。

数据结构

type gcWork struct {
	wbuf1, wbuf2 *workbuf

	bytesMarked uint64
	scanWork int64
	flushedWork bool
}

• wbuf1,wbuf2：这里 wbuf1 是主工作缓存区; wbuf2为次工作缓存区，两者要么都是nil,要么都不是。 这可以看作是两个工作缓冲区指针串联的堆栈。当我们弹出最后一个指针的时候，我们可以引入新的缓存区，并将指针向上移动一个空缓存区，从而丢失掉的缓存区；当我们填充两个缓存区的时，可以通过引入一个新的空缓冲区并丢弃一个满的缓冲区，同时将堆栈向下移动一个工作缓冲区。
• bytesMarked 标记为黑色对象的累计大小
• scanWork 扫描统计
• flushedWork 表示自上次 gcMarkDone 终止检查以来，已将非空工作缓存区刷新到全局工作队列。表示是否gcWork可能传递给了另一个gcWork

wbuf1 和 wbuf2 为 workbuf 数据类型，其数据结构

type workbuf struct {
	workbufhdr
	// account for the above fields
	obj [(_WorkbufSize - unsafe.Sizeof(workbufhdr{})) / sys.PtrSize]uintptr
}

type workbufhdr struct {
	node lfnode // must be first
	nobj int
}

// Lock-free stack node.
// Also known to export_test.go.
type lfnode struct {
	next    uint64
	pushcnt uintptr
}

工作原理

GC 期间 gcBgMarkWorker() 函数会根据GC的模式(gcMarkWorkerMode、gcMarkWorkerDedicatedMode、gcMarkWorkerFractionalMode 和 gcMarkWorkerIdleMode) 调用 gcDrain() 函数采用不同的策略来实现扫描来实现将灰色对象变为黑色。

在阅读此文前，需要先了解一下三色标记法以及混合写屏障这些概念。

源文件 [src/runtime/mgc.go](https://github.com/golang/go/blob/go1.16/src/runtime/mgc.go) 版本 1.16.2。

基本知识

在介绍GC之前，我们需要认识有些与GC相关的基本信息，如GC的状态、模式、统计信息等。

三种状态

共有三种状态

const (
	_GCoff             = iota // GC not running; sweeping in background, write barrier disabled
	_GCmark                   // GC marking roots and workbufs: allocate black, write barrier ENABLED
	_GCmarktermination        // GC mark termination: allocate black, P's help GC, write barrier ENABLED
)

• _GCoff GC未运行
• _GCmark 标记中，启用写屏障
• _GCmarktermination 标记终止，启用写屏障

三种模式

支持三种模式：

const (
    gcBackgroundMode gcMode = iota // concurrent GC and sweep
    gcForceMode                    // stop-the-world GC now, concurrent sweep
    gcForceBlockMode               // stop-the-world GC now and STW sweep (forced by user)
)

• gcBackgroundMode 默认模式，标记与清扫过程都是并发执行的
• gcForceMode 只在清扫阶段支持并发；
• gcForceBlockMode GC全程需要STW。

针对每种模式，在标记阶段会采用不同的标记策略，详细见  [gcBgMarkWorker()](https://github.com/golang/go/blob/go1.16.2/src/runtime/mgc.go#L1877-L2048)

今天再看 timer 源码的时候，在函数 [clearDeletedTimers()](https://github.com/golang/go/blob/go1.16.2/src/runtime/time.go#L904-L992) 里看到一段对切片的处理代码，实现目的就是对一个切片内容进行缩容。

// src/runtime/time.go

// The caller must have locked the timers for pp.
func clearDeletedTimers(pp *p) {
	timers := pp.timers
	......
	// 对无用的切片元素赋值 nil
	for i := to; i < len(timers); i++ {
		timers[i] = nil
	}

	atomic.Xadd(&pp.deletedTimers, -cdel)
	atomic.Xadd(&pp.numTimers, -cdel)
	atomic.Xadd(&pp.adjustTimers, -cearlier)

	timers = timers[:to]
	pp.timers = timers
	updateTimer0When(pp)

	......
}

变量 to 指新切片的长度， len(timers)指原来切片的长度。

这里在其进行 timers = timers[:to] 操作前，先是将 to 数组索引后的值进行了赋值 nil。按照我们平常的用法，赋 nil 值是没有必要执行这一步的，那为什么这里要加这一步呢？主要还是与GC 有关。

定时器作为开发经常使用的一种数据类型，是每个开发者需要掌握的，对于一个高级开发很有必要了解它的实现原理，今天我们runtime源码来学习一下它的底层实现。

定时器分两种，分别为 Timer 和 Ticker，两者差不多，这里重点以Timer为例。

源文件位于 [src/time/sleep.go](https://github.com/golang/go/blob/go1.16.2/src/time/sleep.go) 和 [src/time/tick.go](https://github.com/golang/go/blob/go1.16.2/src/time/tick.go) 。 go version 1.16.2

数据结构

Timer 数据结构

// src/runtime/sleep.go

// The Timer type represents a single event.
// When the Timer expires, the current time will be sent on C,
// unless the Timer was created by AfterFunc.
// A Timer must be created with NewTimer or AfterFunc.
type Timer struct {
	C <-chan Time
	r runtimeTimer
}

Timer 数据类型是表示单个事件。当计时器过期时，当前的时候将会发送到 Timer.C 通道，如果用 AfterFunc 创建计时器的话，则例外。

在高并发编程中，经常会出现对同一个资源并发访问修改的情况，为了保证最终结果的正确性，一般会使用 锁 和 CAS原子操作 来实现。

如要对一个变量进行计数统计，两种实现方式分别为

package main

import (
	"fmt"
	"sync"
)

// 锁实现方式
func main() {
	var count int64
	var wg sync.WaitGroup
	var mu sync.Mutex

	for i := 0; i < 10000; i++ {
		wg.Add(1)
		go func(wg *sync.WaitGroup) {
			defer wg.Done()
			mu.Lock()
			count = count + 1
			mu.Unlock()
		}(&wg)
	}
	wg.Wait()

	// count = 10000
	fmt.Println("count = ", count)
}

与

package main

import (
	"fmt"
	"sync"

	"sync/atomic"
)

// atomic CAS 原子操作
func main() {
	var count int64
	var wg sync.WaitGroup

	for i := 0; i < 10000; i++ {
		wg.Add(1)
		go func(wg *sync.WaitGroup) {
			defer wg.Done()
			// 失败一直重试
			for {
				old := atomic.LoadInt64(&count)
				if atomic.CompareAndSwapInt64(&count, old, old+1) {
					break
				}
			}

		}(&wg)
	}
	wg.Wait()

	// count = 10000
	fmt.Println("count = ", count)
}

可以看到两种用法的执行结果是一样的，我们再看一下两者的性能区别。

信号量是并发编程中比较常见的一种同步机制，它会保持资源计数器一直在0-N（N表示权重值大小，在用户初始化时指定）之间。当用户获取的时候会减少一点，使用完毕后再恢复过来。当遇到请求时资源不够的情况下，将会进入休眠状态以等待其它进程释放资源。

在 Golang 官方扩展库中为我们提供了一个基于权重的信号量 [semaphore](https://github.com/golang/sync/blob/master/semaphore/semaphore.go) 并发原语。

你可以将下面的参数 n 理解为资源权重总和，表示每次获取时的权重；也可以理解为资源数量，表示每次获取时必须一次性获取的资源数量。为了理解方便，这里直接将其理解为资源数量。

数据结构

[semaphoreWeighted](https://github.com/golang/sync/blob/master/semaphore/semaphore.go#L19-L33) 结构体

type waiter struct {
	n     int64
	ready chan<- struct{} // Closed when semaphore acquired.
}

// NewWeighted creates a new weighted semaphore with the given
// maximum combined weight for concurrent access.
func NewWeighted(n int64) *Weighted {
	w := &Weighted{size: n}
	return w
}

// Weighted provides a way to bound concurrent access to a resource.
// The callers can request access with a given weight.
type Weighted struct {
	size    int64
	cur     int64
	mu      sync.Mutex
	waiters list.List
}

一个 watier 就表示一个请求，其中n表示这次请求的资源数量（权重）。

对于gc的介绍主要位于 [src/runtime/mgc.go](https://github.com/golang/go/blob/go1.16.2/src/runtime/mgc.go)，以下内容是对注释的翻译。

GC 四个阶段

通过源文件注释得知GC共分四个阶段：

1. GC 清理终止 (GC performs sweep termination） a. Stop the world, 每个P 进入GC safepoint（安全点），从此刻开始，万物静止。 b. 清理未被清理的span，如果GC被强制执行时才会出现这些未清理的span
2. GC 标记阶段（GC performs the mark phase） a. 将gc标记从 _GCoff 修改为 _GCmark，开启写屏障（write barries）和 协助助手（mutator assists），将根对象放入队列。 在STW期间，在所有P都启用写屏障之前不会有什么对象被扫描。 b. Start the world（恢复STW）。标记工作线程和协助助手并发的执行。对于任何指针的写操作和指针值，都会被写屏障覆盖，使新分配的对象标记为黑色。 c. GC 执行根标记工作。包括扫描所有的栈，全局对象和不在堆数据结构中的堆指针。每扫描一个栈就会导致goroutine停止，把在栈上找到的所有指针置灰色，然后再恢复goroutine运行。 d. GC 遍历队列中的每个灰色对象，扫描完以后将灰色对象标记为黑色，并将其指向的对象标记为灰色。 e. 由于GC工作在分布本地缓存中，采用了一种 “分布式终止算法（distributed termination algorithm）” 来检测什么时候没有根对象或灰色对象。在这个时机GC会转为标记中止（mark termination）。
3. 标记终止（GC performs mark termination） a. Stop the world，从此刻开始，万物静止 b. 设置阶段为 _GCmarktermination，并禁用 工作线程worker和协助助手 c. 执行清理，flush cache
4. 清理阶段（GC performs the sweep phase） a. 设置清理阶段标记为 _GCoff，设置清理状态禁用写屏障 b. Start the world（恢复STW），从现在开始，新分配的对象是白色的。如有必要，请在请在使用前扫描清理 c. GC在后台执行并发扫描，并响应分配

整个GC共四个阶段，每次开始时从上到下执行。第一步是清理上次未清理完的span，而不是直接标记阶段。具体的流程可以参考 runtime.GC() 函数

Pool 指一组可以单独保存和恢复的 临时对象。Pool 中的对象随时都有可能在没有收到任何通知的情况下被GC自动销毁移除。

多个goroutine同时操作Pool是并发安全的。

源文件为 [src/sync/pool.go](https://github.com/golang/go/blob/master/src/sync/pool.go) go version: 1.16.2

为什么使用Pool

在开发高性能应用时，经常会有一些完全相同的对象需要频繁的创建和销毁，每次创建都需要在堆中分配对象，等使用完毕后，这些对象需要等待GC回收。我们知道在Golang中使用三色标记法进行垃圾回收的，在回收期间会有一个短暂STW（stop the world)的时间段，这样就会导致程序性能下降。

那么能否实现类似数据库连接池这种效果，用来避免对象的频繁创建和销毁，达到尽可能的资源复用呢？为了实现这种需求，标准库中有了sync.Pool 这个数据结构。看名字很知道它是一个池。但是它和我们想象中的数据库连接池还是有些差别的。对于数据库连接池这种资源只要不手动释放就可以一直利用，但对于 sync.Pool 则不一样，主要是因为Pool里的对象是随时都有可能被销毁，即这些都 临时对象。只要进行了GC，就会出现对象销毁的情况。所以不用使用Pool当作数据库连接池。

总之记住一点：sync.Pool中的资源随时都有可能被销毁而消失，这是与我们日常所说的池最大的区别，切勿乱用。

sync.Pool 基本信息

与 Pool 相关的主要有三个常量，其中 allPoolsMu 是一个全局锁；对于 allPoos 和 oldPools 则是一个 *Pool 数组，主要用在当P数量发生变化（增加）时会导致一些P找不到自己对应的 localPool，会将当前 Pool 放入 allPools，这样便于当GC发生时对其进行清理。

var (
	allPoolsMu Mutex

	// allPools is the set of pools that have non-empty primary
	// caches. Protected by either 1) allPoolsMu and pinning or 2)
	// STW.
	allPools []*Pool

	// oldPools is the set of pools that may have non-empty victim
	// caches. Protected by STW.
	oldPools []*Pool
)

Pool 数据结构

// A Pool must not be copied after first use.
type Pool struct {
	// 不允许复制
	noCopy noCopy

	// 池的固定大小, local 对应类似 poolLocal，是一个数组
	local     unsafe.Pointer // local fixed-size per-P pool, actual type is [P]poolLocal
	localSize uintptr        // size of the local array

	victim     unsafe.Pointer // local from previous cycle
	victimSize uintptr        // size of victims array

	// New optionally specifies a function to generate
	// a value when Get would otherwise return nil.
	// It may not be changed concurrently with calls to Get.
	// 可选项，当使用Get获取对象时调用此函数，返回值是一个接口，意味着可以返回任意内容。如果不指定此函数将返回nil。
	// 不能在调用Get() 时修改此函数
	New func() interface{}
}

一旦 Pool 被初始化后,后续将不可以被复制使用，这一点与 sync.Mutex 同步原语相同。注意这里有一个 noCopy 这字段，主要是用在一些go工具检测对象是否存在复制的问题。

在 sync 包里提供了最基本的同步原语，如互斥锁 Mutex。除 Once 和 WaitGroup 类型外，大部分是由低级库提供的，更高级别的同步最好是通过 channel 通讯来实现。

Mutex 类型的变量默认值是未加锁状态，在第一次使用后，此值将不得复制，这点切记！！！

本文基于go version: 1.16.2

Mutex 锁实现了 Locker 接口。

// A Locker represents an object that can be locked and unlocked.
type Locker interface {
	Lock()
	Unlock()
}

锁的模式

为了互斥公平性，Mutex 分为 正常模式 和 饥饿模式 两种。

正常模式

在正常模式下，等待者 waiter 会进入到一个FIFO队列，在获取锁时waiter会按照先进先出的顺序获取。当唤醒一个waiter 时它被并不会立即获取锁，而是要与新来的goroutine竞争，这种情况下新来的goroutine比较有优势，主要是因为它已经运行在CPU，可能它的数量还不少，所以waiter大概率下获取不到锁。在这种waiter获取不到锁的情况下，waiter会被添加到队列的前面。如果waiter获取不到锁的时间超出了1毫秒，它将被切换为饥饿模式。

这里的 waiter 是指新来一个goroutine 时会尝试一次获取锁，如果获取不到我们就视其为watier，并将其添加到FIFO队列里。

饥饿模式

在正常模式下，每次新来的goroutine都会抢走锁，就这会导致一些 waiter 永远也获取不到锁，产生饥饿问题。所以为了应对高并发抢锁场景下的公平性，官方引入了饥饿模式。

在饥饿模式下，锁将直接交给队列最前面的waiter。新来的goroutine即使在锁未被持有情况下也不会参与竞争锁，同时也不会进行自旋，而直接将其添加到队列的尾部。

如果拥有锁的waiter发现有以下两种情况，它将切换回正常模式：

1. 它是队列里的最后一个waiter，再也没有其它waiter
2. 等待时间小于1毫秒

模式区别

正常模式 拥有更好的性能，因为即使等待队列里有抢锁的 waiter，由于新来的goroutine 正在CPU中运行，所以优先获取到锁。 饥饿模式 是对公平性和性能的一种平衡，它避免了某些 goroutine 长时间的等待锁。在饥饿模式下，优先处理的是那些一直在等待的 waiter。饥饿模式在一定机时会切换回正常模式。

Golang采用了三色标记法来进行垃圾回收，那么在什么场景下会触发这个GC动作呢？

源码主要位于文件 [src/runtime/mgc.go](https://github.com/golang/go/blob/go1.16/src/runtime/mgc.go) go version 1.16

触发条件从大方面来说，分为 手动触发 和 系统触发 两种方式。手动触发一般很少用，主要通过开发者调用 runtime.GC() 函数来实现，而对于系统自动触发是 运行时 根据一些条件自行维护的，这也正是本文要介绍的内容。

不管哪种触发方式，底层回收机制是一样的，所以我们先看一下手动触发，看看能否根据它来找GC触发所需的条件。

// src/runtime/mgc.go

// GC runs a garbage collection and blocks the caller until the
// garbage collection is complete. It may also block the entire
// program.
func GC() {
	n := atomic.Load(&work.cycles)

	// 等待上一轮的标记终止
	gcWaitOnMark(n)

	// We're now in sweep N or later. Trigger GC cycle N+1, which
	// will first finish sweep N if necessary and then enter sweep
	// termination N+1.
	// 触发GC
	gcStart(gcTrigger{kind: gcTriggerCycle, n: n + 1})

	// Wait for mark termination N+1 to complete.
	// 等待本轮 标记终止
	gcWaitOnMark(n + 1)

	......
}

可以看到开始执行GC的是 [gcStart()](https://github.com/golang/go/blob/go1.16/src/runtime/mgc.go#L1286-L1463) 函数，它有一个 gcTrigger 参数，是一个触发条件结构体，它的结构体也很简单。

在Go1.14版本开始实现了 基于信号的协程抢占调度 模式，在此版本以前执行以下代码是永远也无法执行最后一条println语句。

本文基于go version 1.16

package main

import (
    "runtime"
    "time"
)

func main() {
    runtime.GOMAXPROCS(1)
    go func() {
        for {
        }
    }()

    time.Sleep(time.Millisecond)
    println("OK")
}

原因很简单：在main函数里只有一个CPU，从上到下执行到 time.Sleep() 函数的时候，会将 main goroutine 放入运行队列，出让了P,开始执行匿名函数，但匿名函数是一个for循环，没有任何 IO 语句，也就无法引起对 G 的调度，所以当前仅有的一个 P 永远被其占用，导致无法打印OK。

这个问题在1.14版本开始有所改变，主要是因为引入了基于信号的抢占模式。在程序启动时，初始化信号，并在 runtime.sighandler 函数注册了 SIGURG 信号的处理函数 runtime.doSigPreempt，然后在触发垃圾回收的栈扫描时或执行 sysmon 监控线程时，调用函数挂起goroutine，并向M发送信号，M收到信号后，会让当前goroutine陷入休眠继续执行其他的goroutine。

本篇从发送与接收信号并处理两方面来看一下它是如何实现的。

发送信号

在上篇文章（ 认识sysmon监控线程）介绍 sysmon 的时候，我们知道监控线程会在无P的情况下一直运行，定期扫描所有的P，将长时间运行的G 进行解除。

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

		......

		// retake P's blocked in syscalls
		// and preempt long running G's
		if retake(now) != 0 {
			idle = 0
		} else {
			idle++
		}
	}

	......

}

通过 retake() 函数对所有 P 进行检查。

我们上篇文章（ Golang 的底层引导流程/启动顺序）介绍了一个golang程序的启动流程，在文章的最后对于最重要的一点“调度“ (函数  [schedule()](https://github.com/golang/go/blob/go1.15.6/src/runtime/proc.go#L2607-L2723)) 并没有展开来讲，今天我们继续从源码来分析一下它的调度机制。

在此之前我们要明白golang中的调度主要指的是什么？在 src/runtime/proc.go 文件里有一段注释这样写到

// Goroutine scheduler

// The scheduler’s job is to distribute ready-to-run goroutines over worker threads.

这里指如何找一个已准备好运行的 G 关联到PM 让其执行。对于G 的调度可以围绕三个方面来理解：

• 时机：什么时候关联（调度）。对于调度时机一般是指有空闲P的时候都会去找G执行
• 对象：选择哪个G进行调度。这是我们本篇要讲的内容
• 机制：如何调度。execute() 函数

理解了这三个问题，基本也就明白了它的调度策略了，本篇主要对G的获取。

源文件 [src/runtime/proc.go](https://github.com/golang/go/blob/go1.15.6/src/runtime/proc.go) , go version 1.15.6

获取G流程

下面我们看一下 schedule() 函数

// One round of scheduler: find a runnable goroutine and execute it.
// Never returns.
func schedule() {}

从注释我们可得知以下几点:

1. 调度是一轮一轮执行的，并不是只执行一次
2. 调度的工作就是找到一个 runnable 状态的G，对于G的选择可直接理解为调度（实际上这只是调试中的前半部分，找到G 还要把它放在一个位置去执行），至少大部分场景下我们谈论的是指G的调度
3. 当前这个调度并无返回值，也就是说在当函数执行结束时就代表当前一轮的调度已结束(不严谨)。剩下的执行此函数后面的程序

func schedule() {
	// 获取当前 g0
	_g_ := getg()

	if _g_.m.locks != 0 {
		throw("schedule: holding locks")
	}

	if _g_.m.lockedg != 0 {
		stoplockedm()
		execute(_g_.m.lockedg.ptr(), false) // Never returns.
	}

	// We should not schedule away from a g that is executing a cgo call,
	// since the cgo call is using the m's g0 stack.
	// 不允许cgo正在使用g0栈
	if _g_.m.incgo {
		throw("schedule: in cgo")
	}

top:
	pp := _g_.m.p.ptr()
	pp.preempt = false

	if sched.gcwaiting != 0 {
		gcstopm()
		goto top
	}
	if pp.runSafePointFn != 0 {
		runSafePointFn()
	}

	// Sanity check: if we are spinning, the run queue should be empty.
	// 健全性检查：如果有m正在spinning 的话，则g的运行队列应该是空的才对，这个应该很好理解
	// Check this before calling checkTimers, as that might call
	// goready to put a ready goroutine on the local run queue.
	// 健全性检查必须要在调用 checkTimers() 之前进行检查，这是因为有可能goready()在本地运行队列放了一个就绪的goroutine
	if _g_.m.spinning && (pp.runnext != 0 || pp.runqhead != pp.runqtail) {
		throw("schedule: spinning with local work")
	}

	// 重点关注 定时器处理
	checkTimers(pp, 0)

	var gp *g
	var inheritTime bool

	// Normal goroutines will check for need to wakeP in ready,
	// but GCworkers and tracereaders will not, so the check must
	// be done here instead.
	tryWakeP := false
	if trace.enabled || trace.shutdown {
		gp = traceReader()
		if gp != nil {
			casgstatus(gp, _Gwaiting, _Grunnable)
			traceGoUnpark(gp, 0)
			tryWakeP = true
		}
	}
	if gp == nil && gcBlackenEnabled != 0 {
		gp = gcController.findRunnableGCWorker(_g_.m.p.ptr())
		tryWakeP = tryWakeP || gp != nil
	}
	if gp == nil {
		// Check the global runnable queue once in a while to ensure fairness.
		// Otherwise two goroutines can completely occupy the local runqueue
		// by constantly respawning each other.
		// 为了确保公平性，调度器会每经过61次调度就直接从全局g运行队列获取1个G，否则直接从本地g运行队列获取
		if _g_.m.p.ptr().schedtick%61 == 0 && sched.runqsize > 0 {
			lock(&sched.lock)
			gp = globrunqget(_g_.m.p.ptr(), 1)
			unlock(&sched.lock)
		}
	}

	// 从与当前m关联的p本地g队列获取，优先读取p.runnext的G,如果为nil再从队列里取
	if gp == nil {
		gp, inheritTime = runqget(_g_.m.p.ptr())
		// We can see gp != nil here even if the M is spinning,
		// if checkTimers added a local goroutine via goready.
	}

	// 以阻塞方式获取一个g, 重点关注函数 finrunnable() 函数
	if gp == nil {
		gp, inheritTime = findrunnable() // blocks until work is available
	}

	// This thread is going to run a goroutine and is not spinning anymore,
	// so if it was marked as spinning we need to reset it now and potentially
	// start a new spinning M.
	// 如果当前m处于 spinning 状态，则进行重置，因为它要执行当前获取到的G
	if _g_.m.spinning {
		resetspinning()
	}

	if sched.disable.user && !schedEnabled(gp) {
		// Scheduling of this goroutine is disabled. Put it on
		// the list of pending runnable goroutines for when we
		// re-enable user scheduling and look again.
		lock(&sched.lock)
		if schedEnabled(gp) {
			// Something re-enabled scheduling while we
			// were acquiring the lock.
			unlock(&sched.lock)
		} else {
			sched.disable.runnable.pushBack(gp)
			sched.disable.n++
			unlock(&sched.lock)
			goto top
		}
	}

	// If about to schedule a not-normal goroutine (a GCworker or tracereader),
	// wake a P if there is one.
	// 如果调度的是一个gcworker或traceeader，则唤醒一个P (gc也是并发的)
	if tryWakeP {
		wakep()
	}
	if gp.lockedm != 0 {
		// Hands off own p to the locked m,
		// then blocks waiting for a new p.
		startlockedm(gp)
		goto top
	}

	// 执行G(将G运行在一个m上)
	execute(gp, inheritTime)
}

可以看到，整个 schedue() 函数主要工作就是获取一个 _Grunnable 状态的G，大概获取流程如下

我们知道在Golang中，当一个Goroutine由于执行 系统调用 而阻塞时，会将M从GPM中分离出去，然后P再找一个G和M重新执行，避免浪费CPU资源，那么在内部又是如何实现的呢？今天我们还是通过学习Runtime源码的形式来看下他的内部实现细节有哪些？

go version 1.15.6

我们知道一个P有四种运行状态，而当执行系统调用函数阻塞时，会从 _Prunning 状态切换到 _Psyscall，等系统调用函数执行完毕后再切换回来。P的状态切换

从上图我们可以看出 P 执行系统调用时会执行 [entersyscall()](https://github.com/golang/go/blob/go1.15.6/src/runtime/proc.go#L3134-L3142) 函数（另还有一个类似的阻塞函数 entersyscallblock() ，注意两者的区别）。当系统调用执行完毕切换回去会执行 exitsyscall() 函数，下面我们看一下这两个函数的实现。

进入系统调用

// Standard syscall entry used by the go syscall library and normal cgo calls.
//
// This is exported via linkname to assembly in the syscall package.
//
//go:nosplit
//go:linkname entersyscall
func entersyscall() {
	reentersyscall(getcallerpc(), getcallersp())
}

当通过Golang标准库 syscall 或者 cgo 调用时会执行 entersyscall() 函数，并通过 go:linkname 方式导出为标准包。此函数只是对 [reentersyscall()](https://github.com/golang/go/blob/go1.15.6/src/runtime/proc.go#L3037-L3132) 函数的封装，我们看下这个函数实现了什么。

函数注释比较多，这里只帖子重点的一部分

// The goroutine g is about to enter a system call.
// Record that it's not using the cpu anymore.
// This is called only from the go syscall library and cgocall,
// not from the low-level system calls used by the runtime.
//
// Entersyscall cannot split the stack: the gosave must
// make g->sched refer to the caller's stack segment, because
// entersyscall is going to return immediately after.
//
// Nothing entersyscall calls can split the stack either.
// We cannot safely move the stack during an active call to syscall,
// because we do not know which of the uintptr arguments are
// really pointers (back into the stack).
// In practice, this means that we make the fast path run through
// entersyscall doing no-split things, and the slow path has to use systemstack
// to run bigger things on the system stack.
//
// reentersyscall is the entry point used by cgo callbacks, where explicitly
// saved SP and PC are restored. This is needed when exitsyscall will be called
// from a function further up in the call stack than the parent, as g->syscallsp
// must always point to a valid stack frame. entersyscall below is the normal
// entry point for syscalls, which obtains the SP and PC from the caller.

从注释我们得知以下信息：

上一篇我们介绍了 创建一个goroutine 会经历些什么，今天我们再看下当一个goroutine 运行结束的时候，又会发生什么？

go version 1.15.6。

主要源文件为 [src/runtime/proc.go](https://github.com/golang/go/blob/go1.15.6/src/runtime/proc.go)。

当一个goroutine 运行结束的时候，默认会执行一个 [goexit1()](https://github.com/golang/go/blob/go1.15.6/src/runtime/proc.go#L2941-L2950) 的函数，这是一个只有八行代码的函数，其中最后以通过 [mcall()](https://github.com/golang/go/blob/go1.15.6/src/runtime/stubs.go#L34) 调用 [goexit0](https://github.com/golang/go/blob/go1.15.6/src/runtime/proc.go#L2952-L3011) 函数结束。因此我们主要关注 goexit0 函数即可。这里为了更好让大家理解，以此之前需要先介绍一下 mcall() 函数。

在 [stubs.go](https://github.com/golang/go/blob/go1.15.6/src/runtime/stubs.go#L20-L34) 源文件中只是对 [mcall()](https://github.com/golang/go/blob/go1.15.6/src/runtime/stubs.go#L34) 函数进行了声明，并无函数体，说明这个函数是使用汇编实现的。但这里我们并不需要关心它的具体实现，只要知道它的主要工作职责就可以了，所有信息我们都可以通过函数注释得知。

// mcall switches from the g to the g0 stack and invokes fn(g),
// where g is the goroutine that made the call.

// mcall函数用来从 g 切换到 g0 栈并调用 fn(g)函数，这里的 g 指发起调用的那个goroutine。

// 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 会将当前 g 的 PC/SP 信息到 g->sched，以便以后恢复执行
// 由 fn 函数来安排稍后的执行，一般是通过将g记录到一个数据结构中，以后再通过调用 ready(g) 进行唤醒

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

// 当 g 被重新调度后，mcall将返回原来的 g
// fn 不能返回，通常是在它调度结束后，直接让 m 运行其它的 goroutine

//
// mcall can only be called from g stacks (not g0, not gsignal).

// mcall 只能从 g 栈中发起调用，不能是 g0 或 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.

// fn 必须是 go:noescape（非逃逸函数）
// 如果 fn 是堆栈分配的一个闭包函数, 则 fn 函数将 g 放在一个runqueue 中，g并在fn返回之前执行，当仍在执行期间闭包将失效

func mcall(fn func(*g))

从上面的注释可看出来，mcall() 函数主要有来实现从 g 到 g0 的切换，对特殊的g0的切换过程，我们在 g0 特殊的goroutine 文章里已经讲过，每次 g 与 g 之间的切换都需要经过g0 来完成。

我们都知道goroutine的在golang中发挥了很大的作用，那么当我们创建一个新的goroutine时，它是怎么一步一步创建的呢？都经历了哪些操作呢？今天我们通过源码来剖析一下创建goroutine都经历了些什么？go version 1.15.6

对goroutine最关键的两个函数是 [newproc()](https://github.com/golang/go/blob/go1.15.6/src/runtime/proc.go#L3535-L3564) 和 [newproc1()](https://github.com/golang/go/blob/go1.15.6/src/runtime/proc.go#L3566-L3674)，而 newproc1() 函数是我们最需要关注的。

函数 newproc()

我们先看一个简单的创建goroutine的例子，找出来创建它的函数。

package main

func start(a, b, c int64) {
	_ = a + b + c
}

func main() {
	go start(7, 2, 5)
}

输出结果:

➜  gotest go tool compile -S main.go
"".start STEXT nosplit size=1 args=0x18 locals=0x0
        0x0000 00000 (main.go:3)        TEXT    "".start(SB), NOSPLIT|ABIInternal, $0-24
        0x0000 00000 (main.go:3)        FUNCDATA        $0, gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB)
        0x0000 00000 (main.go:3)        FUNCDATA        $1, gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB)
        0x0000 00000 (main.go:5)        RET
        0x0000 c3                                               .
"".main STEXT size=98 args=0x0 locals=0x30
        0x0000 00000 (main.go:7)        TEXT    "".main(SB), ABIInternal, $48-0
        0x0000 00000 (main.go:7)        MOVQ    (TLS), CX
        0x0009 00009 (main.go:7)        CMPQ    SP, 16(CX)
        0x000d 00013 (main.go:7)        PCDATA  $0, $-2
        0x000d 00013 (main.go:7)        JLS     90
        0x000f 00015 (main.go:7)        PCDATA  $0, $-1
        0x000f 00015 (main.go:7)        SUBQ    $48, SP
        0x0013 00019 (main.go:7)        MOVQ    BP, 40(SP)
        0x0018 00024 (main.go:7)        LEAQ    40(SP), BP
        0x001d 00029 (main.go:7)        FUNCDATA        $0, gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB)
        0x001d 00029 (main.go:7)        FUNCDATA        $1, gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB)
        0x001d 00029 (main.go:8)        MOVL    $24, (SP)
        0x0024 00036 (main.go:8)        LEAQ    "".start·f(SB), AX
        0x002b 00043 (main.go:8)        MOVQ    AX, 8(SP)
        0x0030 00048 (main.go:8)        MOVQ    $7, 16(SP)
        0x0039 00057 (main.go:8)        MOVQ    $2, 24(SP)
        0x0042 00066 (main.go:8)        MOVQ    $5, 32(SP)
        0x004b 00075 (main.go:8)        PCDATA  $1, $0
        0x004b 00075 (main.go:8)        CALL    runtime.newproc(SB)
        0x0050 00080 (main.go:9)        MOVQ    40(SP), BP
        0x0055 00085 (main.go:9)        ADDQ    $48, SP
        0x0059 00089 (main.go:9)        RET
        0x005a 00090 (main.go:9)        NOP
        0x005a 00090 (main.go:7)        PCDATA  $1, $-1
        0x005a 00090 (main.go:7)        PCDATA  $0, $-2
        0x005a 00090 (main.go:7)        CALL    runtime.morestack_noctxt(SB)
        0x005f 00095 (main.go:7)        PCDATA  $0, $-1
        0x005f 00095 (main.go:7)        NOP
        0x0060 00096 (main.go:7)        JMP     0
        0x0000 65 48 8b 0c 25 00 00 00 00 48 3b 61 10 76 4b 48  eH..%....H;a.vKH
        0x0010 83 ec 30 48 89 6c 24 28 48 8d 6c 24 28 c7 04 24  ..0H.l$(H.l$(..$
        0x0020 18 00 00 00 48 8d 05 00 00 00 00 48 89 44 24 08  ....H......H.D$.
        0x0030 48 c7 44 24 10 07 00 00 00 48 c7 44 24 18 02 00  H.D$.....H.D$...
        0x0040 00 00 48 c7 44 24 20 05 00 00 00 e8 00 00 00 00  ..H.D$ .........
        0x0050 48 8b 6c 24 28 48 83 c4 30 c3 e8 00 00 00 00 90  H.l$(H..0.......
        0x0060 eb 9e                                            ..
        rel 5+4 t=17 TLS+0
        rel 39+4 t=16 "".start·f+0
        rel 76+4 t=8 runtime.newproc+0
        rel 91+4 t=8 runtime.morestack_noctxt+0
go.cuinfo.packagename. SDWARFINFO dupok size=0
        0x0000 6d 61 69 6e                                      main
""..inittask SNOPTRDATA size=24
        0x0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        0x0010 00 00 00 00 00 00 00 00                          ........
"".start·f SRODATA dupok size=8
        0x0000 00 00 00 00 00 00 00 00                          ........
        rel 0+8 t=1 "".start+0
gclocals·33cdeccccebe80329f1fdbee7f5874cb SRODATA dupok size=8
        0x0000 01 00 00 00 00 00 00 00                          ........

通过使用 go tool compile -S main.go 命令输出的汇编我们基本可以看到有一个 [runtime.newproc()](https://github.com/golang/go/blob/go1.15.6/src/runtime/proc.go#L3535-L3564) 函数的调用（CALL 是汇编调用函数指令） ，这个正是runtime创建goroutine的关键函数。