golang 从http.request中取参数_golang的协程调度硬核原理

系统线程存在的弊端

现代操作系统的架构中,都是多用户多任务模式,多任务的执行是基于系统线程完成的,首先进程是一个程序运行时的内存抽象,包含了其执行需要的全部资源,为了可以多任务执行程序,使程序在单核cpu上像多个任务同时执行一样,那么就需要多进程进行调度,最常用的就是分时调度模型,一个进程在cpu上执行一段时间后就会被通过发送中断信号 INT21 进行调度,保存各个寄存器的状态形成上下文存入进程,然后从队列中取出下一个等待执行的进程,取出它的上下文装载cpu的各个寄存器状态ESP指令等,恢复进程的执行。但是很多时候我们编写程序的时候并非是顺序执行的,我们有时需要并发执行程序,一个进程中我们需要可以同时执行多段指令代码,但是对于CPU每次只能让一段代码在流水线上执行。如果仅有进程级别的调度,那么我们永远无法实现并发编程,为了解决这个问题,伟大的计算机科学家们设计了线程,一种比进程轻量级的执行单元,从此cpu再也不认识进程了,进程不再是执行单位,而是一个资源隔离单位,一个进程内部可以有多个系统线程,每个系统线程可以作为一个独立的代码执行单元,被绑定到一个CPU的流水线上执行。这样在逻辑上一个程序的多个代码片段就可以像是可以同时执行了一样,而且线程的资源比进程资源占用少,维护的状态也少,调度切换的效率更高。这样不仅可以并发编程,性能也得到了提高。 再后来,随着摩尔定律的失效,人们开始了对多核处理器的探寻之路,程序才得以真正的并行执行,所以所谓的并发仅是一种编程方式,并非真正的并行执行,当同一个进程的线程在多个处理器上运行时,才是真正的并行。 多核架构的出现,使多线程编程成为了主流趋势,并发与并行的应用使得很多无法实现的事情变成了可能,业务规模进一步扩大,终于量变引起了质变,从前牛逼无比的多线程模型,出现了种种问题。 首先我们开始觉得线程维护的状态实在太多了,线程存在的意义是可以在一个程序中同时执行多个指令流,而维护线程的状态与数据只是一种成本。这种成本体现在要维护线程复杂的状态切换,寄存器指令,调用函数栈的存储。一个线程栈初始化默认的线程栈大小是8M,无论线程是否会使用到8M的栈空间。开辟与释放栈空间是很浪费时间的,一个线程的开辟需要消耗非常多的资源(当然比进程小的多的多).在当今动不动就上千个线程的程序里(网络通信中经常需要开辟线程),我们的资源不足!同时与团队管理很像,团队人数多的时候如何分配任务,如何调度所有人都将成为非常耗时的事情,线程也同样如此。从空间与时间上,线程本身已经成为了性能的瓶颈。

协程,大并发时代的高效工具

线程的出现可以说是并发与并行共同驱使导致的,而协程是专门为了提高并发而设计的。明白这样的本质,接下来才不会绕晕。那怎么做到这一点?首先,操作系统是如何执行一个程序的呢? 站在很宏观的角度上看,操作系统执行程序可以分为用户态与系统态,当进程启动时,默认只有一个线程,但是在多线程的程序中,应用进行了系统调用,发送了一个信号到操作系统内核中,系统内核创建了一个系统线程,关联进程,应用通过系统调用来控制系统线程的状态,通过控制他的状态,我们可以控制CPU对线程的调度行为。CPU的调度是一个复杂的过程,最简单的说每个cpu维护一个可运行队列通过时间片,来轮询可运行队列里处于就绪状态的线程,当时间片到期,则cpu会保存线程上下文,修改线程状态调度下一个线程。 协程并没有改变cpu的这个逻辑,对于协程,CPU是不关心的。协程只是一个应用级用户态的概念。 是模拟cpu的调度过程编写的一套实现逻辑与运行的线程解藕的组件。线程将业务逻辑与进程解藕,使得业务不需要随着进程进行调度,协程也是如此,使业务随着协程调度,脱离线程。但是cpu真正认识的还是线程,所以实际上协程还是跑在线程中的,只不过线程执行的是调度协程的逻辑,在恰当时机执行协程的代码逻辑。

协程真的好吗？

协程解决了,以大量并发模式写代码的问题,但软件工程至今没解决的问题就是:以复杂治理复杂. 现在假设,有A,B,C三个线程。A线程中按照上述协程理论我们定义A1,A2,A3,三个协程。同理,B,C上也有三个协程。A,B,C线程上执行的是调度这些协程的逻辑。我们想一下,是不是需要一个全局的数据结构可以让这些线程在没有协程执行的情况下可以去先获取一下待执行的协程,如果没有则休眠。那么什么数据结构是最佳选择?仿照CPU的调度,队列是最好的选择,所以我们要维护一个全局的协程队列,线程从中获取协程来执行。同时,还需要的是什么呢？调度逻辑说到底还是应用级别代码,没法利用时钟中断来终止协程的执行。无法终止执行,也就无法进行调度。所以最简单的办法就是定义一些触发调度的点,比如程序进行系统调用时,网络IO时,等等执行时间不是很确定的时候,为了不阻塞其他协程执行,同时为了防止某些在未定义的调度点处执行时间过长,我们启动一个后台监控的线程专门来监控那些执行时间过长的协程,将其强制调度(如果都使用监控线程切换,性能比较低)。协程的状态如何维护?,状态与函数调用栈的模拟都可以封装在一个结构体中,当获取这个协程的结构题,从中解析协程的状态,调用栈的现场恢复后就可以执行协程的逻辑,调度切换时,可以将其状态写入这个结构体,保存上下文。这样我们就大体实现了协程调度的逻辑,这也是协程主流的实现方法,基本支持协程的语言或框架都是这样的一个思路。但是,这里面有几个问题:首先,我如果有很多线程在执行协程调度,都去全局队列中获取或者写入协程,是不是会有多线程安全问题?说到底,真正在cpu流水线上执行的是线程,协程的调度只是增加了一个中间层。所以协程并没有使计算变快,它只是适用于数据密集型任务,并发场景而不是并行场景。 同时,增加中间层固然使开发变的简单,但也增加了复杂性,一旦出现问题,问题将更难被分析,并发程序的问题本来就很难分析,提升了并发度,问题将更加复杂化(事件驱动模式在这方面似乎更好一些)。 若以在学习go的协程之前,我们必须正确的理解协程本身,否则为自己错误的使用而犯错。

goroutine,先进的协程

终于说到我们的主角了,go的协程与其他的大众协程有着很多不同的地方,这些地方导致goroutine,似乎不像是一个简简单单的协程,跟像是一种新的事物。go中使用M,一个结构体对象来代表真实的系统线程,她的一个字段封装了一个系统线程。其他字段用于控制这个线程,实现协程调度逻辑。同时,为了防止从全局队列中取数据,每个M自身维护了一个局部的协程队列,协程在golang中以G结构体对象表示,封装了协程的执行栈,协程状态等数据。这样,通过局部缓存的方式避免了加锁从全局队列拿G造成的性能下降。每次M执行完一个G就从局部就绪队列拿一个G来执行。你看,目前来看go的协程似乎解决了问题,真正的实现了大并发编程。但是,如果他的的实现真的如此的话,那么问题将会不少。 首先,要明白所有的问题来自于我们没办法像cpu那样调度协程,对何时调度协程这个问题没有完美的方案。比如说,如果一个M欢快的执行着G,在G的逻辑中发生了系统调用,去请求内核完成一向任务,甚至是自己进行复杂耗时的运算,这种场景下假设无法调度G,那么在M中排队的其他线程将无法执行,这就造成了G的饥饿。一个G影响了所有G的执行,这似乎在大并发下可能很常见,一个G处理一年内的新闻热度统计,一个G只是想查看当前的一篇新闻,假设两个G都在同一个M上,统计G一直在执行计算,没有进入调度点,这时该怎么办？监控线程来调度吗？那这种情况非常非常多,要起很多监控线程吗？我们的设计到此似乎陷入来两难的境地。 在左右为难的时候,无论进行何种取舍都无法满足要求的时候,这就要用到设计领域的必杀技,添加中间层。 于是,Golang的设计者们决定解决协程的设计难题--协程的执行者和协程的状态维护者即使变成了两个对象还是耦合的。这样就引入一个新的结构体:P,一个G的执行上下文.在计算机科学中,我们通常将那些既不是A也不是B的东西统统的称之为上下文,对于P既不是协程执行者M,也不是协程状态的维护者G,而是一个存储一个局部的协程执行就绪队列等等一系列缓存相关的数据结构,go的调度机制中,大量的应用局部缓存来避免全局竞争造成的性能损失。这样,M就不再维护状态,专心的从P中取出一个G来执行,当一个G执行时间过长的时候,我们把它从P中剔除,将P与M分离,带着P去找一个新的M. 一个很好的比喻,M就是一个地鼠,真正干活的土拨鼠;P是一个推车装载着,小地鼠需要干的活-要搬的砖,G就是砖头,小地鼠要搬的砖。接下来我们将以结合源码与这个比喻去理解go的调度机制。 点击这里,查看官方goroutine设计文档

Go程序启动时,调度器的初始化

go的标准SDk中有一个runtime包,这个包用来管理golang程序的运行时行为。我们的源码之旅从协程调度器的初始化,开始.

• go的程序从哪里开始? mac 版本默认安装在:/usr/local/Cellar/go/1.11.4/libexec/src/runtime目录下。 有一个文件:asm_amd64.s,go是静态语言,所以底层的汇编实现会根据不同的处理器架构而有所区别,这里主要完成命令行参数的解析与整理,还有就是调度器的初始化。

        // .....省略.....CALL	runtime·args(SB) // 命令行参数初始化CALL	runtime·osinit(SB) // 系统线程初始化CALL	runtime·schedinit(SB) // 调度初始化

程序初始化时,解析完命令行参数后,当然是初始化runtime系统协程了。对于go的runtime,他将业务执行的协程与runtime完成自身功能的协程分离开来,这样做是为了更好的完成管理与隔离二者,避免在监控管理上的麻烦。所以在此时会初始化一个m0,启动一个系统线程与m0相关联,然后在启动一个runtime逻辑工作的函数栈,g0,初始大小8k,所有的runtime的系统逻辑都在此栈上完成。注意这时并没有真正的创建一个G,要知道go main包下的main函数,也会被封装在一个G中执行。但是此时并没有创建,只是创建了一个函数调用栈g0,用来执行runtime的自身逻辑,同时要注意到,上面的汇编代码是asm_amd64.s中的,这是一个引导文件。之后就进入到了,引导文件调用proc.go文件中,m0,g0是全局变量。

var (
m0           m
g0           g
raceprocctx0 uintptr
)

命令行参数与系统协程初始化后进入了初始化阶段的主要过程.首先,初始化的应该是真正的系统线程,这里默认最大允许使用的系统线程是10000个。然后初始化一个系统线程栈,在其基础上创建一个M的对象作为真正执行当下main.main函数的M,创建一个内存分配器,用来管理runtime的内存使用,创建垃圾回收协程,用来进行垃圾回收。最后根据命令行中指定的P的数量来调节P的数量大小,P在初始的时候默认是与操作系统处理器的数量相同,但是可以在命令行或程序中人为的指定。本质P都是放在一个allp的队列中,调整其大小,就是增加一些p的数量，或减少一些p的数量。

func schedinit() {
    // raceinit must be the first call to race detector.// In particular, it must be done before mallocinit below calls racemapshadow._g_ := getg()if raceenabled {
    
		_g_.racectx, raceprocctx0 = raceinit()
	}
	sched.maxmcount = 10000 //最大开辟系统线程10000tracebackinit()moduledataverify() // 各个模块的一些检验stackinit()   //栈空间的初始化mallocinit()  //内存管理器初始化mcommoninit(_g_.m)cpuinit()       // 多个cpu架构下的一些初始化操作alginit()       // maps must not be used before this callmodulesinit()   // modules功能的一些初始化typelinksinit() // uses maps, activeModulesitabsinit()     // uses activeModulesmsigsave(_g_.m)
	initSigmask = _g_.m.sigmaskgoargs()  //命令行参数初始化goenvs() // 环境变量初始化parsedebugvars() //处理 debug参数gcinit() //gc 回收器初始化
	sched.lastpoll = uint64(nanotime())// 调整P的数量procs := ncpuif n, ok := atoi32(gogetenv("GOMAXPROCS")); ok && n > 0 {
    
		procs = n
	}if procresize(procs) != nil {
    throw("unknown runnable goroutine during bootstrap")
	}
    .....

在这里真正的创建了一个G来执行main函数

	// create a new goroutine to start programMOVQ	$runtime·mainPC(SB), AX		// entryPUSHQ	AXPUSHQ	$0			// arg sizeCALL	runtime·newproc(SB)POPQ	AXPOPQ	AX

到了这里还没有开始执行业务逻辑的main函数,runtime还是没有完全初始化完毕,runtim本质就是go程序的工作环境,还需要继续创建go程序的执行条件. 这是就进入了 runtime.main()函数内,此时runtime环境大体已经创建完毕,开始逐步的开始构建执行业务逻辑的环境,开始先设置一下函数栈的最大值等一些初始化参数,以检测在什么时候栈溢出.根据处理器的架构,默认64位1G栈大小,32为250M大小。此时需要创建很关键的东西了,我们知道go的调度是在应用层设计的,为了能够做到系统级别的功能(如时钟中断),需要一个奶妈一样的线程来监控管理整个runtime的运行时的大小事务,它叫做MONSYS线程,主要监控垃圾回收与协程调度管理。

// Allow newproc to start new Ms.
	mainStarted = trueif GOARCH != "wasm" { // no threads on wasm yet, so no sysmonsystemstack(func() { // systemstack函数主要作用是切换调用栈,语意为在g0系统栈上执行这个函数。newm(sysmon, nil)
		})
	}

此时还需要初始化一些函数,先初始化runtime包下的init函数

runtime_init() // must be before deferif nanotime() == 0 {
    throw("nanotime returning zero")
	}

当万事具备后将真的开始执行代码了,先会实现main包下的init函数,按照main包下go源文件名称的字典顺序来执行。

fn := main_init // make an indirect call, as the linker doesn't know the address of the main package when laying down the runtimefn()close(main_init_done)

到此将真正的执行用户的逻辑,main包下的main函数:

fn = main_main // make an indirect call, as the linker doesn't know the address of the main package when laying down the runtimefn()

这些函数都是编译器生成的,连接器不知道具体的地址,因此需要使用上面的这种形式进行调用。

main_main代表着真正需要执行的用户逻辑代码,当其全部执行完毕后。 runtime.main函数最后调用exit(0)正确退出go进程。

创建一个go协程源码分析

我们从 go function... 这行代码开始分析,这其中到底发生了什么？

// create a new goroutine to start programMOVQ	$runtime·mainPC(SB), AX		// entryPUSHQ	AXPUSHQ	$0			// arg sizeCALL	runtime·newproc(SB)POPQ	AXPOPQ	AX

此段代码中 runtime·newproc(SB) ,可看出一个go协程的创建是使用newproc函数实现的。

// Create a new g running fn with siz bytes of arguments.// Put it on the queue of g's waiting to run.// The compiler turns a go statement into a call to this.// Cannot split the stack because it assumes that the arguments// are available sequentially after &fn; they would not be// copied if a stack split occurred.//go:nosplitfunc newproc(siz int32, fn *funcval) {
    argp := add(unsafe.Pointer(&fn), sys.PtrSize)gp := getg()pc := getcallerpc()systemsta