二、调度模型
golang操作内核线程
在此模型下的用户线程与内核线程一一对应,也就是说完全接管了用户线程,它也属于内核的一部分,统一由调度器来创建、终止和切换。这样就能完全发挥出多核的优势,多个线程可以跑在不同的CPU上,实现真正的并行。但也正由于一切都由内核来调度,这样大大增加了工作量,线程的切换是非常耗时的,而且创建也很用到更多的资源,所以也大大减少能创建线程的数量。由于是一对一的关系所以也叫(1:1)线程实现。
讲一讲GMP模型
- G(Goroutine):G 就是我们所说的 Go 语言中的协程 Goroutine 的缩写,相当于操作系统中的进程控制块。其中存着 goroutine 的运行时栈信息,CPU 的一些寄存器的值以及执行的函数指令等。
- M(Machine):代表一个操作系统的主线程,对内核级线程的封装,数量对应真实的 CPU 数。一个 M 直接关联一个 os 内核线程,用于执行 G。M 会优先从关联的 P 的本地队列中直接获取待执行的 G。M 保存了 M 自身使用的栈信息、当前正在 M上执行的 G 信息、与之绑定的 P 信息。
- P(Processor):Processor 代表了 M 所需的上下文环境,代表 M 运行 G 所需要的资源。是处理用户级代码逻辑的处理器,可以将其看作一个局部调度器使 go 代码在一个线程上跑。当 P 有任务时,就需要创建或者唤醒一个系统线程来执行它队列里的任务,所以 P 和 M 是相互绑定的。总的来说,P 可以根据实际情况开启协程去工作,它包含了运行 goroutine 的资源,如果线程想运行 goroutine,必须先获取 P,P 中还包含了可运行的 G 队列。
能开多少个M由什么决定
- 由于M必须持有一个P才可以运行Go代码,所以同时运行的M个数,也即线程数一般等同于CPU的个数,以达到尽可能的使用CPU而又不至于产生过多的线程切换开销。
- P的个数默认等于CPU核数,每个M必须持有一个P才可以执行G,一般情况下M的个数会略大于P的个数,这多出来的M将会在G产生系统调用时发挥作用。
- Go语⾔本身是限定M的最⼤量是10000,可以在runtime/debug包中的SetMaxThreads函数来修改设置。
能开多少个P由什么决定
- P的个数在程序启动时决定,默认情况下等同于CPU的核数。
- 程序中可以使用 runtime.GOMAXPROCS() 设置P的个数,在某些IO密集型的场景下可以在一定程度上提高性能。
- 一般来讲,程序运行时就将GOMAXPROCS大小设置为CPU核数,可让Go程序充分利用CPU。在某些IO密集型的应用里,这个值可能并不意味着性能最好。理论上当某个Goroutine进入系统调用时,会有一个新的M被启用或创建,继续占满CPU。但由于Go调度器检测到M被阻塞是有一定延迟的,也即旧的M被阻塞和新的M得到运行之间是有一定间隔的,所以在IO密集型应用中不妨把GOMAXPROCS设置的大一些,或许会有好的效果。
golang调度能不能不要P
第一版
1.介绍golang调度器中P是什么?
Processor的简称,处理器,上下文。
2.简述p的功能与为什么必须要P
它的主要用途就是用来执行goroutine的,它维护了一个goroutine队列。Processor是让咱们从N:1调度到M:N调度的重要部分。
第二版
在 Go 语言中,P(Processor)是调度器的一部分,用于管理和执行 goroutine。每个 P 都有一个固定的系统线程(OS thread)关联,用于在该线程上执行 goroutine。P 的存在是为了协调调度器和系统线程之间的关系,它充当了调度器和操作系统之间的中间层。P 的作用包括:
- 调度:P 负责将 goroutine 分配给系统线程执行,并在系统线程空闲时重新分配。
- Goroutine 栈管理:P 管理 goroutine 的栈空间,包括分配和回收。
- 垃圾回收:P 参与垃圾回收过程,协助标记和清理不再使用的内存。
由于 Go 语言的调度器是基于 M:N 模型实现的,即将 M 个 goroutine 关联到 N 个系统线程上执行,因此不能直接在没有 P 的情况下运行 goroutine。
为什么GMP这么快
谈到 Go 语言调度器,绕不开操作系统,进程与线程这些概念。线程是操作系统调度的最小单元,而 Linux 调度器并不区分进程和线程的调度,它们在不同操作系统上的实现也不同,但是在大多数实现中线程属于进程。多个线程可以属于同一个进程并共享内存空间。因为多线程不需要创建新的虚拟内存空间,所以它们也不需要内存管理单元处理上下文的切换,线程之间的通信也正是基于共享内存进行的,与重量级进程相比,线程显得比较轻量。虽然线程比较轻量,但是在调度时也有比较大的额外开销。每个线程会都占用 1MB 以上的内存空间,在切换线程时不止会消耗较多内存,恢复寄存器中的内存还需要向操作系统申请或者销毁资源。每一个线程上下文的切换都需要消耗 1 us 的时间,而 Go 调度器对 Goroutine 的上下文切换越为 0.2us,减少了 80% 的额外开销。Go 语言的调度器使用与 CPU 数量相等的线程来减少线程频繁切换带来的内存开销,同时在每一个线程上执行额外开销更低的 Goroutine 来降低操作系统和硬件的负载。
GMP调度过程
- 我们通过 go func()来创建一个goroutine;
- 有两个存储G的队列,一个是局部调度器P的本地队列、一个是全局G队列。新创建的G会先保存在P的本地队列中,如果P的本地队列已经满了就会保存在全局的队列中;
- G只能运行在M中,一个M必须持有一个P,M与P是1:1的关系。M会从P的本地队列弹出一个可执行状态的G来执行,如果P的本地队列为空,会从全局队列拿P,如果全局队列也为空,就会向其他的MP组合偷取一个可执行的G来执行;
- 一个M调度G执行的过程是一个循环机制;
- 当M执行某一个G时候如果发生了syscall或则其余阻塞操作,M会阻塞,如果当前有一些G在执行,runtime会把这个线程M从P中摘除(detach),然后再创建一个新的操作系统的线程(如果有空闲的线程可用就复用空闲线程)来服务于这个P;
- 当M系统调用结束时候,这个G会尝试获取一个空闲的P执行,并放入到这个P的本地队列。如果获取不到P,那么这个线程M变成休眠状态, 加入到空闲线程中,然后这个G会被放入全局队列中。
两种类型的队列
- 本地队列:本地的队列是无锁的,没有数据竞争问题,处理速度比较高。
- 全局队列:是用来平衡不同的P的任务数量,所有的M共享P的全局队列。
- 全局G队列(Global Queue):存放等待运⾏的G。
- P的本地G队列:同全局队列类似,存放的也是等待运⾏的G,存的数量有限,不超过256个。 新建G时,G优先加入到P的本地队列,如果队列满了,则会把本地队列中⼀半的G移动到全局队列
- P列表:所有的P都在程序启动时创建,并保存在数组中,最多有 GOMAXPROCS(可配置)个。可通过 runtime.GOMAXPROCS() 来进⾏设置,1.5版本之前默认为1,使⽤单核⼼执⾏,之后默认为最⼤逻辑cpu数量,即默认有最⼤逻辑cpu数量个P。
- M列表:当前操作系统分配给golang程序的内核线程数。线程想运⾏任务就得获取P,从P的本地队列获取G,P队列为空时,M会优先尝试从全局队列拿⼀批G放到P的本地队列,或从其他P的本地队列偷⼀半放到⾃⼰P的本地队列。M运⾏G,G执⾏之后,M会从P获取下⼀个G,不断重复下去。 Goroutine调度器和OS调度器是通过M结合起来的,每个M都代表了1个内核线程,OS调度器负责把内核线程分配到CPU的。
g阻塞,g,m,p发生什么
当g阻塞时,p会和m解绑,去寻找下一个可用的m。 g&m在阻塞结束之后会优先寻找之前的p,如果此时p已绑定其他m,当前m会进入休眠,g以可运行的状态进入全局队列。
为什么P的local queue可无锁访问,任务窃取的时候要加锁吗?
绑定在P上的local queue是顺序执行的,不存在执行状态的G协程抢占,所以可以无锁访问。任务窃取也是窃取其他P上等待状态的G协程,所以也可以不用加锁。
go调度中阻塞的方式
- 由于原子、互斥量或通道操作调用导致 Goroutine 阻塞,调度器将把当前阻塞的 Goroutine 切换出去,重新调度 LRQ 上的其他 Goroutine;
- 由于网络请求和 IO 操作导致 Goroutine 阻塞。Go 程序提供了网络轮询器(NetPoller)来处理网络请求和 IO 操作的问题,其后台通过 kqueue(MacOS),epoll(Linux)或 iocp(Windows)来实现 IO 多路复用。通过使用 NetPoller 进行网络系统调用,调度器可以防止 Goroutine 在进行这些系统调用时阻塞 M。这可以让 M 执行 P 的 LRQ 中其他的 Goroutines,而不需要创建新的 M。执行网络系统调用不需要额外的 M,网络轮询器使用系统线程,它时刻处理一个有效的事件循环,有助于减少操作系统上的调度负载。用户层眼中看到的 Goroutine 中的“block socket”,实现了 goroutine-per-connection 简单的网络编程模式。实际上是通过 Go runtime 中的 netpoller 通过 Non-block socket + I/O 多路复用机制“模拟”出来的。
- 当调用一些系统方法的时候(如文件 I/O),如果系统方法调用的时候发生阻塞,这种情况下,网络轮询器(NetPoller)无法使用,而进行系统调用的 G1 将阻塞当前 M1。调度器引入 其它M 来服务 M1 的P。
- 如果在 Goroutine 去执行一个 sleep 操作,导致 M 被阻塞了。Go 程序后台有一个监控线程 sysmon,它监控那些长时间运行的 G 任务然后设置可以强占的标识符,别的 Goroutine 就可以抢先进来执行。
具体的调度策略
Go的调度器内部有三个重要的结构,G(代表一个goroutine,它有自己的栈),M(Machine,代表内核级线程),P(Processor([prɑːsesər]),上下文处理器,它的主要用途就是用来连接执行的goroutine和内核线程的,定义在源码的src/runtime/runtime.h文件中) -G代表一个goroutine对象,每次go调用的时候,都会创建一个G对象 -M代表一个线程,每次创建一个M的时候,都会有一个底层线程创建;所有的G任务,最终还是在M上执行 -P代表一个处理器,每一个运行的M都必须绑定一个P,就像线程必须在每一个CPU核上执行一样 一个M对应一个P,一个P下面挂多个G,但同一时间只有一个G在跑,其余都是放入等待队列(runqueue([kjuː]))。 当一个P的队列消费完了就去全局队列里取,如果全局队列里也消费完了会去其他P的队列里抢任务(所以需要单独存储下一个 g 的地址,而不是从队列里获取)。
同时启动一万个G如何调度
首先一万个G会按照P的设定个数,尽量平均地分配到每个P的本地队列中。如果所有本地队列都满了,那么剩余的G则会分配到GMP的全局队列上。接下来便开始执行GMP模型的调度策略:
- 本地队列轮转:每个P维护着一个包含G的队列,不考虑G进入系统调用或IO操作的情况下,P周期性的将G调度到M中执行,执行一小段时间,将上下文保存下来,然后将G放到队列尾部,然后从队首中重新取出一个G进行调度。
- 系统调用:上面说到P的个数默认等于CPU核数,每个M必须持有一个P才可以执行G,一般情况下M的个数会略大于P的个数,这多出来的M将会在G产生系统调用时发挥作用。当该G即将进入系统调用时,对应的M由于陷入系统调用而进被阻塞,将释放P,进而某个空闲的M1获取P,继续执行P队列中剩下的G。
- 工作量窃取:多个P中维护的G队列有可能是不均衡的,当某个P已经将G全部执行完,然后去查询全局队列,全局队列中也没有新的G,而另一个M中队列中还有3很多G待运行。此时,空闲的P会将其他P中的G偷取一部分过来,一般每次偷取一半。
抢占式调度及goroutine泄漏
go的抢占式调度
在1.1 版本中的调度器是不支持抢占式调度的,程序只能依靠 Goroutine 主动让出 CPU 资源才能触发调度。Go 语言的调度器在 1.2 版本中引入基于协作的抢占式调度,解决了以下的问题:
- 某些 Goroutine 可以长时间占用线程,造成其它 Goroutine 的饥饿;
- 垃圾回收需要暂停整个程序(Stop-the-world,STW),最长可能需要几分钟的时间,导致整个程序无法工作;
1.2 版本的抢占式调度虽然能够缓解这个问题,但是它实现的抢占式调度是基于协作的,在之后很长的一段时间里 Go 语言的调度器都有一些无法被抢占的边缘情况,例如:for 循环或者垃圾回收长时间占用线程,这些问题中的一部分直到 1.14 才被基于信号的抢占式调度解决。 抢占式分为两种:
- 协作式的抢占式调度
- 基于信号的抢占式调度
Goroutine 泄露
Goroutine 作为一种逻辑上理解的轻量级线程,需要维护执行用户代码的上下文信息。在运行过程中也需要消耗一定的内存来保存这类信息,而这些内存在目前版本的 Go 中是不会被释放的。因此,如果一个程序持续不断地产生新的 goroutine、且不结束已经创建的 goroutine 并复用这部分内存,就会造成内存泄漏的现象。造成泄露的大多数原因有以下三种:
- Goroutine 内正在进行 channel/mutex 等读写操作,但由于逻辑问题,某些情况下会被一直阻塞。
- Goroutine 内的业务逻辑进入死循环,资源一直无法释放。
- Goroutine 内的业务逻辑进入长时间等待,有不断新增的 Goroutine 进入等待。
P和M的数量一定是1:1吗?如果一个G阻塞了会怎么样?
不一定,M必须持有P才可以执行代码,跟系统中的其他线程一样,M也会被系统调用阻塞。P的个数在启动程序时决定,默认情况下等于CPU的核数,可以使用环境变量GOMAXPROCS或在程序中使用runtime.GOMAXPROCS()方法指定P的个数。 M的个数通常稍大于P的个数,因为除了运行Go代码,runtime包还有其他内置任务需要处理。
一个协程挂起换入另外一个协程是什么过程?
对于进程、线程,都是有内核进行调度,有CPU时间片的概念,进行抢占式调度。协程,又称微线程,纤程。英文名Coroutine。协程的调用有点类似子程序,如程序A调用了子程序B,子程序B调用了子程序C,当子程序C结束了返回子程序B继续执行之后的逻辑,当子程序B运行结束了返回程序A,直到程序A运行结束。但是和子程序相比,协程有挂起的概念,协程可以挂起跳转执行其他协程,合适的时机再跳转回来。 本质上goroutine就是协程,但是完全运行在用户态,采用了MPG模型:
M:内核级线程
G:代表一个goroutine
P:Processor,处理器,用来管理和执行goroutine的。
G-M-P三者的关系与特点:
- P的个数取决于设置的GOMAXPROCS,go新版本默认使用最大内核数,比如你有8核处理器,那么P的数量就是8
- M的数量和P不一定匹配,可以设置很多M,M和P绑定后才可运行,多余的M处于休眠状态。
- P包含一个LRQ(Local Run Queue)本地运行队列,这里面保存着P需要执行的协程G的队列
- 除了每个P自身保存的G的队列外,调度器还拥有一个全局的G队列GRQ(Global Run Queue),这个队列存储的是所有未分配的协程G。
golang gmp模型,全局队列中的G会不会饥饿,为什么?P的数量是多少?能修改吗?M的数量是多少?
第一版
- 全局队列中的G不会饥饿。 因为线程想运行任务就得获取P,从P的本地队列获取G,P队列为空时,M也会尝试从全局队列拿一批G放到P的本地队列,或从其他P的本地队列偷一半放到自己P的本地队列。 M运行G,G执行之后,M会从P获取下一个G,不断重复下去。所以全局队列中的G总是能被消费掉。
- P的数量可以理解为最大为本机可执行的cpu的最大数量。 通过runtime.GOMAXPROCS(runtime.NumCPU())设置。 runtime.NumCPU()方法返回当前进程可用的逻辑cpu数量。
第二版
全局队列中的G不会饥饿,P中每执行61次调度,就需要优先从全局队列中获取一个G到当前P中,并执行下一个要执行的G。
P数量问题可以通过 runtime.GOMAXPROCS() 设置数量,默认为当前CPU可执行的最大数量。M数量问题 Go语⾔本身是限定M的最⼤量是10000。 runtime/debug包中的SetMaxThreads函数来设置。 有⼀个M阻塞,会创建⼀个新的M。 如果有M空闲,那么就会回收或者睡眠。
三、内存管理
make和new的异同点
- 用途不同:make 用于创建和初始化引用类型(如 slice、map 和 channel),而 new 用于创建指针类型的值。
- 返回类型不同:make 返回的是所创建类型的引用,而 new 返回的是对应类型的指针。
- 参数不同:make 接收的参数是类型和一些可选的长度或容量等参数,具体取决于所创建的类型。而 new 只接收一个参数,即所要创建类型的指针。
- 初始化不同:make 创建的引用类型会进行初始化,并返回一个可用的、已分配内存的对象。而 new 创建的指针类型只是返回一个对应类型的指针,并不会进行初始化。
内存模型
Go语言运行时依靠细微的对象切割、极致的多级缓存、精准的位图管理实现了对内存的精细化管理。 将对象分为微小对象、小对象、大对象,使用三级管理结构mcache、mcentral、mheap用于管理、缓存加速span对象的访问和分配,使用精准的位图管理已分配的和未分配的对象及对象的大小。 Go语言运行时依靠细微的对象切割、极致的多级缓存、精准的位图管理实现了对内存的精细化管理以及快速的内存访问,同时减少了内存的碎片。
span
Go 将内存分成了67个级别的span,特殊的0级特殊大对象大小是不固定的。
当具体的对象需要分配内存时,并不是直接分配span,而是分配不同级别的span中的元素。因此span的级别不是以每个span的大小为依据,而是以span中元素的大小为依据的。
第1级span拥有的元素个数为8192/8=1024。每个span的大小和span中元素的个数都不是固定的,例如第65级span的大小为57344字节,每个元素的大小为28672字节,元素个数为2。span的大小虽然不固定,但其是8KB或更大的连续内存区域。 每个具体的对象在分配时都需要对齐到指定的大小,假如我们分配17字节的对象,会对应分配到比17字节大并最接近它的元素级别,即第3级,这导致最终分配了32字节。因此,这种分配方式会不可避免地带来内存的浪费。
三级对象管理
为了方便对Span进行管理,加速Span对象访问、分配。分别为mcache、mcentral、mheap。 TCMalloc内存分配算法的思想: 每个逻辑处理器P都存储了一个本地span缓存,称作mcache。如果协程需要内存可以直接从mcache中获取,由于在同一时间只有一个协程运行在逻辑处理器P上,所以中间不需要加锁。mcache包含所有大小规格的mspan,但是每种规格大小只包含一个。除class0外,mcache的span都来自mcentral。
mcentral 所有逻辑处理器P共享的。
- 对象收集所有给定规格大小的span。每个mcentral都包含两个mspan的链表:empty mspanList表示没有空闲对象或span已经被mcache缓存的span链表,nonempty mspanList表示有空闲对象的span链表。(为了的分配Mspan到Mcache中)
- mheap 每个级别的span都会有一个mcentral用于管理span链表(0级除外),其实 都是一个数组,由Mheap管理 作用: 不只是管理central,大对象也会直接通过mheap进行分配。
- mheap实现了对虚拟内存线性地址空间的精准管理,建立了span与具体线性地址空间的联系,保存了分配的位图信息,是管理内存的最核心单元。堆区的内存被分成了HeapArea大小进行管理。对Heap进行的操作必须全局加锁,而mcache、mcentral可以被看作某种形式的缓存。
四级内存块管理
Go 根据对象大小,将堆内存分成了 HeapArea->chunk->span->page 4种内存块进行管理。不同的内存块用于不同的场景,便于高效地对内存进行管理。
- HeapArea 内存块最大,其大小与平台相关,在UNIX 64位操作系统中占据64MB。
- chunk占据了512KB。
- span根据级别大小的不同而不同,但必须是page的倍数。
- 而1个page占据8KB。
内存分配的实现
Golang内存分配和TCMalloc差不多,都是把内存提前划分成不同大小的块,其核心思想是把内存分为多级管理,从而降低锁的粒度。先了解下内存管理每一级的概念: mspan mspan跟tcmalloc中的span相似,它是golang内存管理中的基本单位,也是由页组成的,每个页大小为8KB,与tcmalloc中span组成的默认基本内存单位页大小相同。mspan里面按照8*2n大小(8b,16b,32b … ),每一个mspan又分为多个object。
mcache mcache跟tcmalloc中的ThreadCache相似,ThreadCache为每个线程的cache,同理,mcache可以为golang中每个Processor提供内存cache使用,每一个mcache的组成单位也是mspan。
mcentral mcentral跟tcmalloc中的CentralCache相似,当mcache中空间不够用,可以向mcentral申请内存。可以理解为mcentral为mcache的一个“缓存库”,供mcaceh使用。它的内存组成单位也是mspan。mcentral里有两个双向链表,一个链表表示还有空闲的mspan待分配,一个表示链表里的mspan都被分配了。
mheap mheap跟tcmalloc中的PageHeap相似,负责大内存的分配。当mcentral内存不够时,可以向mheap申请。那mheap没有内存资源呢?跟tcmalloc一样,向OS操作系统申请。还有,大于32KB的内存,也是直接向mheap申请。
golang 分配内存具体过程如下:
- 程序启动时申请一大块内存,并划分成spans、bitmap、arena区域。
- arena区域按页划分成一个个小块。
- span管理一个或多个页。
- mcentral管理多个span供线程申请使用。
- mcache作为线程私有资源,资源来源于mcentral。
简单介绍一下go的内存分配机制?有mcentral为啥要mcache?
第一版
- 介绍内存分配机制
GO语言内存管理子系统主要由两部分组成:内存分配器和垃圾回收器(gc)。内存分配器主要解决小对象的分配管理和多线程的内存分配问题。什么是小对象呢?小于等于32k的对象就是小对象,其它都是大对象。小对象的内存分配是通过一级一级的缓存来实现的,目的就是为了提升内存分配释放的速度以及避免内存碎片等问题。 - 介绍MCentral
所有线程共享的组件,不是独占的,因此需要加锁操作。它其实也是一个缓存,cache的一个上游用户,但缓存的不是小对象内存块,而是一组一组的内存page(一个page4K)。从图2可以看出,在heap结构里,使用了一个0到n的数组来存储了一批central,并不是只有一个central对象。从上面结构定义可以知道这个数组长度位61个元素,也就是说heap里其实是维护了61个central,这61个central对应了cache中的list数组,也就是每一个sizeclass就有一个central。所以,在cache中申请内存时,如果在某个sizeclass的内存链表上找不到空闲内存,那么cache就会向对应的sizeclass的central获取一批内存块。注意,这里central数组的定义里面使用填充字节,这是因为多线程会并发访问不同central避免false sharing。 - 介绍mcache
每个线程都有一个cache,用来存放小对象。由于每个线程都有cache,所以获取空闲内存是不用加锁的。cache层的主要目的就是提高小内存的频繁分配释放速度。 我们在写程序的时候,其实绝大多数的内存申请都是小于32k的,属于小对象,因此这样的内存分配全部走本地cache,不用向操作系统申请显然是非常高效的。 - 阐述二者区别
mcentral与mcache有一个明显区别,就是有锁存在,由于mcentral是公共资源,会有多个mcache向它申请mspan,因此必须加锁,另外,mcentral与mcache不同,由于P绑定了很多Goroutine,在P上会处理不同大小的对象,mcache就需要包含各种规格的mspan,但mcentral不同,同一个mcentral只负责一种规格的mspan就够了。
第二版
Go 的内存分配借鉴了 Google 的 TCMalloc 分配算法,其核心思想是内存池 + 多级对象管理。内存池主要是预先分配内存,减少向系统申请的频率;多级对象有:mheap、mspan、arenas、mcentral、mcache。它们以 mspan 作为基本分配单位。具体的分配逻辑如下: 当要分配大于 32K 的对象时,从 mheap 分配。 当要分配的对象小于等于 32K 大于 16B 时,从 P 上的 mcache 分配,如果 mcache 没有内存,则从 mcentral 获取,如果 mcentral 也没有,则向 mheap 申请,如果 mheap 也没有,则从操作系统申请内存。 当要分配的对象小于等于 16B 时,从 mcache 上的微型分配器上分配。
GC触发时机
- 内存分配量达到阀值触发GC
每次内存分配时都会检查当前内存分配量是否已达到阀值,如果达到阀值则立即启动GC。
阀值 = 上次GC内存分配量 * 内存增长率
内存增长率由环境变量GOGC控制,默认为100,即每当内存扩大一倍时启动GC
- 定期触发GC
默认情况下,最长2分钟触发一次GC,这个间隔在src/runtime/proc.go:forcegcperiod变量中被声明:
var forcegcperiod int64 = 2 * 60 * 1e9
- 手动触发
程序代码中也可以使用runtime.GC()来手动触发GC。这主要用于GC性能测试和统计。
go垃圾回收介绍
第一版
三色标记法+混合写屏障
- 初始状态下所有对象都是白色的。
- 从根节点开始遍历所有对象,把遍历到的对象变成灰色对象。
- 遍历灰色对象,将灰色对象引用的对象也变成灰色对象,然后将遍历过的灰色对象变成黑色对象。
- 循环步骤3,直到灰色对象全部变黑色。
- 通过写屏障(write-barrier)检测对象有变化,重复以上操作。
- 收集所有白色对象(垃圾)。
(1)标记清除: 此算法主要有两个主要的步骤:
标记(Mark phase)
清除(Sweep phase)
第一步,找出不可达的对象,然后做上标记。 第二步,回收标记好的对象。
操作非常简单,但是有一点需要额外注意:mark and sweep算法在执行的时候,需要程序暂停!即 stop the world。 也就是说,这段时间程序会卡在哪儿。故中文翻译成 卡顿。
标记-清扫(Mark And Sweep)算法存在什么问题? 标记-清扫(Mark And Sweep)算法这种算法虽然非常的简单,但是还存在一些问题:
STW,stop the world;让程序暂停,程序出现卡顿。
标记需要扫描整个heap。
清除数据会产生heap碎片 这里面最重要的问题就是:mark-and-sweep 算法会暂停整个程序。
(2)三色并发标记法: 首先:程序创建的对象都标记为白色。 gc开始:扫描所有可到达的对象,标记为灰色 从灰色对象中找到其引用对象标记为灰色,把灰色对象本身标记为黑色 监视对象中的内存修改,并持续上一步的操作,直到灰色标记的对象不存在 此时,gc回收白色对象 最后,将所有黑色对象变为白色,并重复以上所有过程。
(3)混合写屏障: 注意: 当gc进行中时,新创建一个对象. 按照三色标记法的步骤,对象会被标记为白色,这样新生成的对象最后会被清除掉,这样会影响程序逻辑. golang引入写屏障机制.可以监控对象的内存修改,并对对象进行重新标记. gc一旦开始,无论是创建对象还是对象的引用改变,都会先变为灰色。
第二版
goalng1.8的GC采用三色标记法+混合写屏障
三色标记法:将所有对象分为三类,白色、黑色与灰色。
白色:暂无对象引用的潜在垃圾,其内存可能会被垃圾回收器回收
黑色:表示活跃的对象
灰色:黑色与白色的中间状态
三色标记算法分五步进行。
- 将所有的对象标记为白色;
- 从根节点出发,将第一次遍历到的节点标记为灰色;
- 遍历节点,将灰色节点遍历到的白色节点标记为灰色,把遍历到的灰色节点标记为黑色;
- 循环执行该过程;
- 直到没有灰色节点,回收所有白色节点。
屏障机制分为插入屏障和删除屏障,插入屏障实现的是强三色不变式,删除屏障则实现了弱三色不变式。值得注意的是为了保证栈的运行效率,屏障只对堆上的内存对象启用,栈上的内存会在GC结束后启用STW重新扫描。
插入屏障:对象被引用时触发的机制,当白色对象被黑色对象引用时,白色对象被标记为灰色(栈上对象无插入屏障)。
C语言这种较为传统的语言通过malloc和free手动向操作系统申请和释放内存,这种自由管理内存的方式给予程序员极大的自由度,但是也相应地提高了对程序员的要求。C语言的内存分配和回收方式主要包括三种:
- 函数体内的局部变量:在栈上创建,函数作用域结束后自动释放内存。
- 静态变量:在静态存储区域上分配内存,整个程序运行结束后释放(全局生命周期)。
- 动态分配内存的变量:在堆上分配,通过malloc申请,free释放。
C、C++和Rust等较早的语言采用的是手动垃圾回收,需要程序员通过向操作系统申请和释放内存来手动管理内存,程序员极容易忘记释放自己申请的内存,对于一个长期运行的程序往往是一个致命的缺点。
Java垃圾回收
就是将 对象的内存周期划分为几块,按照每块的情况采取不同的垃圾回收算法。一般是把Java堆分为新生代和老年代。年轻代:年轻代用来存放新近创建的对象,年轻代中存在的对象是死亡非常快的。存在朝生夕死的情况。 老年代:老年代中存放的对象是存活了很久的对象。 垃圾回收算法分为三种,分别为标记-清除算法,复制算法,标记-整理算法。
标记-清除算法:标记无用对象,然后对其进行清除回收。 复制算法:将内存区域划分为大小相等的两部分,每次只使用一部分,当该部分用完后将其存活的对象移至另一部分,并把该部分内存全部清除。 标记-整理算法:标记无用对象,让所有存活的对象都向内存一端移动,然后清除掉存活对象边界外的内存区域。
golang逃逸分析
Golang 的逃逸分析,是指编译器根据代码的特征和生命周期,自动的把变量分配到堆或者是栈上面。Go 在编译阶段确立逃逸,并不是在运行时。可以使用 -gcflags="-m" 参数来查看逃逸分析的详细信息,包括哪些变量逃逸到堆上。
介绍栈堆
栈( stack)是系统自动分配空间的,例如我们定义一个 char a;系统会自动在栈上为其开辟空间。而堆(heap)则是程序员根据需要自己申请的空间,例如 malloc(10);开辟十个字节的空间。栈在内存中是从高地址向下分配的,并且连续的,遵循先进后出原则。系统在分配的时候已经确定好了栈的大小空间。栈上面的空间是自动回收的,所以栈上面的数据的生命周期在函数结束后,就被释放掉了。堆分配是从低地址向高地址分配的,每次分配的内存大小可能不一致,导致了空间是不连续的,这也产生内存碎片的原因。由于是程序分配,所以效率相对慢些。而堆上的数据只要程序员不释放空间,就一直可以访问到,不过缺点是一旦忘记释放会造成内存泄露。
逃逸策略
每当函数中申请新的对象,编译器会根据该对象是否被函数外部引用来决定是否逃逸:
- 如果函数外部没有引用,则优先放到栈中;
- 如果函数外部存在引用,则必定放到堆中;
注意,对于函数外部没有引用的对象,也有可能放到堆中,比如内存过大超过栈的存储能力。
逃逸分析好处
- 内存分配优化:逃逸分析可以帮助编译器确定哪些变量可以在栈上分配,而不是在堆上分配。栈上分配的变量生命周期受限于函数或栈帧的范围,分配和释放内存的开销较小,可以提高程序的性能。
- 减少内存压力:通过将变量分配在栈上,可以减少对堆的内存压力。这对于大量临时对象的创建和销毁非常有用,可以减少垃圾回收的频率,提高程序的吞吐量。
- 减少垃圾回收压力:逃逸分析可以减少不必要的堆分配,从而减少垃圾回收器的负担。这对于大型和长时间运行的应用程序尤为重要,可以降低垃圾回收的停顿时间。
常见的逃逸现象
func(函数类型)数据类型;interface{} 数据类型 ;指针类型
- []interface{}数据类型,通过[]赋值必定会出现逃逸。
- map[string]interface{}类型尝试通过赋值,必定会出现逃逸。
- map[interface{}]interface{}类型尝试通过赋值,会导致key和value的赋值,出现逃逸。
- map[string][]string数据类型,赋值会发生[]string发生逃逸。
- []*int数据类型,赋值的右值会发生逃逸现象。
- func(*int)函数类型,进行函数赋值,会使传递的形参出现逃逸现象。
- func([]string): 函数类型,进行[]string{"value"}赋值,会使传递的参数出现逃逸现象。
- chan []string数据类型,想当前channel中传输[]string{"value"}会发生逃逸现象。
- 发送指针或带有指针的值到channel,因为编译时候无法知道那个goroutine会在channel接受数据,编译器无法知道什么时候释放。
- 在一个切片上存储指针或带指针的值。比如[]*string,导致切片内容逃逸,其引用值一直在堆上。
- 切片的append导致超出容量,切片重新分配地址,切片背后的存储基于运行时的数据进行扩充,就会在堆上分配。
- 调用接口类型时,接口类型的方法调用是动态调度,实际使用的具体实现只能在运行时确定,如一个接口类型为io.Reader的变量r,对r.Read(b)的调用将导致r的值和字节片b的后续转义并因此分配到堆上。
- 在方法内把局部变量指针返回,被外部引用,其生命周期大于栈,导致内存溢出。
写代码时如何减少对象分配
例如如果需要把数字转换成字符串,使用 strconv.Itoa() 比 fmt.Sprintf() 要快一倍左右。如果需要把数字转换成字符串,使用 strconv.Itoa() 比 fmt.Sprintf() 要快一倍左右。
内存分配和tcmalloc的区别
go 内存分配核心思想就是把内存分为多级管理,从而降低锁的粒度。它将可用的堆内存采用二级分配的方式进行管理:每个线程都会自行维护一个独立的内存池,进行内存分配时优先从该内存池中分配,当内存池不足时才会向全局内存池申请,以避免不同线程对全局内存池的频繁竞争。
- Go在程序启动时,会向操作系统申请一大块内存,之后自行管理。
- Go内存管理的基本单元是mspan,它由若干个页组成,每种mspan可以分配特定大小的object。
- mcache, mcentral, mheap是Go内存管理的三大组件,层层递进。mcache管理线程在本地缓存的mspan;mcentral管理全局的mspan供所有线程使用;mheap管理Go的所有动态分配内存。
- 极小的对象(<=16B)会分配在一个object中,以节省资源,使用tiny分配器分配内存;一般对象(16B-32KB)通过mspan分配内存;大对象(>32KB)则直接由mheap分配内存。
tcmalloc tcmalloc 是google开发的内存分配算法库,最开始它是作为google的一个性能工具库 perftools 的一部分。TCMalloc是用来替代传统的malloc内存分配函数。它有减少内存碎片,适用于多核,更好的并行性支持等特性。 TC就是Thread Cache两英文的简写。它提供了很多优化,如: 1.TCMalloc用固定大小的page(页)来执行内存获取、分配等操作。这个特性跟Linux物理内存页的划分是不是有同样的道理。 2.TCMalloc用固定大小的对象,比如8KB,16KB 等用于特定大小对象的内存分配,这对于内存获取或释放等操作都带来了简化的作用。 3.TCMalloc还利用缓存常用对象来提高获取内存的速度。 4.TCMalloc还可以基于每个线程或者每个CPU来设置缓存大小,这是默认设置。 5.TCMalloc基于每个线程独立设置缓存分配策略,减少了多线程之间锁的竞争。
Go中的内存分类并不像TCMalloc那样分成小、中、大对象,但是它的小对象里又细分了一个Tiny对象,Tiny对象指大小在1Byte到16Byte之间并且不包含指针的对象。小对象和大对象只用大小划定,无其他区分。 Go内存管理与tcmalloc最大的不同在于,它提供了逃逸分析和垃圾回收机制。
Go 语言内存分配,什么分配在堆上,什么分配在栈上
Go 语言有两部分内存空间:栈内存和堆内存。栈内存由编译器自动分配和释放,函数调用的参数、返回值以及局部变量大都会被分配到栈上。堆内存的生命周期比栈内存要长,如果函数返回的值还会在其他地方使用,那么这个值就会被编译器自动分配到堆上。堆内存相比栈内存来说,不能自动被编译器释放,只能通过垃圾回收器才能释放,所以栈内存效率会很高。
go性能调优的方法
内存优化
- 将小对象合并成结构体一次分配,减少内存分配次数 Go runtime底层采用内存池机制,每个span大小为4k,同时维护一个cache。cache有一个0到n的list数组,list数组的每个单元挂载的是一个链表,链表的每个节点就是一块可用的内存块,同一链表中的所有节点内存块都是大小相等的;但是不同链表的内存大小是不等的,即list数组的一个单元存储的是一类固定大小的内存块,不同单元里存储的内存块大小是不等的。cache缓存的是不同类大小的内存对象,申请的内存大小最接近于哪类缓存内存块时,就分配哪类内存块。当cache不够时再向spanalloc中分配。
- 缓存区内容一次分配足够大小空间,并适当复用 在协议编解码时,需要频繁地操作[]byte,可以使用bytes.Buffer或其它byte缓存区对象。 bytes.Buffer等通过预先分配足够大的内存,避免当增长时动态申请内存,减少内存分配次数。对于byte缓存区对象需要考虑适当地复用。
- slice和map采make创建时,预估大小指定容量 slice和map与数组不一样,不存在固定空间大小,可以根据增加元素来动态扩容。 slice初始会指定一个数组,当对slice进行append等操作时,当容量不够时,会自动扩容: 如果新的大小是当前大小2倍以上,则容量增涨为新的大小; 否则循环以下操作:如果当前容量小于1024,按2倍增加;否则每次按当前容量1/4增涨,直到增涨的容量超过或等新大小。 map的扩容比较复杂,每次扩容会增加到上次容量的2倍。map的结构体中有一个buckets和oldbuckets,用于实现增量扩容: 正常情况下,直接使用buckets,oldbuckets为空; 如果正在扩容,则oldbuckets不为空,buckets是oldbuckets的2倍, 因此,建议初始化时预估大小指定容量
- 长调用栈避免申请较多的临时对象 Goroutine的调用栈默认大小是4K(1.7修改为2K),采用连续栈机制,当栈空间不够时,Go runtime会自动扩容: 当栈空间不够时,按2倍增加,原有栈的变量会直接copy到新的栈空间,变量指针指向新的空间地址; 退栈会释放栈空间的占用,GC时发现栈空间占用不到1/4时,则栈空间减少一半。 比如栈的最终大小2M,则极端情况下,就会有10次的扩栈操作,会带来性能下降。 因此,建议控制调用栈和函数的复杂度,不要在一个goroutine做完所有逻辑;如的确需要长调用栈,而考虑goroutine池化,避免频繁创建goroutine带来栈空间的变化。
- 避免频繁创建临时对象 Go在GC时会引发stop the world,即整个情况暂停。Go1.8最坏情况下GC为100us。但暂停时间还是取决于临时对象的个数,临时对象数量越多,暂停时间可能越长,并消耗CPU。 因此,建议GC优化方式是尽可能地减少临时对象的个数:尽量使用局部变量;所多个局部变量合并一个大的结构体或数组,减少扫描对象的次数,一次回尽可能多的内存。
并发优化
- 高并发的任务处理使用goroutine池 Goroutine虽然轻量,但对于高并发的轻量任务处理,频繁来创建goroutine来执行,执行效率并不会太高,因为:过多的goroutine创建,会影响go runtime对goroutine调度,以及GC消耗;高并发时若出现调用异常阻塞积压,大量的goroutine短时间积压可能导致程序崩溃。
- 避免高并发调用同步系统接口 goroutine的实现,是通过同步来模拟异步操作。 网络IO、锁、channel、Time.sleep、基于底层系统异步调用的Syscall操作并不会阻塞go runtime的线程调度。 本地IO调用、基于底层系统同步调用的Syscall、CGo方式调用C语言动态库中的调用IO或其它阻塞会创建新的调度线程。 网络IO可以基于epoll的异步机制(或kqueue等异步机制),但对于一些系统函数并没有提供异步机制。例如常见的posix api中,对文件的操作就是同步操作。虽有开源的fileepoll来模拟异步文件操作。但Go的Syscall还是依赖底层的操作系统的API。系统API没有异步,Go也做不了异步化处理。 因此,建议:把涉及到同步调用的goroutine,隔离到可控的goroutine中,而不是直接高并的goroutine调用。
- 高并发时避免共享对象互斥 传统多线程编程时,当并发冲突在4~8线程时,性能可能会出现拐点。Go推荐不通过共享内存来通信,Go创建goroutine非常容易,当大量goroutine共享同一互斥对象时,也会在某一数量的goroutine出在拐点。 因此,建议:goroutine尽量独立,无冲突地执行;若goroutine间存在冲突,则可以采分区来控制goroutine的并发个数,减少同一互斥对象冲突并发数。
其它优化
- 避免使用CGO或者减少CGO调用次数 GO可以调用C库函数,但Go带有垃圾收集器且Go的栈动态增涨,无法与C无缝地对接。Go的环境转入C代码执行前,必须为C创建一个新的调用栈,把栈变量赋值给C调用栈,调用结束现拷贝回来。调用开销较大,需要维护Go与C的调用上下文,两者调用栈的映射。相比直接的GO调用栈,单纯的调用栈可能有2个甚至3个数量级以上。 因此,建议:尽量避免使用CGO,无法避免时,要减少跨CGO的调用次数。
- 减少[]byte与string之间转换,尽量采用[]byte来字符串处理 GO里面的string类型是一个不可变类型,GO中[]byte与string底层是两个不同的结构,转换存在实实在在的值对象拷贝,所以尽量减少不必要的转化。 因此,建议:存在字符串拼接等处理,尽量采用[]byte。
- 字符串的拼接优先考虑bytes.Buffer string类型是一个不可变类型,但拼接会创建新的string。GO中字符串拼接常见有如下几种方式: string + 操作 :导致多次对象的分配与值拷贝 fmt.Sprintf :会动态解析参数,效率好不哪去 strings.Join :内部是[]byte的append bytes.Buffer :可以预先分配大小,减少对象分配与拷贝 因此,建议:对于高性能要求,优先考虑bytes.Buffer,预先分配大小。
虚拟内存有什么作用 (无效,属于操作系统)
虚拟内存就是说,让物理内存扩充成更⼤的逻辑内存,从⽽让程序获得更多的可⽤内存。虚拟内存使⽤部分加载的
技术,让⼀个进程或者资源的某些⻚⾯加载进内存,从⽽能够加载更多的进程,甚⾄能加载⽐内存⼤的进程,这样
看起来好像内存变⼤了,这部分内存其实包含了磁盘或者硬盘,并且就叫做虚拟内存。
四、并发编程
说一下reflect
recflect是golang用来检测存储在接口变量内部(值value;类型concrete type) pair对的一种机制。它提供了两种类型(或者说两个方法)让我们可以很容易的访问接口变量内容,分别是reflect.ValueOf() 和 reflect.TypeOf()。
- ValueOf用来获取输入参数接口中的数据的值,如果接口为空则返回0;
- TypeOf用来动态获取输入参数接口中的值的类型,如果接口为空则返回nil;
runtime提供常见的方法
- Gosched():让当前线程让出 cpu 以让其它线程运行,它不会挂起当前线程,因此当前线程未来会继续执行。
- NumCPU():返回当前系统的 CPU 核数量。
- GOMAXPROCS():设置最大的可同时使用的 CPU 核数。 通过runtime.GOMAXPROCS函数,应用程序可以设置运行时系统中的 P 最大数量。注意,如果在运行期间设置该值的话,会引起“Stop the World”。所以,应在应用程序最早期调用,并且最好是在运行Go程序之前设置好操作程序的环境变量GOMAXPROCS,而不是在程序中调用runtime.GOMAXPROCS函数。无论我们传递给函数的整数值是什么值,运行时系统的P最大值总会在1~256之间。go1.8 后,默认让程序运行在多个核上,可以不用设置了。go1.8 前,还是要设置一下,可以更高效的利用 cpu。
- Goexit():退出当前 goroutine(但是defer语句会照常执行)。
- NumGoroutine:返回正在执行和排队的任务总数。 runtime.NumGoroutine函数在被调用后,会返回系统中的处于特定状态的 Goroutine 的数量。这里的特定状态是指Grunnable\Gruning\Gsyscall\Gwaition。处于这些状态的Groutine即被看做是活跃的或者说正在被调度。注意:垃圾回收所在Groutine的状态也处于这个范围内的话,也会被纳入该计数器。
- GOOS:查看目标操作系统。很多时候,我们会根据平台的不同实现不同的操作,就可以用GOOS来查看自己所在的操作系统。
- runtime.GC:会让运行时系统进行一次强制性的垃圾收集。 强制的垃圾回收:不管怎样,都要进行的垃圾回收。非强制的垃圾回收:只会在一定条件下进行的垃圾回收(即运行时,系统自上次垃圾回收之后新申请的堆内存的单元(也成为单元增量)达到指定的数值)。
- GOROOT():获取 goroot 目录。
- runtime.LockOSThread 和 runtime.UnlockOSThread 函数:前者调用会使调用他的 Goroutine 与当前运行它的M锁定到一起,后者调用会解除这样的锁定。
sync.once 如何实现并发安全
type Once struct {
done unit32
m Mutex
}
他们分别为标记是否已经执行过的标志(done),以及执行时所用的互斥锁(m) 除了结构体外,sync.Once还包括了一个公开的方法Do:
func (o *Once) Do(f func()) {
if atomic.LoadUint32(&o.done) == 0 {
o.doSlow(f)
}
}
Once.Do方法的实现非常简单,通过atomic.LoadUint32获取Once实例的done属性值。 若done值为0时,表示函数f未被调用过或正运行中且未结束,则将调用doSlow方法; 若done值为1时,表示函数f已经调用且完成,则直接返回。 这里使用了原子操作方法atomic.LoadUint32而不是直接将o.done进行比较,也是为了避免并发状态下错误地判断执行状态,产生不必要的锁操作带来的时间开销。
func (o *Once) doSlow(f func()) {
o.m.Lock()
defer o.m.Unlock()
if o.done == 0 {
defer atomic.StoreUint32(&o.done, 1)
f()
}
}
Once.doSlow方法的实现使用了传统的互斥锁Mutex操作,在执行时即调用o.m.Lock方法获得锁,然后再继续判断是否已经完成并调用f函数。 可以看到,在获得锁后还需要对o.done的值进行一次判断,避免了f函数被重复调用。 最后,在退出doSlow方法时还需要对获取的锁进行释放,若进入到f函数的调用则需要更改o.done属性值。
context数据结构
Context 是一个接口,定义了 4 个方法,它们都是幂等的。也就是说连续多次调用同一个方法,得到的结果都是相同的。
- Done() 返回一个 channel,可以表示 context 被取消的信号:当这个 channel 被关闭时,说明 context 被取消了。注意,这是一个只读的channel。 我们又知道,读一个关闭的 channel 会读出相应类型的零值。并且源码里没有地方会向这个 channel 里面塞入值。换句话说,这是一个 receive-only 的 channel。因此在子协程里读这个 channel,除非被关闭,否则读不出来任何东西。也正是利用了这一点,子协程从 channel 里读出了值(零值)后,就可以做一些收尾工作,尽快退出。
- Err() 返回一个错误,表示 channel 被关闭的原因。例如是被取消,还是超时。
- Deadline() 返回 context 的截止时间,通过此时间,函数就可以决定是否进行接下来的操作,如果时间太短,就可以不往下做了,否则浪费系统资源。当然,也可以用这个 deadline 来设置一个 I/O 操作的超时时间。
- Value() 获取之前设置的 key 对应的 value。
go 怎么控制查询timeout (context) context 监听是否有 IO 操作,开始从当前连接中读取网络请求,每当读取到一个请求则会将该cancelCtx传入,用以传递取消信号,可发送取消信号,取消所有进行中的网络请求。
- Deadline — 返回 context.Context 被取消的时间,也就是完成工作的截止日期;
- Done — 返回一个 Channel,这个 Channel 会在当前工作完成或者上下文被取消之后关闭,多次调用 Done 方法会返回同一个 Channel;
- Err — 返回 context.Context 结束的原因,它只会在 Done 返回的 Channel 被关闭时才会返回非空的值;
如果 context.Context 被取消,会返回 Canceled 错误;
如果 context.Context 超时,会返回 DeadlineExceeded 错误; - Value — 从 context.Context 中获取键对应的值,对于同一个上下文来说,多次调用 Value 并传入相同的 Key 会返回相同的结果,该方法可以用来传递请求特定的数据;
go并发优秀在哪里
Go中天然的支持并发,Go允许使用go语句开启一个新的运行期线程,即 goroutine,以一个不同的、新创建的goroutine来执行一个函数。同一个程序中的所有goroutine共享同一个地址空间。 Goroutine非常轻量,除了为之分配的栈空间,其所占用的内存空间微乎其微。并且其栈空间在开始时非常小,之后随着堆存储空间的按需分配或释放而变化。内部实现上,goroutine会在多个操作系统线程上多路复用。如果一个goroutine阻塞了一个操作系统线程,例如:等待输入,这个线程上的其他goroutine就会迁移到其他线程,这样能继续运行。开发者并不需要关心/担心这些细节。 Go语言的并发机制运用起来非常简便,在启动并发的方式上直接添加了语言级的关键字就可以实现,和其他编程语言相比更加轻量。
高并发特点
- 用户空间:避免了内核态和用户态的切换导致的成本
- 可以由语言和框架层进行调度
- 更小的栈空间允许创建大量的实例 2) channel: 被单独创建并且可以在进程之间传递,它的通信模式类似于 boss-worker 模式的,一个实体通过将消息发送到 channel 中,然后又监听这个 channel 的实体处理,两个实体之间是匿名的,这个就实现实体中间的解耦,在实现原理上其实是一个阻塞的消息队列。 3) 调度器: goroutine 中提供了调度器,在调度器加入了steal working 算法 ,goroutine 是可以被异步抢占,因此没有函数调用的进程不再对调度器造成死锁或造成垃圾回收的大幅变慢。并且 go 对网络IO库进行了封装,屏蔽了复杂的细节,对外提供统一的语法关键字支持,简化了并发程序编写的成本。
golang并发控制
数据安全控制
- 互斥锁 sync.Mutex
- 读写锁 sync.RWMutex
- 原子操作 sync/atomic
并发行为控制
golang控制并发有三种经典的方式,一种是通过channel通知实现并发控制 一种是WaitGroup,另外一种就是Context。
- 使用最基本通过channel通知实现并发控制 无缓冲通道: 无缓冲的通道指的是通道的大小为0,也就是说,这种类型的通道在接收前没有能力保存任何值,它要求发送 goroutine 和接收 goroutine 同时准备好,才可以完成发送和接收操作。 从上面无缓冲的通道定义来看,发送 goroutine 和接收 gouroutine 必须是同步的,同时准备后,如果没有同时准备好的话,先执行的操作就会阻塞等待,直到另一个相对应的操作准备好为止。这种无缓冲的通道我们也称之为同步通道。
- 通过sync包中的WaitGroup实现并发控制 在 sync 包中,提供了 WaitGroup ,它会等待它收集的所有 goroutine 任务全部完成,在主 goroutine 中 Add(delta int) 索要等待goroutine 的数量。 在每一个 goroutine 完成后 Done() 表示这一个goroutine 已经完成,当所有的 goroutine 都完成后,在主 goroutine 中 WaitGroup 返回返回。
- 在Go 1.7 以后引进的强大的Context上下文,实现并发控制 在一些简单场景下使用 channel 和 WaitGroup 已经足够了,但是当面临一些复杂多变的网络并发场景下 channel 和 WaitGroup 显得有些力不从心了。 比如一个网络请求 Request,每个 Request 都需要开启一个 goroutine 做一些事情,这些 goroutine 又可能会开启其他的 goroutine,比如数据库和RPC服务。 所以我们需要一种可以跟踪 goroutine 的方案,才可以达到控制他们的目的,这就是Go语言为我们提供的 Context,称之为上下文非常贴切,它就是goroutine 的上下文。 它是包括一个程序的运行环境、现场和快照等。每个程序要运行时,都需要知道当前程序的运行状态,通常Go 将这些封装在一个 Context 里,再将它传给要执行的 goroutine 。 context 包主要是用来处理多个 goroutine 之间共享数据,及多个 goroutine 的管理。 context包方法: Done() 返回一个只能接受数据的channel类型,当该context关闭或者超时时间到了的时候,该channel就会有一个取消信号 Err() 在Done() 之后,返回context 取消的原因。 Deadline() 设置该context cancel的时间点 Value() 方法允许 Context 对象携带request作用域的数据,该数据必须是线程安全的。
CSP并发模型:
Go实现了两种并发模式。第一种:多线程共享内存。第二种:通过通信来共享内存(CSP)。
CSP并发模型是Go语言特有的并发模型,也是Go语言官方所推荐的并发模型。
Go的CSP并发模型,是由Go语言中的goroutine与channel共同来实现的。
- goroutine:Go语言中使用关键字go来创建goroutine。将关键字go放到需要调用的函数前,在相同地址空间调用运行这个函数,该函数在执行的时候会创建一个独立的线程去执行,这个线程就是Go语言中的goroutine。
- channel:Go语言中goroutine之间的通信机制。
线程模型:
一对一模型(1:1)
将一个用户级线程映射到一个内核线程,每一个线程由内核调度器独立调度,线程之间互不影响。
优点:在多核处理器的条件下,实现了真正的并行。
缺点:为每一个用户级线程建立一个内核线程,开销大,浪费资源。
多对一模型(M:1)
将多个用户级线程映射到一个内核线程。
优点:线程上下文切换发生在用户空间。
缺点:只有一个处理器被应用,在多处理环境下是不可以被接受的,实现了并发,不能解决并行问题。
多对多模型(M:N)
多个用户级线程运行在多个内核线程上,这使得大部分的线程上下文切换都发生在用户空间,而多个内核线程又能充分利用处理器资源。
golang中Context的使用场景
Go1.7加入到标准库,在于控制goroutine的生命周期。当一个计算任务被goroutine承接了之后,由于某种原因,我们希望中止这个goroutine的计算任务,那么就用得到这个Context了。 包含CancelContext,TimeoutContext,DeadLineContext,ValueContext。
场景一:RPC调用 在主goroutine上有4个RPC,RPC2/3/4是并行请求的,我们这里希望在RPC2请求失败之后,直接返回错误,并且让RPC3/4停止继续计算。这个时候,就使用的到Context。
场景二:PipeLine runSimplePipeline的流水线工人有三个,lineListSource负责将参数一个个分割进行传输,lineParser负责将字符串处理成int64,sink根据具体的值判断这个数据是否可用。他们所有的返回值基本上都有两个chan,一个用于传递数据,一个用于传递错误。(<-chan string, <-chan error)输入基本上也都有两个值,一个是Context,用于传声控制的,一个是(in <-chan)输入产品的。
场景三:超时请求 我们发送RPC请求的时候,往往希望对这个请求进行一个超时的限制。当一个RPC请求超过10s的请求,自动断开。当然我们使用CancelContext,也能实现这个功能(开启一个新的goroutine,这个goroutine拿着cancel函数,当时间到了,就调用cancel函数)。鉴于这个需求是非常常见的,context包也实现了这个需求:timerCtx。具体实例化的方法是 WithDeadline 和 WithTimeout。具体的timerCtx里面的逻辑也就是通过time.AfterFunc来调用ctx.cancel的。
场景四:HTTP服务器的request互相传递数据 context还提供了valueCtx的数据结构。这个valueCtx最经常使用的场景就是在一个http服务器中,在request中传递一个特定值,比如有一个中间件,做cookie验证,然后把验证后的用户名存放在request中。我们可以看到,官方的request里面是包含了Context的,并且提供了WithContext的方法进行context的替换。
用共享内存的方式实现并发如何保证安全
Go的设计思想就是, 不要通过共享内存来通信,而是通过通信来共享内存,前者就是传统的加锁,后者就是Channel。也就是说,设计Channel的主要目 的就是在多任务间传递数据的,本身就是安全的。 看源码就知道channel内部维护了一个互斥锁,来保证线程安全,channel底层实现出队入队时也加锁。
从运行速度来讲,go的并发模型channel和goroutine
- goroutine 是一种非常轻量级的实现,可在单个进程里执行成千上万的并发任务,它是Go语言并发设计的核心。 说到底 goroutine 其实就是线程,但是它比线程更小,十几个 goroutine 可能体现在底层就是五六个线程,而且Go语言内部也实现了 goroutine 之间的内存共享。 使用 go 关键字就可以创建 goroutine,将 go 声明放到一个需调用的函数之前,在相同地址空间调用运行这个函数,这样该函数执行时便会作为一个独立的并发线程,这种线程在Go语言中则被称为 goroutine。
- channel 是Go语言在语言级别提供的 goroutine 间的通信方式。可以使用 channel 在两个或多个 goroutine 之间传递消息。
怎么理解“不要用共享内存来通信,而是用通信来共享内存”
共享内存会涉及到多个线程同时访问修改数据的情况,为了保证数据的安全性,那就会加锁,加锁会让并行变为串行,cpu此时也会忙于线程抢锁。另外使用过多的锁,容易使得程序的代码逻辑坚涩难懂,并且容易使程序死锁,死锁了以后排查问题相当困难,特别是很多锁同时存在的时候。
在这种情况下,不如换一种方式,把数据复制一份,每个线程有自己的,只要一个线程干完一件事其他线程不用去抢锁了,这就是一种通信方式,把共享的以通知方式交给线程,实现并发。go语言的channel就保证同一个时间只有一个goroutine能够访问里面的数据,为开发者提供了一种优雅简单的工具,所以go原生的做法就是使用channle来通信,而不是使用共享内存来通信。
五、异常处理
error
Go语言没有提供传统的try···catch语句来处理异常,而是使用error来处理错误,用panic和recover来处理异常。
Go语言中的错误的表示
答案:在Go中,错误是通过实现error接口来表示的。error接口只有一个方法Error() string,返回一个描述错误的字符串。
为什么Go选择使用接口来表示错误
答案:Go选择使用接口来表示错误有几个优势。首先,接口提供了一种统一的错误表示方式,使得编写和处理错误更加一致和简单。其次,接口可以被多个不同类型的错误实现,这样就可以根据具体的错误类型执行不同的处理逻辑。最后,通过接口,我们可以轻松地将错误传递给调用者,而不需要暴露底层错误的具体实现细节。
在Go中,如何处理错误
答案:在Go中,错误处理是显式的。通常使用if err != nil来检查错误,并根据需要执行相应的处理逻辑。这可以是返回错误、记录日志、重新尝试操作或采取其他恰当的行动。
进行错误类型断言(Type Assertion)
答案:错误类型断言可用于判断错误的具体类型,并执行相应的处理逻辑。可以使用类型断言表达式err.(具体错误类型)来判断错误的类型,如果断言成功,则可以访问该错误类型的特定方法或属性。
创建自定义的错误类型
答案:在Go中,可以通过创建满足error接口的自定义类型来定义自己的错误类型。可以定义一个新的结构体类型,并为其实现Error() string方法,以便返回适当的错误描述信息。
什么是包装错误(Error Wrapping)
答案:包装错误是指将底层错误包装在更高级别的错误中,以提供更多的上下文信息。这可以通过调用fmt.Errorf函数或使用errors.Wrap函数来实现。包装错误可以形成错误链,可以使用errors.Is和errors.As函数来遍历和检查包装的错误。
defer、panic、recover之间的关系和错误输出可参考基础篇 defer 相关内容。
六、测试
单元测试
单元测试是指针对软件中的最小可测试单元进行检查和验证,比如对一个函数的测试
- 测试文件名必须以_test.go结尾;
- 测试函数名必须以TestXxx开始;
- 在命令行下使用go test即可启动测试。
性能测试
性能测试也称为基准测试,可以测试一段程序的性能,可以得到时间消耗,内存使用情况的报告
- 文件名必须以_test.go结尾;
- 函数名必须以BenchmarkXxx开始;
- 使用go test -bench=.命令即可开始性能测试。
示例测试
示例测试广泛应用于Go源码和各种开源框架中,用于展示某个包或者某个方法的用法。比如,在Go标准库中,mail包展示了如何从一个字符串中解析出邮件列表的用法。
- 示例测试函数名需要以Example开头;
- 检测单行输出格式为 // Output:<期望字符串>;
- 检测多行输出格式为 // Output:\n <期望字符串> \n <期望字符串> ,每个期望字符串占一行;
- 检测无序输出格式为 // Unordered output :\n <期望字符串> \n <期望字符串>,每个期望字符串占一行;
- 测试字符串时会自动忽略字符串前后的空白字符串;
- 如果测试函数中没有Output标识,则该测试函数不会被执行;
- 执行测试可以使用go test,此时该目录下的其他测试文件也会一并执行;
- 执行测试可以使用go test <xxx_test.go>,此时仅执行特定文件中的测试函数。