go语言中线程有几种模型 golang实现线程池

Golang 线程和协程的区别

线程：

多线程是为了解决CPU利用率的问题，线程则是为了减少上下文切换时的开销，进程和线程在Linux中没有本质区别，最大的不同就是进程有自己独立的内存空间，而线程是共享内存空间。

在进程切换时需要转换内存地址空间，而线程切换没有这个动作，所以线程切换比进程切换代价要小得多。

协程：

想要简单，又要性能高，协程就可以达到我们的目的，它是用户视角的一种抽象，操作系统并没有这个概念，主要思想是在用户态实现调度算法，用少量线程完成大量任务的调度。

Goroutine是GO语言实现的协程，其特点是在语言层面就支持，使用起来十分方便，它的核心是MPG调度模型：M即内核线程;P即处理器，用来执行Goroutine，它维护了本地可运行队列;G即Goroutine，代码和数据结构;S及调度器，维护M和P的信息。

相关问答

Q1: Golang的调度模型

Go有四大核心模块，基本全部体现在runtime，有调度系统、GC、goroutine、channel，那么深入理解其中的精髓可以帮助我们理解Go这一门语言！

参考: 调度系统设计精要

下面是我用Go语言简单写的一个调度器，大家可以看看设计思路，以及存在的问题！

1、测试条件，调度器只启动两个线程，然后一个线程主要是负责循环的添加任务，一个线程循环的去执行任务

2、测试条件，调度器启动三个线程，然后两个线程去执行任务，一个添加任务

3、继续测试，启动十个线程，一个添加任务，九个执行任务

4、我们添加一些阻塞的任务

执行可以看到完全不可用

1、 可以看到随着M的不断的增加，可以发现执行任务的数量也不断的减少，原因是什么呢？有兴趣的同学可以加一个pprof可以看看，其实大量的在等待锁的过程！

2、如果我的M运行了类似于Sleep操作的方法如何解决了，我的调度器还能支撑这个量级的调度吗？

关于pprof如何使用：在代码头部加一个这个代码：

我们查看一下 go tool pprof main/prof.pporf

可以看到真正执行代码的时间只有 0.17s + 0.02s 其他时间都被阻塞掉了！

1、GM模型中的所有G都是放入到一个queue，那么导致所有的M取执行任务时都会去竞争锁，我们插入G也会去竞争锁，所以解决这种问题一般就是减少对单一资源的竞争，那就是桶化，其实就是每个线程都分配一个队列

2、GM模型中没有任务状态，只有runnable，假如任务遇到阻塞，完全可以把任务挂起再唤醒

这里其实会遇到一个问题，假如要分配很多个线程，那么此时随着线程的增加，也会造成队列的增加，其实也会造成调度器的压力，因为它需要遍历全部线程的队列去分配任务以及后续会讲到的窃取任务！

因为我们知道CPU的最大并行度其实取决于CPU的核数，也就是我们没必要为每个线程都去分配一个队列，因为就算是给他们分配了，他们自己去那执行调度，其实也会出现大量阻塞，原因就是CPU调度不过来这些线程！

Go里面是只分配了CPU个数的队列，这里就是P这个概念，你可以理解为P其实是真正的资源分配器，M很轻只是执行程序，所有的资源内存都维护在P上！M只有绑定P才能执行任务（强制的）！

这样做的好处：

1、首先调度程序其实就是调度不同状态的任务，go里面为Go标记了不同的状态，其实大概就是分为：runnable，running，block等，所以如何充分调度不同状态的G成了问题，那么关于阻塞的G如何解决，其实可以很好的解决G调度的问题！

上面这些情况其实就分为：

2、用户态阻塞，一般Go里面依靠 gopark 函数去实现，大体的代码逻辑基本上和go的调度绑定死了

源码在：

3、其实对于netpool 这种nio模型，其实内核调用是非阻塞的，所以go开辟了一个网络轮训器队列，来存放这些被阻塞的g，等待内核被唤醒！那么什么时候会被唤醒了，其实就是需要等待调度器去调度了！

4、如果是内核态阻塞了（内核态阻塞一般都会将线程挂起，线程需要等待被唤醒），我们此时P只能放弃此线程的权利，然后再找一个新的线程去运行P！

关于着新线程：找有没有idle的线程，没有就会创建一个新的线程！

关于当内核被唤醒后的操作：因为GPM模型所以需要找到个P绑定，所以G会去尝试找一个可用的P，如果没有可用的P，G会标记为runnable放到全局队列中！

5、其实了解上面大致其实就了解了Go的基本调度模型

答案文章里慢慢品味！

如果某个 G 执行时间过长，其他的 G 如何才能被正常的调度？ 这便涉及到有关调度的两个理念：协作式调度与抢占式调度。协作式和抢占式这两个理念解释起来很简单： 协作式调度依靠被调度方主动弃权；抢占式调度则依靠调度器强制将被调度方被动中断。

例如下面的代码，我本地的版本是 go1.13.5

执行: GOMAXPROCS=1 配置全局只能有一个P

可以看到main函数无法执行!也就是那个go 空转抢占了整个程序

备注：

但是假如我换为用 1.14+版本执行，有兴趣的话可以使用我的docker镜像，直接可以拉取： fanhaodong/golang:1.15.11 和 fanhaodong/golang:1.13.5

首先我们知道G/M/P，G可能和M也可能和P解除绑定，那么关于数据变量放在哪哇！其实这个就是逃逸分析！

输出可以看到其实没有发生逃逸，那是因为 demo被拷贝它自己的栈空间内

备注：

-gcflags"-N -l -m" 其中 -N禁用优化-l禁止内联优化，-m打印逃逸信息

那么继续改成这个

可以看到发现 demo对象其实被逃逸到了堆上！这就是不会出现类似于G如果被别的M执行，其实不会出现内存分配位置的问题！

所以可以看到demo其实是copy到了堆上！这就是g逃逸的问题，和for循环一样的

执行可以发现，其实x已经逃逸到了堆上，所以你所有的g都引用的一个对象，如何解决了

如何解决了，其实很简单

也谈goroutine调度器

图解Go运行时调度器

Go语言回顾：从Go 1.0到Go 1.13

Go语言原本

调度系统设计精要

Scalable Go Scheduler Design Doc

Q2: 用多线程又有几种常用的编程模型

我这里可以大概给你介绍一下 但对于每一种编程模型要看具体的示例是什么 而且我不可能给你罗列所有的代码 请谅解 其实我们编程只要尽量站到比较高的层次 很多道理其实你会发现你已经懂了 就多线程来说 我们开始设想只有两个线程（ 时是不是算数学归纳法？）那么如果两个独立的线程会发生什么呢？ 当一个线程进入moniter（也就是说站用一个object） 另一个线程只有等待或返回 而我们把返回就称为一种模式 这种模式的英文是Balking 这两个线程可以是有序的执行 而不是让OS来调度 这时我们要用一个object来调度 这种模式称为Scheduler （这个词及其含义其实OS中就有） 如果这两个线程同时读一个资源 我们可以让他们执行 但如果同时写的话 你闭着眼睛都会知道可能出现问题 这时我们就要用另一种模式（Read/Write Lock） 如果一个线程是为另一个线程服务的话 比如IE中负责数据传输的线程和界面显示的线程 当一个图片没有传完时 另一个线程就无法显示 至少是部分没有传完 那么这时我们要用一个模式称为生产者和消费者 英文是Producer Consumer 两个线程的消亡也可以不是完全又OS来控制的 这时我们需要给出一个条件 使得每个线程在符合条件是才消亡 也就是有序的消亡 我们称为Two Phase Termination 那么有这 个线程模型 基本上可以用到大多数编程任务中 我需要指出的三点是 从高层次上我们可以再验证是否含盖了所有的情况 其实模式不是完全固定的或者说象定律一样 而模式可以为不同的情况进行适当 的调整和组合 目的是为了简洁和高效 学习模式是为了具备更好的分析问题的能力 而似乎这些来自西方的技术 并且是目前的 我们有没有呢？其实我个人有个大胆的推测 我认为我们祖先的《孙子兵法》就是很好设计模式 因为它符合设计模式需要的基本特征 就是在特定的条件下 用某种特定的方式合理且高效的解决问题 只不过一是用在军事上 二是完备性方面我们还没研究 但我认为我们至少没有很好的扩展和进行类比式的应用 否则今天可能是我们中国人教外国人什么是设计模式 类比的方法实际上是发明或发现的常用方法 不知能否让你感觉到其实外国的技术并不是那么的神秘 也许我们从自身的文化当中挖掘出的东西太少了 P S 更深一步的研究你可以参考Doug Lea lishixinzhi/Article/program/Java/gj/201311/27428

Q3: Go语言——goroutine并发模型

参考：

Goroutine并发调度模型深度解析手撸一个协程池

Golang 的 goroutine 是如何实现的？

Golang - 调度剖析【第二部分】

OS线程初始栈为2MB。Go语言中，每个goroutine采用动态扩容方式，初始2KB，按需增长，最大1G。此外GC会收缩栈空间。

BTW，增长扩容都是有代价的，需要copy数据到新的stack，所以初始2KB可能有些性能问题。

更多关于stack的内容，可以参见大佬的文章。 聊一聊goroutine stack

用户线程的调度以及生命周期管理都是用户层面，Go语言自己实现的，不借助OS系统调用，减少系统资源消耗。

Go语言采用两级线程模型，即用户线程与内核线程KSE（kernel scheduling entity）是M:N的。最终goroutine还是会交给OS线程执行，但是需要一个中介，提供上下文。这就是G-M-P模型

Go调度器有两个不同的运行队列：

go1.10\src\runtime\runtime2.go

Go调度器根据事件进行上下文切换。

调度的目的就是防止M堵塞，空闲，系统进程切换。

详见 Golang - 调度剖析【第二部分】

Linux可以通过epoll实现网络调用，统称网络轮询器N（Net Poller）。

文件IO操作

上面都是防止M堵塞，任务窃取是防止M空闲

每个M都有一个特殊的G，g0。用于执行调度，gc，栈管理等任务，所以g0的栈称为调度栈。g0的栈不会自动增长，不会被gc，来自os线程的栈。

go1.10\src\runtime\proc.go

G没办法自己运行，必须通过M运行

M通过通过调度，执行G

从M挂载P的runq中找到G，执行G

Q4: golang csp 模型

调度器 由三方面实体构成：

三者对应关系：

上图有2个 物理线程 Mgo语言中线程有几种模型，每一个 M 都拥有一个上下文（P）go语言中线程有几种模型，每一个也都有一个正在运行go语言中线程有几种模型的goroutine（G）。

P 的数量可由 runtime.GOMAXPROCS() 进行设置，它代表go语言中线程有几种模型了真正的并发能力，即可有多少个 goroutine 同时运行。

调度器为什么要维护多个上下文P 呢？ 因为当一个物理线程 M 被阻塞时，P 可以转而投奔另一个OS线程 M （即 P 带着 G 连茎拔起，去另一个 M 节点下运行）。这是 Golang调度器厉害的地方，也是高并发能力的保障。

Q5: Go CSP并发模型

Gogo语言中线程有几种模型的CSP并发模型

Go实现go语言中线程有几种模型了两种并发形式。第一种是大家普遍认知go语言中线程有几种模型的：多线程共享内存。其实就是Java或者C++等语言中的多线程开发。另外一种是Go语言特有的go语言中线程有几种模型，也是Go语言推荐的：CSP（communicating sequential processes）并发模型。

CSP 是 Communicating Sequential Process 的简称，中文可以叫做通信顺序进程，是一种并发编程模型，由 Tony Hoare 于 1977 年提出。简单来说，CSP 模型由并发执行的实体（线程或者进程）所组成，实体之间通过发送消息进行通信，这里发送消息时使用的就是通道，或者叫 channel。CSP 模型的关键是关注 channel，而不关注发送消息的实体。 Go 语言实现了 CSP 部分理论 。

“ 不要以共享内存的方式来通信，相反， 要通过通信来共享内存。”

Go的CSP并发模型，是通过 goroutine和channel 来实现的。

goroutine 是Go语言中并发的执行单位。其实就是协程。

channel是Go语言中各个并发结构体(goroutine)之前的通信机制。 通俗的讲，就是各个goroutine之间通信的”管道“，有点类似于Linux中的管道。

Channel

Goroutine

go语言中线程有几种模型的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于golang实现线程池、go语言中线程有几种模型的信息别忘了在本站进行查找喔。