1.Go有哪些数据类型

f

2.方法与函数的区别

在Go语言中，函数和方法不太一样，有明确的概念区分；函数是指不属于任何结构体、类型的方法，也就是说函数是没有接收者的；而方法是有接收者的。

3.方法值接收者和指针接收者的区别

如果方法的接收者是指针类型，无论调用者是对象还是对象指针，修改的都是对象本身，会影响调用者；
如果方法的接收者是值类型，无论调用者是对象还是对象指针，修改的都是对象的副本，不影响调用者；

4.函数返回局部变量的指针是否安全

一般来说，局部变量会在函数返回后被销毁，因此被返回的引用就成为了"无所指"的引用，程序会进入未知状态。
但这在 Go 中是安全的，Go 编译器将会对每个局部变量进行逃逸分析。如果发现局部变量的作用域超出该函数，则不会将内存分配在栈上，而是分配在堆上，因为他们不在栈区，即使释放函数，其内容也不会受影响。

5.函数参数传递是值传递还是引用传递

Go语言中所有的传参都是值传递（传值），都是一个副本，一个拷贝。
参数如果是非引用类型（int、string、struct等这些），这样就在函数中就无法修改原内容数据；如果是引用类型（指针、map、slice、chan等这些），这样就可以修改原内容数据。

6.defer关键字的实现原理

defer关键字的实现跟go关键字很类似，不同的是它调用的是runtime.deferproc而不是runtime.newproc。在defer出现的地方，插入了指令call runtime.deferproc，然后在函数返回之前的地方，插入指令call runtime.deferreturn。

7.内置函数make和new的区别

变量初始化，一般包括2步，变量声明 + 变量内存分配，var关键字就是用来声明变量的，new和make函数主要是用来分配内存的；
make 只能用来分配及初始化类型为slice、map、chan 的数据，并且返回类型本身。
new 可以分配任意类型的数据，并且置零，返回一个指向该类型内存地址的指针。

8.slice底层实现原理

切片是基于数组实现的，它的底层是数组，它自己本身非常小，可以理解为对 底层数组的抽象。因为基于数组实现，所以它的底层的内存是连续分配的，效 率非常高，还可以通过索引获得数据。
切片本身并不是动态数组或者数组指针。它内部实现的数据结构通过指针引用 底层数组，设定相关属性将数据读写操作限定在指定的区域内。切片本身是一 个只读对象，其工作机制类似数组指针的一种封装。

9.array和slice的区别

1）数组长度不同
数组初始化必须指定长度，并且长度就是固定的
切片的长度是不固定的，可以追加元素，在追加时可能使切片的容量增大
2）函数传参不同
数组是值类型，将一个数组赋值给另一个数组时，传递的是一份深拷贝，函数传参操作都会复制整个数组数据，会占用额外的内存，函数内对数组元素值的修改，不会修改原数组内容。
切片是引用类型，将一个切片赋值给另一个切片时，传递的是一份浅拷贝，函数传参操作不会拷贝整个切片，只会复制len和cap，底层共用同一个数组，不会占用额外的内存，函数内对数组元素值的修改，会修改原数组内容。
3）计算数组长度方式不同
数组需要遍历计算数组长度，时间复杂度为O(n)
切片底层包含len字段，可以通过len()计算切片长度，时间复杂度为O(1)

10.slice深拷贝和浅拷贝

深拷贝：拷贝的是数据本身，创造一个新对象，新创建的对象与原对象不共享内存，新创建的对象在内存中开辟一个新的内存地址，新对象值修改时不会影响原对象值
浅拷贝：拷贝的是数据地址，只复制指向的对象的指针，此时新对象和老对象指向的内存地址是一样的，新对象值修改时老对象也会变化

11.slice扩容机制

扩容会发生在slice append的时候，当slice的cap不足以容纳新元素，就会进行扩容，扩容规则如下：
如果新申请容量比两倍原有容量大，那么扩容后容量大小 为 新申请容量
如果原有 slice 长度小于 1024， 那么每次就扩容为原来的 2 倍
如果原 slice 长度大于等于 1024， 那么每次扩容就扩为原来的 1.25 倍
如果最终容量计算值溢出，则最终容量就是新申请容量

12.slice为什么不是线程安全的

slice底层结构并没有使用加锁等方式，不支持并发读写，所以并不是线程安全的，使用多个 goroutine 对类型为 slice 的变量进行操作，每次输出的值大概率都不会一样，与预期值不一致; slice在并发执行中不会报错，但是数据会丢失

13.map底层实现原理

Go中的map是一个指针，占用8个字节，指向hmap结构体
源码包中src/runtime/map.go定义了hmap的数据结构：
hmap包含若干个结构为bmap的数组，每个bmap底层都采用链表结构，bmap通常叫其bucket

14.map遍历为什么是无序的

主要原因有2点：

  • map在遍历时，并不是从固定的0号bucket开始遍历的，每次遍历，都会从一个随机值序号的bucket，再从其中随机的cell开始遍历
  • map遍历时，是按序遍历bucket，同时按需遍历bucket中和其overflow bucket中的cell。但是map在扩容后，会发生key的搬迁，这造成原来落在一个bucket中的key，搬迁后，有可能会落到其他bucket中了，从这个角度看，遍历map的结果就不可能是按照原来的顺序了

map 本身是无序的，且遍历时顺序还会被随机化，如果想顺序遍历 map，需要对 map key 先排序，再按照 key 的顺序遍历 map。

15.map为什么是非线程安全的

map默认是并发不安全的，同时对map进行并发读写时，程序会panic

16.map如何查找

Go 语言中读取 map 有两种语法：带 comma 和 不带 comma。当要查询的 key 不在 map 里，带 comma 的用法会返回一个 bool 型变量提示 key 是否在 map 中；而不带 comma 的语句则会返回一个 value 类型的零值。如果 value 是 int 型就会返回 0，如果 value 是 string 类型，就会返回空字符串。

// 不带 comma 用法
value := m["name"]
fmt.Printf("value:%s", value)

// 带 comma 用法
value, ok := m["name"]
if ok {
    fmt.Printf("value:%s", value)
}

17.map冲突的解决方式

比较常用的Hash冲突解决方案有链地址法和开放寻址法：
链地址法
当哈希冲突发生时，创建新单元，并将新单元添加到冲突单元所在链表的尾部。
开放寻址法
当哈希冲突发生时，从发生冲突的那个单元起，按照一定的次序，从哈希表中寻找一个空闲的单元，然后把发生冲突的元素存入到该单元。开放寻址法需要的表长度要大于等于所需要存放的元素数量

18.什么是负载因子?map的负载因子为什么是6.5

负载因子（load factor），用于衡量当前哈希表中空间占用率的核心指标，也就是每个 bucket 桶存储的平均元素个数。
Go 官方发现：装载因子越大，填入的元素越多，空间利用率就越高，但发生哈希冲突的几率就变大。反之，装载因子越小，填入的元素越少，冲突发生的几率减小，但空间浪费也会变得更多，而且还会提高扩容操作的次数。根据这份测试结果和讨论，Go 官方取了一个相对适中的值，把 Go 中的 map 的负载因子硬编码为 6.5，这就是 6.5 的选择缘由。这意味着在 Go 语言中，当 map存储的元素个数大于或等于 6.5 * 桶个数 时，就会触发扩容行为。

19.map如何扩容

双倍扩容：扩容采取了一种称为“渐进式”的方式，原有的 key 并不会一 次性搬迁完毕，每次最多只会搬迁 2 个 bucket。
等量扩容：重新排列，极端情况下，重新排列也解决不了，map 存储就会蜕 变成链表，性能大大降低，此时哈希因子 hash0 的设置，可以降低此类极 端场景的发生。

20.map和sync.Map谁的性能最好，为什么？

和原始map+RWLock的实现并发的方式相比，减少了加锁对性能的影响。它做了一些优化：可以无锁访问read map，而且会优先操作read map，倘若只操作read map就可以满足要求，那就不用去操作write map(dirty)，所以在某些特定场景中它发生锁竞争的频率会远远小于map+RWLock的实现方式，适合读多写少的场景。写多的场景，会导致 read map 缓存失效，需要加锁，冲突变多，性能急剧下降。

21.channel有什么特点

22.channel的底层实现原理

Go中的channel 是一个队列，遵循先进先出的原则，负责协程之间的通信（Go 语言提倡不要通过共享内存来通信，而要通过通信来实现内存共享，CSP(Communicating Sequential Process)并发模型，就是通过 goroutine 和 channel 来实现的）
通过var声明或者make函数创建的channel变量是一个存储在函数栈帧上的指针，占用8个字节，指向堆上的hchan结构体

23.channel有无缓冲的区别

不带缓冲的channel是同步的，带缓冲的channel是异步的。
不带缓冲的channel中，每一个发送者与接收者都会阻塞当前线程，只有当接受者与发送者都准备就绪了，channel才能正常使用。
带缓冲的channel并不能无限的接收数据而不造成阻塞，能够接收的数据的个数取决于channel定义时，设定的缓冲的大小，只有在这个缓冲大小范围之内，channel的发送才不会造成阻塞。

24.channel为什么是线程安全的

不同协程通过channel进行通信，本身的使用场景就是多线程，为了保证数据的一致性，必须实现线程安全。
因此channel的底层实现中，hchan结构体中采用Mutex锁来保证数据读写安全。在对循环数组buf中的数据进行入队和出队操作时，必须先获取互斥锁，才能操作channel数据

25.channel如何控制goroutine并发执行程序

使用channel进行通信通知，用channel去传递信息，从而控制并发执行顺序

26.channe共享内存有什么优劣势

在这里插入图片描述
Go 引入了 Channel 和 Goroutine 实现 CSP 模型将生产者和消费者进行了解耦，Channel 其实和消息队列很相似。
优点：使用 channel 可以帮助我们解耦生产者和消费者，可以降低并发当中的耦合
缺点：容易死锁

27.channel发送和接受什么情况下会死锁

死锁：

  • 单个协程永久阻塞
  • 两个或两个以上的协程的执行过程中，由于竞争资源或由于彼此通信而造成的一种阻塞的现象。

channel死锁场景：

  • 非缓存channel只写不读
  • 非缓存channel读在写后面
  • 缓存channel写入超过缓冲区数量
  • 空读
  • 多个协程互相等待

28.Go 互斥锁的实现原理

参考：GO互斥锁实现原理剖析
Go sync包提供了两种锁类型：互斥锁sync.Mutex 和 读写互斥锁sync.RWMutex，都属于悲观锁。
概念：Mutex是互斥锁，当一个 goroutine 获得了锁后，其他 goroutine 不能获取锁（只能存在一个写者或读者，不能同时读和写）
互斥锁对应的是底层结构是sync.Mutex结构体

type Mutex struct {  
     state int32     
     sema  uint32
 }

state表示锁的状态，有锁定、被唤醒、饥饿模式等，并且是用state的二进制位来标识的，不同模式下会有不同的处理方式
sema表示信号量，mutex阻塞队列的定位是通过这个变量来实现的，从而实现goroutine的阻塞和唤醒

29.互斥锁正常模式和饥饿模式的区别

正常模式(非公平锁)
在刚开始的时候，是处于正常模式（Barging），也就是，当一个G1持有着一个锁的时候，G2会自旋的去尝试获取这个锁
当自旋超过4次还没有能获取到锁的时候，这个G2就会被加入到获取锁的等待队列里面，并阻塞等待唤醒
正常模式下，所有等待锁的 goroutine 按照 FIFO(先进先出)顺序等待。唤醒的goroutine 不会直接拥有锁，而是会和新请求锁的 goroutine 竞争锁。新请求锁的 goroutine 具有优势：它正在 CPU 上执行，而且可能有好几个，所以刚刚唤醒的 goroutine 有很大可能在锁竞争中失败，长时间获取不到锁，就会切换到饥饿模式
饥饿模式(公平锁)
当一个 goroutine 等待锁时间超过 1 毫秒时，它可能会遇到饥饿问题。 在版本1.9中，这种场景下Go Mutex 切换到饥饿模式（handoff），解决饥饿问题。

starving = runtime_nanotime()-waitStartTime > 1e6

饥饿模式下，直接把锁交给等待队列中排在第一位的goroutine(队头)，同时饥饿模式下，新进来的goroutine不会参与抢锁也不会进入自旋状态，会直接进入等待队列的尾部,这样很好的解决了老的goroutine一直抢不到锁的场景。
那么也不可能说永远的保持一个饥饿的状态，总归会有吃饱的时候，也就是总有那么一刻Mutex会回归到正常模式，那么回归正常模式必须具备的条件有以下几种：

  1. G的执行时间小于1ms
  2. 等待队列已经全部清空了

30.互斥锁允许自旋的条件

线程没有获取到锁时常见有2种处理方式：

  • 一种是没有获取到锁的线程就一直循环等待判断该资源是否已经释放锁，这种锁也叫做自旋锁，它不用将线程阻塞起来， 适用于并发低且程序执行时间短的场景，缺点是cpu占用较高
  • 另外一种处理方式就是把自己阻塞起来，会释放CPU给其他线程，内核会将线程置为「睡眠」状态，等到锁被释放后，内核会在合适的时机唤醒该线程，适用于高并发场景，缺点是有线程上下文切换的开销

允许自旋的条件：

  • 锁已被占用，并且锁不处于饥饿模式。
  • 积累的自旋次数小于最大自旋次数（active_spin=4）。
  • cpu 核数大于 1。
  • 有空闲的 P。
  • 当前 goroutine 所挂载的 P 下，本地待运行队列为空。

31.Go 读写锁的实现原理

读写互斥锁RWMutex，是对Mutex的一个扩展，当一个 goroutine 获得了读锁后，其他 goroutine可以获取读锁，但不能获取写锁；当一个 goroutine 获得了写锁后，其他 goroutine既不能获取读锁也不能获取写锁（只能存在一个写者或多个读者，可以同时读）
底层实现结构

type RWMutex struct {
    w           Mutex  // 复用互斥锁
    writerSem   uint32 // 信号量，用于写等待读
    readerSem   uint32 // 信号量，用于读等待写
    readerCount int32  // 当前执行读的 goroutine 数量
    readerWait  int32  // 被阻塞的准备读的 goroutine 的数量
}

实现方法

func (rw *RWMutex) RLock() // 加读锁
func (rw *RWMutex) RUnlock() // 释放读锁
func (rw *RWMutex) Lock() // 加写锁
func (rw *RWMutex) Unlock() // 释放写锁

加读锁 调用atomic.AddInt32(&rw.readerCount, 1) 这个原子方法，对当前在读的数量加1，如果返回负数，那么说明当前有其他写锁，这时候就调用 runtime_SemacquireMutex 休眠当前goroutine 等待被唤醒
释放读锁 解锁的时候对正在读的操作减1，如果返回值小于 0 那么说明当前有在写的操作，这个时候调用 rUnlockSlow 进入慢速通道。被阻塞的准备读的 goroutine 的数量减1，readerWait 为 0，就表示当前没有正在准备读的 goroutine 这时候调用 runtime_Semrelease 唤醒写操作
加写锁 首先调用互斥锁的 lock，获取到互斥锁之后，如果计算之后当前仍然有其他 goroutine 持有读锁，那么就调用 runtime_SemacquireMutex 休眠当前的 goroutine 等待所有的读操作完成。ReaderCount 原子性加上一个很大的负数，是防止后面的协程能拿到读锁，阻塞读
释放写锁 解锁的操作，会先调用 atomic.AddInt32(&rw.readerCount, rwmutexMaxReaders) 将恢复之前写入的负数，然后根据当前有多少个读操作在等待，循环唤醒
互斥锁和读写锁的区别：

  • 读写锁区分读者和写者，而互斥锁不区分
  • 互斥锁同一时间只允许一个线程访问该对象，无论读写；读写锁同一时间内只允许一个写者，但是允许多个读者同时读对象。

32.Go 原子操作有哪些？

原子操作仅会由一个独立的CPU指令代表和完成。原子操作是无锁的，常常直接通过CPU指令直接实现。 事实上，其它同步技术的实现常常依赖于原子操作。
当我们想要对某个变量并发安全的修改，除了使用官方提供的 mutex，还可以使用 sync/atomic 包的原子操作，它能够保证对变量的读取或修改期间不被其他的协程所影响。
atomic 包提供的原子操作能够确保任一时刻只有一个goroutine对变量进行操作，善用 atomic 能够避免程序中出现大量的锁操作。
常见操作：

  • 增减Add
  • 载入Load
  • 比较并交换CompareAndSwap
  • 交换Swap
  • 存储Store

33.原子操作和锁的区别

原子操作由底层硬件支持，而锁是基于原子操作+信号量完成的。若实现相同的功能，前者通常会更有效率

原子操作是单个指令的互斥操作；互斥锁/读写锁是一种数据结构，可以完成临界区（多个指令）的互斥操作，扩大原子操作的范围

原子操作是无锁操作，属于乐观锁；说起锁的时候，一般属于悲观锁

原子操作存在于各个指令/语言层级，比如“机器指令层级的原子操作”，“汇编指令层级的原子操作”，“Go语言层级的原子操作”等。

锁也存在于各个指令/语言层级中，比如“机器指令层级的锁”，“汇编指令层级的锁”，“Go语言层级的锁”等

34.goroutine的底层实现原理

Goroutine可以理解为一种Go语言的协程（轻量级线程），是Go支持高并发的基础，属于用户态的线程，由Go runtime管理而不是操作系统。
goroutine 本身只是一个数据结构，真正让 goroutine 运行起来的是调度器。Go 实现了一个用户态的调度器（GMP模型），这个调度器充分利用现代计算机的多核特性，同时让多个 goroutine 运行，同时 goroutine 设计的很轻量级，调度和上下文切换的代价都比较小。

35.goroutine和线程的区别

goroutine线程
内存占用创建一个 goroutine 的栈内存消耗为 2 KB，实际运行过程中，如果栈空间不够用，会自动进行扩容创建一个 线程 的栈内存消耗为 1 MB
创建和销毀goroutine 因为是由 Go runtime 负责管理的，创建和销毁的消耗非常小，是用户级。线程 创建和销毀都会有巨大的消耗，因为要和操作系统打交道，是内核级的，通常解决的办法就是线程池
切换goroutines 切换只需保存三个寄存器：PC、SP、BP；goroutine 的切换约为 200 ns，相当于 2400-3600 条指令。当线程切换时，需要保存各种寄存器，以便恢复现场。线程切换会消耗 1000-1500 ns，相当于 12000-18000 条指令。

36.goroutine泄露的场景

泄露原因

  • Goroutine 内进行channel/mutex 等读写操作被一直阻塞。
  • Goroutine 内的业务逻辑进入死循环，资源一直无法释放。
  • Goroutine 内的业务逻辑进入长时间等待，有不断新增的 Goroutine 进入等待

泄露场景

  • 如果输出的 goroutines 数量是在不断增加的，就说明存在泄漏

37.如何查看正在执行的goroutine数量

程序中引入pprof pakage并开启HTTP监听服务：

package main

import (
    "net/http"
    _ "net/http/pprof"
)

func main() {

    for i := 0; i < 100; i++ {
        go func() {
            select {}
        }()
    }

    go func() {
        http.ListenAndServe("localhost:6060", nil)
    }()

    select {}
}

在命令行下执行：

go tool pprof -http=:1248 http://127.0.0.1:6060/debug/pprof/goroutine

39.如何控制并发的goroutine数量

在开发过程中，如果不对goroutine加以控制而进行滥用的话，可能会导致服务整体崩溃。比如耗尽系统资源导致程序崩溃，或者CPU使用率过高导致系统忙不过来。因此，我们需要控制goroutine数量。
我们可以通过WaitGroup启动指定数量的goroutine，监听channel的通知。发送者推送信息到channel，信息处理完了，关闭channel,等待goroutine依次退出。

var (
 // channel长度
 poolCount      = 5
 // 复用的goroutine数量
 goroutineCount = 10
)
 
func pool() {
 jobsChan := make(chan int, poolCount)
 
 // workers
 var wg sync.WaitGroup
 for i := 0; i < goroutineCount; i++ {
  wg.Add(1)
  go func() {
   defer wg.Done()
   for item := range jobsChan {
    // ...
    fmt.Println(item)
   }
  }()
 }
 
 // senders
 for i := 0; i < 1000; i++ {
  jobsChan <- i
 }
 
 // 关闭channel，上游的goroutine在读完channel的内容，就会通过wg的done退出
 close(jobsChan)
 wg.Wait()
}

40.Go 线程实现模型

线程实现模型主要分为：内核级线程模型（1：1）、用户级线程模型（N：1）、两级线程模型（M：N），他们的区别在于用户线程与内核线程之间的对应关系。
Go实现的是两级线程模型（M：N)，准确的说是GMP模型，是对两级线程模型的改进实现，使它能够更加灵活地进行线程之间的调度。

41.GMP和GM模型

Go采用了GMP模型（对两级线程模型的改进实现），使它能够更加灵活地进行线程之间的调度
GMP模型
GMP是Go运行时调度层面的实现，包含4个重要结构，分别是G、M、P、Sched

  • G（Goroutine）：代表Go 协程Goroutine，存储了 Goroutine 的执行栈信息、Goroutine 状态以及 Goroutine 的任务函数等。G的数量无限制，理论上只受内存的影响，创建一个 G 的初始栈大小为2-4K，配置一般的机器也能简简单单开启数十万个 Goroutine ，而且Go语言在 G 退出的时候还会把 G 清理之后放到 P 本地或者全局的闲置列表 gFree 中以便复用。

  • M（Machine）： Go 对操作系统线程（OS thread）的封装，可以看作操作系统内核线程，想要在 CPU 上执行代码必须有线程，通过系统调用 clone 创建。M在绑定有效的 P 后，进入一个调度循环，而调度循环的机制大致是从 P 的本地运行队列以及全局队列中获取 G，切换到 G 的执行栈上并执行 G 的函数，调用 goexit 做清理工作并回到 M，如此反复。M 并不保留 G 状态，这是 G 可以跨 M 调度的基础。M的数量有限制，默认数量限制是 10000，可以通过 debug.SetMaxThreads() 方法进行设置，如果有M空闲，那么就会回收或者睡眠。

  • P（Processor）：虚拟处理器，M执行G所需要的资源和上下文，只有将 P 和 M 绑定，才能让 P 的 runq 中的 G 真正运行起来。P 的数量决定了系统内最大可并行的 G 的数量，**P的数量受本机的CPU核数影响，可通过环境变量$GOMAXPROCS或在runtime.GOMAXPROCS()来设置，默认为CPU核心数。

  • Sched：调度器结构，它维护有存储M和G的全局队列，以及调度器的一些状态信息**

GM模型
Go早期是GM模型，没有P组件

42.Go 调度原理

CPU感知不到Goroutine，只知道内核线程，所以需要Go调度器将协程调度到内核线程上面去，然后操作系统调度器将内核线程放到CPU上去执行
M是对内核级线程的封装，所以Go调度器的工作就是将G分配到M
Go 调度器的实现不是一蹴而就的，它的调度模型与算法也是几经演化，从最初的 GM 模型、到 GMP模型，从不支持抢占，到支持协作式抢占，再到支持基于信号的异步抢占，经历了不断地优化与打磨。

43.Go work stealing 机制

获取 P 本地队列，当从绑定 P 本地 runq 上找不到可执行的 g，尝试从全局链 表中拿，再拿不到从 netpoll 和事件池里拿，最后会从别的 P 里偷任务。P 此时去唤醒一个 M。P 继续执行其它的程序。M 寻找是否有空闲的 P，如果有则 将该 G 对象移动到它本身。接下来 M 执行一个调度循环（调用 G 对象->执行-> 清理线程→继续找新的 Goroutine 执行）

44.Go hand off 机制

也称为P分离机制，当本线程 M 因为 G 进行的系统调用阻塞时，线程释放绑定的 P，把 P 转移给其他空闲的 M 执行，也提高了线程利用率

45.Go抢占式调度

在1.2版本之前，Go的调度器仍然不支持抢占式调度，程序只能依靠Goroutine主动让出CPU资源才能触发调度，这会引发一些问题，比如：

  • 某些 Goroutine 可以长时间占用线程，造成其它 Goroutine 的饥饿
  • 垃圾回收器是需要stop the world的，如果垃圾回收器想要运行了，那么它必须先通知其它的goroutine停下来，这会造成较长时间的等待时间

为解决这个问题：

  • Go 1.2 中实现了基于协作的“抢占式”调度
  • Go 1.14 中实现了基于信号的“抢占式”调度

基于协作的抢占式调度

协作式：大家都按事先定义好的规则来，比如：一个goroutine执行完后，退出，让出p，然后下一个goroutine被调度到p上运行。这样做的缺点就在于 是否让出p的决定权在groutine自身。一旦某个g不主动让出p或执行时间较长，那么后面的goroutine只能等着，没有方法让前者让出p，导致延迟甚至饿死。

非协作式: 就是由runtime来决定一个goroutine运行多长时间，如果你不主动让出，对不起，我有手段可以抢占你，把你踢出去，让后面的goroutine进来运行。
基于协作的抢占式调度流程：

  • 编译器会在调用函数前插入 runtime.morestack，让运行时有机会在这段代码中检查是否需要执行抢占调度
  • Go语言运行时会在垃圾回收暂停程序、系统监控发现 Goroutine 运行超过 10ms，那么会在这个协程设置一个抢占标记
  • 当发生函数调用时，可能会执行编译器插入的 runtime.morestack，它调用的 runtime.newstack会检查抢占标记，如果有抢占标记就会触发抢占让出cpu，切到调度主协程里

这种解决方案只能说局部解决了“饿死”问题，只在有函数调用的地方才能插入“抢占”代码（埋点），对于没有函数调用而是纯算法循环计算的 G，Go 调度器依然无法抢占。
为了解决这些问题，Go 在 1.14 版本中增加了对非协作的抢占式调度的支持，这种抢占式调度是基于系统信号的，也就是通过向线程发送信号的方式来抢占正在运行的 Goroutine

基于信号的抢占式调度

真正的抢占式调度是基于信号完成的，所以也称为“异步抢占”。不管协程有没有意愿主动让出 cpu 运行权，只要某个协程执行时间过长，就会发送信号强行夺取 cpu 运行权。

  • M 注册一个 SIGURG 信号的处理函数：sighandler
  • sysmon启动后会间隔性的进行监控，最长间隔10ms，最短间隔20us。如果发现某协程独占P超过10ms，会给M发送抢占信号
  • M 收到信号后，内核执行 sighandler 函数把当前协程的状态从_Grunning正在执行改成 _Grunnable可执行，把抢占的协程放到全局队列里，M继续寻找其他 goroutine 来运行
  • 被抢占的 G 再次调度过来执行时，会继续原来的执行流

46.Go如何查看运行时调度信息

有 2 种方式可以查看一个程序的调度GMP信息，分别是go tool trace和GODEBUG

47.Go内存分配机制

Go语言内置运行时（就是runtime），抛弃了传统的内存分配方式，改为自主管理。这样可以自主地实现更好的内存使用模式，比如内存池、预分配等等。这样，不会每次内存分配都需要进行系统调用。
设计思想

  • 内存分配算法采用Google的TCMalloc算法，每个线程都会自行维护一个独立的内存池，进行内存分配时优先从该内存池中分配，当内存池不足时才会向加锁向全局内存池申请，减少系统调用并且避免不同线程对全局内存池的锁竞争
  • 把内存切分的非常的细小，分为多级管理，以降低锁的粒度
  • 回收对象内存时，并没有将其真正释放掉，只是放回预先分配的大块内存中，以便复用。只有内存闲置过多的时候，才会尝试归还部分内存给操作系统，降低整体开销

Go的内存管理组件主要有：mspan、mcache、mcentral和mheap

48.Go内存逃逸机制

概念
在一段程序中，每一个函数都会有自己的内存区域存放自己的局部变量、返回地址等，这些内存会由编译器在栈中进行分配，每一个函数都会分配一个栈桢，在函数运行结束后进行销毁，但是有些变量我们想在函数运行结束后仍然使用它，那么就需要把这个变量在堆上分配，这种从"栈"上逃逸到"堆"上的现象就成为内存逃逸。

在栈上分配的地址，一般由系统申请和释放，不会有额外性能的开销，比如函数的入参、局部变量、返回值等。在堆上分配的内存，如果要回收掉，需要进行 GC，那么GC 一定会带来额外的性能开销。编程语言不断优化GC算法，主要目的都是为了减少 GC带来的额外性能开销，变量一旦逃逸会导致性能开销变大。
逃逸机制
编译器会根据变量是否被外部引用来决定是否逃逸：

  • 如果函数外部没有引用，则优先放到栈中；
  • 如果函数外部存在引用，则必定放到堆中;
  • 如果栈上放不下，则必定放到堆上;

总结

  1. 栈上分配内存比在堆中分配内存效率更高
  2. 栈上分配的内存不需要 GC 处理，而堆需要
  3. 逃逸分析目的是决定内分配地址是栈还是堆
  4. 逃逸分析在编译阶段完成

因为无论变量的大小，只要是指针变量都会在堆上分配，所以对于小变量我们还是使用传值效率（而不是传指针）更高一点。

49.Go内存对齐机制

为了能让CPU可以更快的存取到各个字段，Go编译器会帮你把struct结构体做数据的对齐。所谓的数据对齐，是指内存地址是所存储数据大小（按字节为单位）的整数倍，以便CPU可以一次将该数据从内存中读取出来。 编译器通过在结构体的各个字段之间填充一些空白已达到对齐的目的。
对齐原则：

  • 结构体变量中成员的偏移量必须是成员大小的整数倍
  • 整个结构体的地址必须是最大字节的整数倍（结构体的内存占用是1/4/8/16byte…)