Go的CSP并发模型
十年的枣强网站建设经验,针对设计、前端、开发、售后、文案、推广等六对一服务,响应快,48小时及时工作处理。成都营销网站建设的优势是能够根据用户设备显示端的尺寸不同,自动调整枣强建站的显示方式,使网站能够适用不同显示终端,在浏览器中调整网站的宽度,无论在任何一种浏览器上浏览网站,都能展现优雅布局与设计,从而大程度地提升浏览体验。创新互联从事“枣强网站设计”,“枣强网站推广”以来,每个客户项目都认真落实执行。
Go实现了两种并发形式。第一种是大家普遍认知的:多线程共享内存。其实就是Java或者C++等语言中的多线程开发。另外一种是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
参考:
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
内核线程(Kernel-Level Thread ,KLT)
轻量级进程(Light Weight Process,LWP):轻量级进程就是我们通常意义上所讲的线程,由于每个轻量级进程都由一个内核线程支持,因此只有先支持内核线程,才能有轻量级进程
用户线程与系统线程一一对应,用户线程执行如lo操作的系统调用时,来回切换操作开销相对比较大
多个用户线程对应一个内核线程,当内核线程对应的一个用户线程被阻塞挂起时候,其他用户线程也阻塞不能执行了。
多对多模型是可以充分利用多核CPU提升运行效能的
go线程模型包含三个概念:内核线程(M),goroutine(G),G的上下文环境(P);
GMP模型是goalng特有的。
P与M一般是一一对应的。P(上下文)管理着一组G(goroutine)挂载在M(内核线程)上运行,图中左边蓝色为正在执行状态的goroutine,右边为待执行状态的goroutiine队列。P的数量由环境变量GOMAXPROCS的值或程序运行runtime.GOMAXPROCS()进行设置。
当一个os线程在执行M1一个G1发生阻塞时,调度器让M1抛弃P,等待G1返回,然后另起一个M2接收P来执行剩下的goroutine队列(G2、G3...),这是golang调度器厉害的地方,可以保证有足够的线程来运行剩下所有的goroutine。
当G1结束后,M1会重新拿回P来完成,如果拿不到就丢到全局runqueue中,然后自己放到线程池或转入休眠状态。空闲的上下文P会周期性的检查全局runqueue上的goroutine,并且执行它。
另一种情况就是当有些P1太闲而其他P2很忙碌的时候,会从其他上下文P2拿一些G来执行。
详细可以翻看下方第一个参考链接,写得真好。
最后用大佬的总结来做最后的收尾————
Go语言运行时,通过核心元素G,M,P 和 自己的调度器,实现了自己的并发线程模型。调度器通过对G,M,P的调度实现了两级线程模型中操作系统内核之外的调度任务。整个调度过程中会在多种时机去触发最核心的步骤 “一整轮调度”,而一整轮调度中最关键的部分在“全力查找可运行G”,它保证了M的高效运行(换句话说就是充分使用了计算机的物理资源),一整轮调度中还会涉及到M的启用停止。最后别忘了,还有一个与Go程序生命周期相同的系统监测任务来进行一些辅助性的工作。
浅析Golang的线程模型与调度器
Golang CSP并发模型
Golang线程模型
GO语言的优势:可直接编译成机器码,不依赖其他库,glibc的版本有一定要求,部署就是扔一个文件上去就完成了。静态类型语言,但是有动态语言的感觉,静态类型的语言就是可以在编译的时候检查出来隐藏的大多数问题,动态语言的感觉就是有很多的包可以使用,写起来的效率很高。语言层面支持并发,这个就是Go最大的特色,天生的支持并发,我曾经说过一句话,天生的基因和整容是有区别的,大家一样美丽,但是你喜欢整容的还是天生基因的美丽呢?Go就是基因里面支持的并发,可以充分的利用多核,很容易的使用并发。内置runtime,支持垃圾回收,这属于动态语言的特性之一吧,虽然目前来说GC不算完美,但是足以应付我们所能遇到的大多数情况,特别是Go1.1之后的GC。简单易学,Go语言的作者都有C的基因,那么Go自然而然就有了C的基因,那么Go关键字是25个,但是表达能力很强大,几乎支持大多数你在其他语言见过的特性:继承、重载、对象等。丰富的标准库,Go目前已经内置了大量的库,特别是网络库非常强大,我最爱的也是这部分。内置强大的工具,Go语言里面内置了很多工具链,最好的应该是gofmt工具,自动化格式化代码,能够让团队review变得如此的简单,代码格式一模一样,想不一样都很困难。跨平台编译,如果你写的Go代码不包含cgo,那么就可以做到window系统编译linux的应用,如何做到的呢?Go引用了plan9的代码,这就是不依赖系统的信息。Go语言这么多的优势,你还不想学吗?我记得当时我看的是黑马程序员的视频,我对他们视频的印象就是通俗易懂,就是好!
1.根据Rust的特点和定位适用于对控制性比较强,对性能很敏感的领域,比如底层软件(OS/driver),基础系统软件(Compiler/VM/DB等),性能要求比较高的应用软件(浏览器/图形图像处理/游戏/高性能服务器软件等,或者可能包括近来很火的ML应用方向)。2.底层软件(比如OS/driver)部分是和C应用领域有很大重合度的,在这个领域我认为对C冲击不大。在这里C已经足够好了,而且这些领域技术性很高,但业务逻辑其实并不算太复杂,Rust的优势作用有限。而且Rust相比于C语言,带来了一定的“黑盒”和这些领域一些不需要的语言复杂特性。C作为“可移植的汇编”恰到好处的非常适合这个领域,其他语言基本无法构成挑战。3.前面1中提到的领域除了底层软件(OS/driver之类)剩下的领域,C++目前最具有优势。在这些领域C++相对于C提供了高级特性方便开发,相对于JVM系的性能更高内存更少。(虽然这些领域有些知名软件是C和JVM系的,比如postgresql/redis/nginx/Hadoop/spark等,但在这些领域目前只有C++一个是全能型)我认为rust的主要战场就在这里,需要对决的对手就是C++。C++既有的力量(系统/代码/人员/习惯)太强大了,在这些领域完全打败C++是非常困难的。而且C++也在不断发展,近年来发展的步伐也快了起来,C++11/14/17等等。但C++的历史包袱是很重的,越发展其实复杂性也在不断提高,何况有些问题(像安全/异常/复杂继承等等)是基因里的,通过增加feature打补丁是弥补不了的。Rust最容易吸引的人群可能是C++程序员:因为,一方面解决了不少C++的痛点,另一方面Rust的很多特性其实有点复杂也有点门槛的。这些特性背后的动因有C++背景的程序员是非常容易理解,也是不少C++程序员梦寐以求的。相对而言,其他语言背景出身的程序员,对Rust的共鸣性远远没有C++程序员强烈。猜测Rust会:a.蚕食掉一定的C++份额。一些可能本会选择C++开发的新项目,可能会选择Rust。b.蚕食掉一定的Java份额。有些项目选择JVM系是由于C++开发太复杂,同时该项目对性能又有一定的要求。那么Rust出现以后也会蚕食掉一定的此类项目。c.蚕食掉一定的golang份额。不满意gc(即使1.5改善了,gc的先天问题是无法彻底解决的),不满意泛型,不满意性能的一部分项目。不过也要依赖于Rust未来并发的解决方案是否足够理想了。1.0这种是没戏的。d.移动端Rust从自己实力上说是够的。不过这个真的要看出品移动端设备的“爹”的意思了。Rust自身有一些优势非常明显,在这些领域是很有竞争力的。Rust社区一定要重视IDE开发环境,花费精力出eclipse/intellji/vs的高质量的IDE插件,对于推广和流行大有帮助。只要Rust社区不要犯D语言曾经反复折腾的毛病,能像golang社区那样基础做的不错并且工程质量优秀,那么未来Rust出几个杀手级的应用,前途还是很可期的。