2024年Go最全golang基础教程（十七）GO并发原理_go高并发原理视频教程(2)，春招我借这份PDF的复习思路-CSDN博客

本文链接：https://blog.csdn.net/2401_84924864/article/details/138979597

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

在这里插入图片描述
左边的goroutine开始阻塞，等待有人接收。

这时候，右边的goroutine发起了接收操作。
在这里插入图片描述
右边的goroutine也开始阻塞，等待别人传送。

这时候，两边goroutine都发现了对方，于是两个goroutine开始一传，一收。

在这里插入图片描述
这便是Golang CSP并发模型最基本的形式。

3、GO并发模型的实现原理

我们先从线程讲起，无论语言层面何种并发模型，到了操作系统层面，一定是以线程的形态存在的。而操作系统根据资源访问权限的不同，体系架构可分为用户空间和内核空间；内核空间主要操作访问CPU资源、I/O资源、内存资源等硬件资源，为上层应用程序提供最基本的基础资源，用户空间呢就是上层应用程序的固定活动空间，用户空间不可以直接访问资源，必须通过“系统调用”、“库函数”或“Shell脚本”来调用内核空间提供的资源。

我们现在的计算机语言，可以狭义的认为是一种“软件”，它们中所谓的“线程”，往往是用户态的线程，和操作系统本身内核态的线程（简称KSE），还是有区别的。

线程模型的实现，可以分为以下几种方式：

用户级线程模型

如图所示，多个用户态的线程对应着一个内核线程，程序线程的创建、终止、切换或者同步等线程工作必须自身来完成。
内核级线程模型

这种模型直接调用操作系统的内核线程，所有线程的创建、终止、切换、同步等操作，都由内核来完成。C++就是这种。
两级线程模型

这种模型是介于用户级线程模型和内核级线程模型之间的一种线程模型。这种模型的实现非常复杂，和内核级线程模型类似，一个进程中可以对应多个内核级线程，但是进程中的线程不和内核线程一一对应；这种线程模型会先创建多个内核级线程，然后用自身的用户级线程去对应创建的多个内核级线程，自身的用户级线程需要本身程序去调度，内核级的线程交给操作系统内核去调度。
Go语言的线程模型就是一种特殊的两级线程模型。暂且叫它“MPG”模型吧。

二、Go线程实现模型MPG

为了完成调度任务，Go Scheduler使用3个主要实体：
在这里插入图片描述
M指的是Machine，代表OS线程。它是由OS管理的执行线程，其工作方式与标准POSIX线程非常相似。在运行时代码中，它被称为M for machine。
P指的是”processor”，表示调度的上下文。您可以将其视为调度程序的本地化版本，该调度程序在单个线程上运行Go代码。这是让我们从N：1调度程序转到M：N调度程序的重要部分。在运行时代码中，它被称为P for processor。
G指的是Goroutine，代表一个goroutine。它包括堆栈，指令指针和其他对调度goroutine很重要的信息，就像它可能被阻塞的任何通道一样。其实本质上也是一种轻量级的线程。在运行时代码，它被称为G。
三者关系如下图所示：
在这里插入图片描述
这里我们看到2个线程（M），每个线程都有一个上下文（P），每个线程都运行一个goroutine（G）。为了运行goroutine，线程必须保存上下文。

上下文的数量在启动时设置为GOMAXPROCS环境变量的值或通过运行时函数GOMAXPROCS()。通常情况下，在程序执行期间不会更改。上下文数量固定的事实意味着只GOMAXPROCS在任何时候运行Go代码。我们可以使用它来调整Go进程到个人计算机的调用，例如4核PC在4个线程上运行Go代码。

灰色的goroutines没有运行，但已准备好安排。它们被安排在名为runqueues的列表中。只要goroutine执行go语句，Goroutines就会被添加到runqueue的末尾。一旦上下文运行goroutine直到调度点，它会从其runqueue中弹出goroutine，设置堆栈和指令指针并开始运行goroutine。

为了降低互斥争用，每个上下文都有自己的本地runqueue。以前版本的Go调度程序只有一个带有互斥锁保护它的全局runqueue。线程经常被阻塞，等待互斥锁解锁。当你有32台核心机器想要尽可能多地挤出性能时，这真的很糟糕。

只要所有上下文都有运行goroutine，调度程序就会在此稳定状态下继续进行调度。但是，有几种情况可以改变这种情况。

三者关系的宏观的图为：
在这里插入图片描述
抛弃P(Processor)？
你可能会想，为什么一定需要一个上下文，我们能不能直接除去上下文，让Goroutine的runqueues挂到M上呢？答案是不行，需要上下文的目的，是让我们可以直接放开其他线程，当遇到内核线程阻塞的时候。

一个很简单的例子就是系统调用sysall，一个线程肯定不能同时执行代码和系统调用被阻塞，这个时候，此线程M需要放弃当前的上下文环境P，以便可以让其他的Goroutine被调度执行。

在这里插入图片描述
在这里，我们看到一个线程放弃了它的上下文，以便另一个线程可以运行它。调度程序确保有足够的线程来运行所有上下文。上图中的M1可能仅为处理此系统调用而创建，或者它可能来自线程缓存。系统调用线程将保持创建系统调用的goroutine，因为它在技术上仍在执行，尽管在操作系统中被阻止。

当系统调用返回时，线程必须尝试获取上下文才能运行返回的goroutine。正常的操作模式是从其他线程之一窃取上下文。如果它不能窃取一个，它会将goroutine放在全局runqueue上，将自己置于线程缓存中并进入休眠状态。

全局runqueue是一个runxue，当它们用完本地runqueue时，它们会从中获取。上下文还定期检查goroutines的全局runqueue。否则，由于饥饿，全局运行队列中的goroutine最终可能永远不会运行。

这种系统调用的处理是Go程序运行多个线程的原因，即使GOMAXPROCS是1.运行时使用调用系统调用的goroutine，留下线程。
均衡的分配工作
按照以上的说法，上下文P会定期的检查全局的goroutine 队列中的goroutine，以便自己在消费掉自身Goroutine队列的时候有事可做。假如全局goroutine队列中的goroutine也没了呢？就从其他运行的中的P的runqueue里偷。

每个P中的Goroutine不同导致他们运行的效率和时间也不同，在一个有很多P和M的环境中，不能让一个P跑完自身的Goroutine就没事可做了，因为或许其他的P有很长的goroutine队列要跑，得需要均衡。
该如何解决呢？

Go的做法倒也直接，从其他P中偷一半！
在这里插入图片描述