关于linux:协程究竟比线程能省多少开销

6次阅读

共计 2308 个字符，预计需要花费 6 分钟才能阅读完成。

前文中中咱们用试验的形式验证了 Linux 过程和线程的上下文切换开销，大概是 3 -5us 之间。当运行在个别的计算机程序时，这个开销的确不算大。然而海量互联网服务端和个别的计算机程序相比，特点是：

高并发：每秒钟须要解决成千上万的用户申请
周期短：每个用户解决耗时越短越好，常常是 ms 级别的
高网络 IO：常常须要从其它机器上进行网络 IO、如 Redis、Mysql 等等
低计算：个别 CPU 密集型的计算操作并不多

即便 3 -5us 的开销，如果上下文切换量特地大的话，也依然会显得是有那么一些性能低下。例如之前的 Web Server 之 Apache，就是这种模型下的软件产品。（其实过后 Linux 操作系统在设计的时候，指标是一个通用的操作系统，并不是专门针对服务端高并发来设计的）

为了防止频繁的上下文切换，还有一种异步非阻塞的开发模型。那就是用一个过程或线程去接管一大堆用户的申请，而后通过 IO 多路复用的形式来进步性能（过程或线程不阻塞，省去了上下文切换的开销）。Nginx 和 Node Js 就是这种模型的典型代表产品。平心而论，从程序运行效率上来，这种模型最为机器敌对，运行效率是最高的（比上面提到的协程开发模型要好）。所以 Nginx 曾经取代了 Apache 成为了 Web Server 里的首选。然而这种编程模型的问题在于开发不敌对，说白了就是过于机器化，离过程概念被形象进去的初衷南辕北辙。人类失常的线性思维被打乱，应用层开发们被逼得以非人类的思维去编写代码，代码调试也变得异样艰难。

于是就有一些聪慧的脑袋们持续在应用层又动起了主见，设计出了不须要过程 / 线程上下文切换的“线程”，协程。用协程去解决高并发的利用场景，既可能合乎过程波及的初衷，让开发者们用人类失常的线性的思维去解决本人的业务，也同样可能省去低廉的过程 / 线程上下文切换的开销。因而能够说，协程就是 Linux 解决海量申请利用场景里的过程模型的一个很好的的补丁。

背景介绍完了，那么我想说的是，毕竟协程的封装尽管轻量，然而毕竟还是须要引入了一些额定的代价的。那么咱们来看看这些额定的代价具体多小吧。

测试代码如下，测试过程是一直在协程之间让出 CPU。外围代码如下：

func cal()  {
    for i :=0 ; i<1000000 ;i++{runtime.Gosched()
    }
}

func main() {runtime.GOMAXPROCS(1)

    currentTime:=time.Now()
    fmt.Println(currentTime)

    go cal()  
    for i :=0 ; i<1000000 ;i++{runtime.Gosched()
    }

    currentTime=time.Now()
    fmt.Println(currentTime)
}

好了，让咱们编译运行一下：

# cd tests/test05/src/main/;  
# go build  
# ./main  
2019-08-08 22:35:13.415197171 +0800 CST m=+0.000286059
2019-08-08 22:35:13.655035993 +0800 CST m=+0.240124923

均匀每次协程切换的开销是（655035993-415197171)/2000000=120ns。绝对于后面文章测得的过程切换开销大概 3.5us，大概是其的三十分之一。比零碎调用的造成的开销还要低。

在空间上，协程初始化创立的时候为其调配的栈有 2KB。而线程栈要比这个数字大的多，能够通过 ulimit 命令查看，个别都在几兆，作者的机器上是 10M。如果对每个用户创立一个协程去解决，100 万并发用户申请只须要 2G 内存就够了，而如果用线程模型则须要 10T。

# ulimit -a  
stack size              (kbytes, -s) 10240

协程因为是在用户态来实现上下文切换的，所以切换耗时只有区区 100ns 多一些，比过程切换要高 30 倍。单个协程须要的栈内存也足够小，只须要 2KB。所以，近几年来协程大火，在互联网后端的高并发场景里大放荣耀。

无论是空间还是工夫性能都比过程（线程）好这么多，那么 Linus 为啥不把它在操作系统里实现了多好？

实际上协程并不是一个新玩意，在上个世纪 60 年代的时候就曾经有人提出了。操作系统的一个次要设计指标是实时性，对优先级比拟高的过程是会抢占以后占用 CPU 的过程。然而协程无奈实现这一点，还得依赖于应用 CPU 的一方被动开释，与操作系统的实现目标不相吻合。协程的高效是以就义了可抢占性为代价的。

扩大：因为 go 的协程调用起来太不便了，所以一些 go 的程序员就很随便地 go 来 go 去。要晓得 go 这条指令在切换到协程之前，得先把协程创立进去。而一次创立加上调度开销就涨到 400ns，差不多相当于一次零碎调用的耗时了。尽管协程很高效，然而也不要乱用，否则 go 祖师爷 Rob Pike 花大精力优化进去的性能，被你随便一 go 又给葬送掉了。

开发内功修炼之 CPU 篇专辑：