浅谈我对协程的理解

简介: 我心中的协程 最近在研究网络服务框架方面的东西,发现了一个神奇的东西-协程。 一句话说明什么是线程:协程是一种用户态的轻量级线程。 一句话并不能完全概括协程的全部,但是起码能让我们对协程这个概念有一个基本的印象。 从硬件发展来看,从最初的单核单CPU,到单核多CPU,多核多CPU,似乎已经到了极限了,但是单核CPU性能却还在不断提升。server端也在不断的发展变

我心中的协程

最近在研究网络服务框架方面的东西,发现了一个神奇的东西-协程。
一句话说明什么是线程:协程是一种用户态的轻量级线程

一句话并不能完全概括协程的全部,但是起码能让我们对协程这个概念有一个基本的印象。
从硬件发展来看,从最初的单核单CPU,到单核多CPU,多核多CPU,似乎已经到了极限了,但是单核CPU性能却还在不断提升。server端也在不断的发展变化。如果将程序分为IO密集型应用和CPU密集型应用,二者的server的发展如下:
IO密集型应用: 多进程->多线程->事件驱动->协程
CPU密集型应用:多进程-->多线程

如果说多进程对于多CPU,多线程对应多核CPU,那么事件驱动和协程则是在充分挖掘不断提高性能的单核CPU的潜力。
以下的讨论如无特别说明,不考虑cpu密集型应用。

异步 vs 同步

无论是线程还是进程,使用的都是同步进制,当发生阻塞时,性能会大幅度降低,无法充分利用CPU潜力,浪费硬件投资,更重要造成软件模块的铁板化,紧耦合,无法切割,不利于日后扩展和变化。不管是进程还是线程,每次阻塞、切换都需要陷入系统调用(system call),先让CPU跑操作系统的调度程序,然后再由调度程序决定该跑哪一个进程(线程)。多个线程之间在一些访问互斥的代码时还需要加上锁,这也是导致多线程编程难的原因之一。

现下流行的异步server都是基于事件驱动的(如nginx)。事件驱动简化了编程模型,很好地解决了多线程难于编程,难于调试的问题。异步事件驱动模型中,把会导致阻塞的操作转化为一个异步操作,主线程负责发起这个异步操作,并处理这个异步操作的结果。由于所有阻塞的操作都转化为异步操作,理论上主线程的大部分时间都是在处理实际的计算任务,少了多线程的调度时间,所以这种模型的性能通常会比较好。

总的说来,当单核cpu性能提升,cpu不在成为性能瓶颈时,采用异步server能够简化编程模型,也能提高IO密集型应用的性能。

协程 vs 线程

之前说道,协程是一种用户级的轻量级线程。协程拥有自己的寄存器上下文和栈。协程调度切换时,将寄存器上下文和栈保存到其他地方,在切回来的时候,恢复先前保存的寄存器上下文和栈。因此:

协程能保留上一次调用时的状态(即所有局部状态的一个特定组合),每次过程重入时,就相当于进入上一次调用的状态,换种说法:进入上一次离开时所处逻辑流的位置。

在并发编程中,协程与线程类似,每个协程表示一个执行单元,有自己的本地数据,与其它协程共享全局数据和其它资源。目前主流语言基本上都选择了多线程作为并发设施,与线程相关的概念是抢占式多任务(Preemptive multitasking),而与协程相关的是协作式多任务

不管是进程还是线程,每次阻塞、切换都需要陷入系统调用(system call),先让CPU跑操作系统的调度程序,然后再由调度程序决定该跑哪一个进程(线程)。
而且由于抢占式调度执行顺序无法确定的特点,使用线程时需要非常小心地处理同步问题,而协程完全不存在这个问题(事件驱动和异步程序也有同样的优点)。

我们在自己在进程里面完成逻辑流调度,碰着i\o我就用非阻塞式的。那么我们即可以利用到异步优势,又可以避免反复系统调用,还有进程切换造成的开销,分分钟给你上几千个逻辑流不费力。这就是协程。

协程 vs 事件驱动

以nginx为代表的事件驱动的异步server正在横扫天下,那么事件驱动模型会是server端模型的终点吗?
我们可以深入了解下,事件驱动编程的模型。
事件驱动编程的架构是预先设计一个事件循环,这个事件循环程序不断地检查目前要处理的信息,根据要处理的信息运行一个触发函数。其中这个外部信息可能来自一个目录夹中的文件,可能来自键盘或鼠标的动作,或者是一个时间事件。这个触发函数,可以是系统默认的也可以是用户注册的回调函数。

事件驱动程序设计着重于弹性以及异步化上面。许多GUI框架(如windows的MFC,Android的GUI框架),Zookeeper的Watcher等都使用了事件驱动机制。未来还会有其他的基于事件驱动的作品出现。

基于事件驱动的编程是单线程思维,其特点是异步+回调。
协程也是单线程,但是它能让原来要使用异步+回调方式写的非人类代码,可以用看似同步的方式写出来。它是实现推拉互动的所谓非抢占式协作的关键。

总结

协程的好处:

  • 跨平台
  • 跨体系架构
  • 无需线程上下文切换的开销
  • 无需原子操作锁定及同步的开销
  • 方便切换控制流,简化编程模型
  • 高并发+高扩展性+低成本:一个CPU支持上万的协程都不是问题。所以很适合用于高并发处理。

缺点:

  • 无法利用多核资源:协程的本质是个单线程,它不能同时将 单个CPU 的多个核用上,协程需要和进程配合才能运行在多CPU上.当然我们日常所编写的绝大部分应用都没有这个必要,除非是cpu密集型应用。
  • 进行阻塞(Blocking)操作(如IO时)会阻塞掉整个程序:这一点和事件驱动一样,可以使用异步IO操作来解决
相关文章
|
网络协议 Unix Linux
有了协程库,开发DPDK应用程序第一次可以这么简单
使用PhotonLibOS协程库,以多执行单元并发的代码模型代替原先的异步回调模型,简化DPDK应用程序的开发。同时使用echo server验证了 用户态TCP/IP协议栈+轮询模式驱动 对比 内核原生协议栈+中断模式驱动 的性能优势
10192 0
有了协程库,开发DPDK应用程序第一次可以这么简单
|
存储 调度 块存储
十二年磨一剑:三代架构演进,打造高性能、低成本的块存储!
上周,全球计算机存储顶会USENIX FAST 2024 在美国加州圣克拉拉召开,继去年获得国内首个FAST最佳论文奖后,凭借在分布式块存储上的创新,阿里云新作再次斩获FAST大会最佳论文奖。这也是国内唯一一家连续两年获得FAST最佳论文奖的科技公司。
106576 105
|
数据采集 数据管理 大数据
5000字详解数据治理如何入门
5000字详解数据治理如何入门
423 1
5000字详解数据治理如何入门
|
存储 分布式计算 运维
大白话讲讲分布式存储系统的架构设计以及容错架构
分布式存储系统的架构设计旨在实现数据的分布式存储和负载均衡,通常采用数据分片和多节点存储的方式。容错架构则是为了提高系统的鲁棒性和可用性。在分布式存储系统中,容错架构常采用数据的冗余备份来应对节点故障或网络异常问题。通过复制数据到多个节点,即使某个节点发生故障,系统仍可以提供数据的可靠访问。此外,容错架构还包括故障检测和自动故障转移机制,用于及时检测节点故障,并将故障节点的任务转移给其他正常节点。这样可以保证系统在故障情况下仍能正常运行,并提供不间断的数据访问。通过合理的架构设计和有效的容错机制,分布式存储系统可以实现高可用性和数据可靠性,满足大规模数据存储和访问的需求。
1716 0
大白话讲讲分布式存储系统的架构设计以及容错架构
|
存储 缓存 算法
带你读《存储漫谈:Ceph原理与实践》——3.1.2 快照与克隆
带你读《存储漫谈:Ceph原理与实践》——3.1.2 快照与克隆
|
Java
java-线程等待/同步的五种方法
在面试时,经常会有面试官问道,一个主线程有多个子线程,如何能使子线程的业务执行完成之后,再执行主线程业务逻辑。对于这个问题,本人能够想到的有五种方法,详细请移步源码 1、使用线程类自带的join方法,将子线程加入到主线程,在子线程执行完之后,在执行主线程逻辑。
1739 0
|
弹性计算 云计算
阿里云认证公开课——ACP云计算重磅来袭
公开课名额:1000人(名额有限,报完即止)!!
阿里云认证公开课——ACP云计算重磅来袭
带你读《2022技术人的百宝黑皮书》——3D技术在数字藏品中的应用(5)
带你读《2022技术人的百宝黑皮书》——3D技术在数字藏品中的应用(5)
124 0
|
JSON JavaScript 前端开发
Node【包】
Node【包】
200 0
|
存储 缓存 NoSQL
漫谈 LevelDB 数据结构(一):跳表(Skip List)
漫谈 LevelDB 数据结构(一):跳表(Skip List)
448 0
漫谈 LevelDB 数据结构(一):跳表(Skip List)