Golang协程和通道

2024-06-04 5886阅读

文章目录

协程（goroutine）
- 基本介绍
- GMP模型
- 协程间共享变量
- 通道（channel）
- - 基本介绍
  - channel的定义方式
  - channel的读写
  - channel的关闭
  - channel的遍历方式
  - 只读/只写channel
  - channel最佳案例
  - select语句
    协程（goroutine）
    
    基本介绍
    
    基本介绍
    
    进程、线程与协程：
    - 进程（Process）是计算机中正在运行的程序的实例，是操作系统进行资源分配和调度的基本单位。每个进程都有自己独立的地址空间、代码、数据和文件资源。进程之间相互独立，通过进程间通信机制进行数据交换和协作。进程的创建、销毁以及切换都由操作系统自动完成，开销较大。
    - 线程（Thread）是操作系统调度的最小执行单元，是进程内的一个执行路径。线程与进程共享同一地址空间和大部分资源，包括代码段、数据段和打开的文件等。线程之间通常借助互斥锁、条件变量以及信号量等进行数据交换。线程的创建、销毁以及切换的开销较小，但需要注意线程间的同步和共享资源的管理。
    - 协程（Coroutine）协程是一种轻量级的并发执行单元，通常由编程语言本身的运行时系统进行调度和管理。协程通常在一个线程内执行，共享相同的地址空间和资源。协程间通常通过通道（Channel）实现数据交换和协作。协程的创建、销毁以及切换都由运行时系统自动完成，开销非常小，可以创建成千上万个协程而不会导致系统负载过高。
      并发与并行：
      - 并发（Concurrency）指的是在单个处理器上以时间片轮转的方式交替执行多个任务，使得在一段时间内，这多个任务都得以推进，但实际在一个时间点只有一个任务在执行。
      - 并行（Parallelism）指的是多个任务同时在不同的处理器上执行，使得这多个任务同时得以推进，并且在一个时间点来看，也是多个任务在同时执行。
        在Go中，通过在函数或方法的调用前加上go关键字即可创建一个go协程，并让其运行对应的函数或方法。如下：
        
        package main import ( "fmt" "time" ) func Print() bool { for i := 0; i
        在上述代码中，主协程创建了一个新协程用于执行Print函数，主协程进行5次打印后退出，新协程进行10次打印后退出。运行结果如下：
        
        说明一下：
        
        在Go中，当程序启动时会自动创建一个主协程来执行main函数，该协程与其他新创建的协程没有本质的区别，但主协程执行完毕后整个程序会退出，即使其他协程还未执行完毕，也会跟着退出。
        如果一个协程在执行过程中触发了panic异常，但没有对其进行捕获，那么会导致整个程序崩溃，因此在协程中也需要通过recover函数对panic进行捕获。
        GMP模型
        
        常规的协程（Coroutine）
        
        线程是在内核态视角下的最小执行单元，而协程是在线程的基础上，在用户态视角下进行二次开发得到的更小的执行单元。常规的协程（Coroutine）通常是与一个线程强绑定的，而一个线程可以绑定多个协程。如下：
        
        说明一下：
        
        由于常规的协程是与一个线程强绑定的，因此绑定于同一线程的多个协程只能做到并发，无法做到并行。
        当一个协程因为某些原因陷入阻塞，那么这个阻塞会直接上升到对应的线程，最终导致整个协程组陷入阻塞。
        Go中的协程（Goroutine）
        
        Go语言中的协程（Goroutine）与常规的协程（Coroutine）的实现方式有所不同，Go中的协程不是与一个线程强绑定的，而是由Go调度器动态的将协程绑定到可用的线程上执行。如下：
        
        说明一下：
        
        由于Go协程与线程之间的绑定是动态的，因此各个协程之间既能做到并发，也能做到并行。
        当一个Go协程因为某些原因陷入阻塞，那么Go调度器会将该协程与其绑定的线程进行解绑，将线程的资源释放出来，使得线程可以与其他可调度的协程进行绑定。
        GMP模型
        
        GMP（Goroutine-Machine-Processor）模型是Go运行时系统中用于实现并发执行的模型，负责管理和调度协程的执行。G、M和P的含义分别如下：
        
        G（Goroutine）：代表Go中的协程，每个G都有自己的运行栈、状态以及执行的任务函数。
        M（Machine）：代表Go中的线程，M不直接执行G，而是先和P绑定，由P来指定M所需执行的G。
        P（Processor）：代表Go中的调度器，P实现G和M之间的动态有机结合。对于G而言，P就是其CPU，G只有被P调度才得以执行；对于M而言，P是其执行代理，为其指定可执行的G。
        GMP模型示意图如下：
        
        上图说明：
        
        全局有多个M和多个P，但M和P的数量不一定是相同的。每个M在调度G之前，需要先和P进行绑定（不是强绑定），每个M调度的G由其对应的P指定。M无需记录所调度的G的状态信息，因此G在全生命周期中可以实现跨M执行。
        在GMP模型中有三种队列来存放G，分别是全局队列、P的本地队列和wait队列（用于存放io阻塞就绪态的G，图中未展示）。
        每个P都有一个对应本地队列，访问本地队列时可以接近无锁化。当P为M获取可调度的G时，会优先从自己的本地队列中进行获取，其次从全局队列中获取，最后从wait队列中获取。
        如果一个G在调度过程中新创建了一个G，那么这个新G会优先投递到当前P的本地队列中，如果本地队列已满则投递到全局队列中。
        调度器P获取可调度的G的流程如下：
        
        优先尝试从当前P的本地队列获取可调度的G。
        尝试从全局队列获取可调度的G。
        尝试从wait队列获取io阻塞就绪的G。
        尝试从其他P的本地队列窃取一半的G补充到当前P的本地队列，防止不同P的闲忙差异过大（work-stealing机制）。
        说明一下：
        
        由于存在work-stealing机制，因此P的本地队列的访问也不是完全无锁的，只能说接近无锁化。
        上述说到的只是获取可调度的G的主要流程，实际实现时还有更多的细节。比如P每进行61次调度后，会先尝试从全局队列中获取一个G进行调度，避免造成全局队列中的G的饥饿问题。
        GOMAXPROCS
        
        在GMP模型中，G只有被P调度才得以执行，因此P的数量决定了G的最大并行数量。通过runtime包中的GOMAXPROCS函数可以获取和设置P的数量。如下：
        
        package main import ( "fmt" "runtime" ) func main() { cpuNum := runtime.NumCPU() // 获取本地机器的逻辑CPU数 fmt.Printf("cpuNum = %d\n", cpuNum) // cpuNum = 6 runtime.GOMAXPROCS(4) // 设置可同时执行的最大CPU数 num := runtime.GOMAXPROCS(0) // 获取可同时执行的最大CPU数 fmt.Printf("num = %d\n", num) // num = 4 }
        
        说明一下：
        
        runtime包中的NumCPU函数，用于获取本地机器的逻辑CPU数。
        runtime包中的GOMAXPROCS函数，用于设置可同时执行的最大CPU数，并返回先前的设置。如果设置的值小于1，则不会更改当前的值，设置的值超过CPU核数无意义。
        从Go1.5开始，GOMAXPROCS默认设置为CPU的核数，并且可以根据需要自动调整并发执行的并行度，无需再手动设置。
        协程的生命周期
        
        Go中协程的生命周期大致由如下几种状态组成：
        
        _Gidle：表示该协程刚刚创建，但还未进行初始化。
        _Gdead：表示该协程已经完成初始化，但还未被使用。
        _Grunnable：表示该协程已经被放入运行队列，但还未被调度。
        _Grunning：表示该协程正在被调度。
        _Gsyscall：表示该协程正在执行系统调用。
        _Gwaiting：表示该协程处于挂起状态，需要等待被唤醒。
        _Gdead：表示该协程刚刚执行完毕。
        状态转换如下：
        
        说明一下：
        
        当协程在调度过程中执行到系统调用代码时，其状态就会由_Grunning切换为_Gsyscall，并在系统调用结束后根据实际情况恢复为_Grunning或_Grunnable状态。
        协程在调度过程中，可能因为某些原因而陷入阻塞，比如等待锁资源就绪或等待channel条件就绪等，这是协程的状态会由_Grunning切换为_Gwaiting，并在协程被唤醒后恢复为_Grunnable状态。
        除了上述常见的协程状态外，协程还有一些其他的状态，比如_Gcopystack表示该协程正处于栈扩容流程中（Go协程的栈空间大小可动态扩缩），_Greempted表示协程被抢占后的状态。
        协程的调度流程
        
        GMP模型中存在三种类型的协程：
        
        普通的g：用户通过go关键字创建的协程，也就是GMP模型中需要被调度的G。
        g0：特殊的调度协程，每个M都有一个g0，其主要负责对普通的g进行运行调度。
        monitor g：全局监控协程，monitor g会越过P直接与一个M进行绑定，不断轮询对所有P的执行状况进行监控，如果发现满足抢占调度的条件，则会从第三方的角度出手干预，主动发起抢占调度。
        在创建M时，Go运行时系统会为每个M初始化一个g0，g0的调度流程如下：
        
        找到一个可被调度执行的G。
        将这个G的状态切换为_Grunning，并通过调用gogo函数将执行权交给G。
        执行G的代码逻辑，直到某些条件达成使得调度结束。
        G调度结束后，通过调用mcall函数将执行权交还给g0，并更新G的状态。
        示意图如下：
        
        调度类型
        
        GMP模型中的调度类型大致可分为如下四类：
        
        主动调度：用户通过调用runtime包中的Gosched函数，可以让当前G主动让出执行权，并将其投递到全局队列中等待下一次调度。
        被动调度：G在调度过程中，因为某些原因而陷入阻塞而导致调度终止，比如等待锁资源就绪或等待channel条件就绪等。
        正常调度：G的代码逻辑被正常执行完毕，调度终止。
        抢占调度：在G执行系统调用的情况下，如果满足了抢占调度的条件，那么monitor g会强行将当前的P和M进行解绑，让解绑后的P重新寻找一个空闲的M进行绑定，进而可以继续调度其他的G，而解绑后M则继续执行系统调用。
        触发前三种调度类型中的任意一种，都会导致当前G的调度终止，此时M的执行权将由普通的g交还给g0。示意图如下：
        
        上图说明：
        
        g0在调度普通的g时，会先通过findRunnable函数找到一个可被调度的G，然后通过execute函数更新对应G和P的状态信息，最后通过gogo函数将执行权交给G，进行G的调度。
        G在调度过程中，如果因为主动调度、被动调度或正常调度导致调度终止，那么会先调用mcall函数将执行权交还给g0，然后通过调用对应的函数更新G的状态信息，并完成G和M解绑等操作，然后开启新一轮的调度。
        gosched_m函数对应的是主动调度，该函数会先将G的状态由_Grunning切换为_Grunnable，然后将G和M解绑并将其投递到全局队列中，最后开启新一轮的调度。
        park_m函数对应的是被动调度，该函数会先将G的状态由_Grunning切换为_Gwaiting，然后将G和M解绑，最后开启新一轮的调度。
        goexit0函数对应的是正常调度，该函数会先将G的状态由_Grunning切换为_Gdead，然后将G和M解绑，最后开启新一轮的调度。
        关于被动调度：
        
        当因被动调度陷入阻塞的G对应的条件就绪时，会由导致条件就绪的G执行goready函数将其唤醒，唤醒时会先将G的状态由_Gwaiting切换为_Grunnable，然后将其添加到唤醒者的P的本地队列中。
        比如某个G在申请锁时由于锁资源不就绪而陷入阻塞，此时这个G会被放在锁对应的资源等待队列中，当另一个持有锁的G在被调度的过程中执行释放锁操作时，就会执行goready函数唤醒该锁对应的资源等待队列中的G，并将其添加到自己的P的本地队列中。
        在调度唤醒者时M的执行权在普通的g手中，而被唤醒者的状态切换操作以及G的投递操作需要由g0执行，因此在goready函数中会先将执行权交还给g0，并在执行唤醒操作后再重新获得执行权，这里的执行权交接是通过systemstack函数完成的。
        goready函数在将唤醒的G添加到唤醒者的P的本地队列中时，如果P的本地队列已满，则会将唤醒的G以及P的本地队列中一半的G放回到全局队列中，帮助当前的P缓解执行压力。
        关于抢占调度：
        
        在G需要执行系统调用之前，会先调用reentersyscall函数保存当前G的执行环境，并将G和P的状态更新为对应的系统调用状态，最后解除P和当前M之间的绑定，因为M即将进入系统调用而导致短暂不可用。与M解除绑定关系的P会被添加到当前M的oldp容器中，后续M执行完系统调用后会优先寻找该P重新建立绑定关系。
        在G执行系统调用期间，如果P的本地队列不为空，或者当前没有空闲的M和P，或者G执行系统调用的时间超过10ms，则monitor g会将当前M的oldp容器中的P的状态置为空闲，并让其与其他空闲的M（也可能新创建一个M）进行绑定，进而可以继续调度其他的G，而当前的M仍然继续执行系统调用。
        当M执行完系统调用后，会通过exitsyscall函数尝试寻找P进行绑定。如果此时M的oldp容器中的P仍然可用，则重新与该P建立绑定关系，并将G的状态重新置为_Grunning，继续执行后续的代码逻辑。如果原先的P已经不可用，则将G的状态置为_Grunnable，并解除G和M的绑定关系，尝试从全局P队列中寻找一个可用的P进行绑定，如果找到了则在绑定对应的P后继续调度该G，否则将该G投递到全局队列，并让当前的M陷入沉睡，直到被唤醒后再继续发起调度。
        协程间共享变量
        
        协程间共享变量
        
        在协程之间共享变量是常见的需求，以便协程之间能够进行数据交换和协同工作。
        为了保证共享资源的并发安全，通常需要引入互斥锁对共享资源进行保护。
        例如，下面程序中启动了4个协程进行抢票，在抢票过程中需要并发访问全局变量tickets，代码中通过加锁的方式保证了tickets变量的并发安全。如下：
        
        package main import ( "fmt" "sync" "time" ) var ( tickets = 1000 // 共享资源 mtx sync.Mutex // 互斥锁 ) func ByTicket(id int) { for { mtx.Lock() // 加锁 if tickets mtx.Unlock() // 解锁 break } time.Sleep(time.Microsecond) // 模拟抢票过程的耗时 tickets-- fmt.Printf("goroutine %d get a ticket, tickets = %d\n", id, tickets) mtx.Unlock() // 解锁 } } func main() { // 启动4个协程进行抢票 for i := 0; i