猪皮课堂 - czp 讲协程

猪皮课堂 - czp 讲协程

czp 带你精通 进程,线程,多线程,回调,协程

czp,脆猪皮老哥太低调了不发文章。来每隔几个月温习一遍,那,你已经精通了。

在冯诺伊曼计算机架构中:指令内存和数据内存在同一块主存储器中的,也就是说,程序的代码(机器码)和保存的变量,是在同一块内存条里面的,所以 CPU 的工作就非常简单了。

开机的时候要做的事情非常简单,那就是把程序写入到 0x00 这个地址,然后把 CPU 中的 program counter 写为 0,CPU 就会开始读取 0x00 这个地址上的指令,执行完之后,program counter 会自增,然后开始读取 0x01,你的 CPU 就开始运作了,但是顺序执行是不够的,所以就发明了 jump,这一条特殊的指令可以写入 prgram counter,使 CPU 执行另一个地方的指令,然后从另一个地方开始继续自增下去,由于数据和代码都在一个内存条上,内存地址是唯一的,所以非常方便的实现了各种读取、写入问题。

有些代码经常被执行,为了避免重复编码,发明了函数,实际上函数就是先 jump 到指定位置,再 jump 回来,这叫一次 call(等会再讲),于是现代计算机的理论体系就这样被构建出来,看上去天衣无缝,非常完美,直到有一天,人们在想:

假如我有一个按钮,无论当前程序运行到何处,只要我按下这个按钮,就希望程序特别的执行一个操作,怎么办?

方案一是让 CPU 不断的去查询这个按钮有没有被按下(这叫轮询,这种等待方式叫做:自旋锁,自旋锁就导致 CPU 一直被占用,也就是一直查询按钮有没有被按下,等同于以下伪代码,实际上 CPU 在一个死循环里,CPU 占用率持续 100%)这在单片机上可能没什么问题,但是随着程序越来越复杂,这种死循环会影响程序的正常流程,在轮询按钮被按下的时候,就无法干别的事情了。

于是发明了中断,中断是一种硬件实现,他可以让一个硬件被激活时被改变 program counter 的值,这种中断改变了程序的流程。在 Unix 中,系统将许多信号封装为中断,这种中断是软件实现的,程序收到 Ctrl+C 之后,会执行自己的函数,而不是关闭。这是通过注册对各种信号的中断函数实现的,中断可以改变程序原有的流程,因此有了一种想法:可不可以在这个时刻,执行程序 a,然后中断,执行程序 b。

对于 CPU 来说,不存在操作系统和应用程序的概念,这些只是代码而已,而中断只是简单的修改了 program counter 的值,系统上运行的程序 a、b 对 CPU 来说没有区别,这个想法是可以实现的。

历史的车轮滚滚滚向前(我倒.. ),直到有一天,丹尼斯从床上起来,他有了一个惊人的想法:能不能在一台电脑上,和基友一起玩游戏,就是那种:你用 wasd,我用上下左右的游戏。这也就意味着:系统必须同时处理控制 2 个程序,很快,沉迷于电子游戏的丹尼斯将这个想法实现了:它就是 Unix,人类历史上第一个真正多任务多用户操作系统,在这个操作系统上,系统让 CPU 来回执行各个进程,从而看起来像在同时执行多个程序。例如:0-0.01s 执行程序 a,0.01-0.05s 执行程序 b

那一天,人类的历史迎来了新的一页,丹尼斯将 Unix 时间戳设计为 1970 年 1 月 1 日 8:00 为原点,所以古人云,1970 年 1 月 1 日,上帝创世。

这种来回执行不同程序的方案,叫做:分时,这种操作系统,就叫做 分时操作系统。很快的,人们发现,虽然分时可以执行多个程序,但是多个程序之间共享数据非常麻烦,于是就想着,能不能在一个进程里面,有好几个同时执行的单元。于是有了线程的概念。

一个进程,它里面会有好几个线程,所有的线程共享同样的数据内存,这样线程 a 修改了变量 var1,线程 b 就可以取得修改后的值(这里有个线程安全的问题,后面讲),也就是说:在现代操作系统中,代码执行的逻辑是线程,每个线程都是被独立执行的,概念上我们认为他们是同时执行的。

如果一个程序只有 main 函数,那么他就只能有一个 Main Thread,程序必须至少要有一个线程,才能是活动的,否则就是僵尸进程(僵尸进程要涉及到程序的父子关系,后面讲),而这个线程,是操作系统控制的,操作系统会根据一个算法,来为所有线程分配时间片,这看起来天衣无缝,非常完美。直到有一天:互联网被发明了。

很快的,就出现了一件事,对于网络的操作,是非常慢的,在未完成之前,程序会一直卡在对网络的操作上,比如说:访问了 bilibili.com 在这个访问没有返回钱,程序就会一直卡在那一行,例如代码时这样的 val response = GET ("bilibili.com") 假如网络奇慢无比,这个访问 30s 后才返回,那么这个程序就会一直卡在这一行 30s,假如这个操作发生在一个 UI 上的按钮按下时,那么这个按钮一按下,程序就卡住了,程序变得未响应,并且按钮也弹不回来,这种东西,我们叫它:阻塞,所有的 IO 操作,都有可能产生阻塞,Java 为此特别搞了一个异常,叫做 IOException。

为了解决这个阻塞,人们想到了用 多线程 来解决,简单的说:就是让阻塞发生在其他线程,而非主线程。主线程的工作应该都是不阻塞的,所以我们现在的工作流变为了:我们按下按钮,程序创建了一个新线程,去访问 bilibili,然后主线程创建完线程本身,工作就结束了,主线程将被按钮弹回,可以继续响应下一次用户操作。

在这个工作流里面,就遇到了另一个问题,主线程如何知道刚才开启的那个线程已经完成了工作?如果主线程不停的查询这个线程是否完成了工作,就又变成先前的轮询问题了,主线程自己会因为这个而阻塞。

所以就引入了一个概念:回调函数,我们只要先之前开启的那个线程传入一个函数指针,当他完成工作后,自己去执行这个函数,我们的主线程就不需要知道它什么时候完成工作了,用 js 举例: fetch ("bilibili.com").then (response=>{}),这个 then(*) 就是回调函数,里面的内容会在那个 fetch 结束工作之后被执行(js 不是多线程的,后面说)比如说里面的内容是把 bilibili 返回的内容显示在主窗体上,那么我们就实现了一个简单的浏览器。

通过:多线程、回调函数,我们似乎已经可以处理一切问题,看起来完美无缺,但是很快,随着互联网的继续发展,人们遇到了更大的问题:假如一万个用户同时访问了这个网站,那么网站服务器上那个程序,就会开启一万个线程来应对这所有的链接。

我们都知道,线程是分时操作系统分配时间片的最小单元。简单来说,分时操作本身就是一个 system call,它需要进入内核代码在内核态中完成,是一种开销相对较大的操作,并且不同的线程有自己的上下文,也会导致很大的内存开销,例如开一千个线程,就可能要消耗 100MB 内存,换句话说,为每个前来链接的用户开一个线程是不切实际的,那,服务器性能再强也会顶不住的。

我们观察到,在这个用例,实际上如果我们真的为每个用户开一个线程,每个线程大多数时间都是在阻塞,只有很少一部分时间实在传输数据,而有一些其他的场景更为夸张,例如:聊天服务器,每个用户 99.999% 的时间都是在打字,传输那一点点文本的时间消耗可以忽略不计了:

我们开出来的线程全部都在阻塞,都没在干活,所以我们想到一个惊人的操作:我们只用一个线程,用这个线程去轮询有没有 socket 里面出现数据,如果有则处理,如果没有就轮询;

虽然我们的 socket 很多,但是同时也只有几个 socket 里面有数据,比如说聊天服务器可能有一万个用户在连接,我们有一万个 socket,同时最多只有十个用户在发消息。而消息的处理非常简单,只要发给他所在的其他群员即可,数据处理及户不耗时,那么我们只用一个线程,不停的监听是否有数据出现,我们就可以几乎不延迟的处理这一万个 socket,由此节约大量的服务器资源。

在现代操作系统中,socket 事件被封装(连接成功、出现数据、连接断开,这些都是事件),程序可以简单的获取这些事件,然后处理对应的 socket,之后继续监听事件出现,这种出现事件,程序就动一动的模式,叫做事件驱动(event driven),与轮询对立,有了事件驱动,事情突然变得非常完美,似乎这个世界上一切的问题都可以用事件驱动来解决。

但是很快,出现了另外一个问题(我倒..):

事件驱动实际上是为每个事件定义了一个回调函数,比如 socket 出现数据,就执行这个函数,socket 断开就执行那个函数,如果这个回调函数里面,要执行另一个异步操作,而另一个异步操作也有它自己的回调函数,那么就会出现嵌套的回调函数:fetch (x).then (response=>{fetch (response.y).then...})

很快的,这个代码变得没法写了,因为太乱了,这个问题,叫做:callback hell,大多数语言都会出现这个问题。这是由于设计模式导致的。

为了解决这个问题,另外一个思路被提出,叫做:协程(coroutines),coroutines 实际上也是一个:事件 - 回调模式,但是他可以让用户看起来同步的方式写异步,举个例子:

launch {
val response=Get(..).await
val var1=Get(response.y).await
}

launch 表示以下是一个无返回值的协程语句块,协程的核心是一个 Coroutines Dispatcher(协助调度器),在程序编译时,编译时注解处理器会检查所有协程代码中存在阻塞的地方。

检查阻塞非常简单,Java 中所有会发生阻塞的地方,都会抛出 InterruptedException,这个异常本来是用来中断一个线程用的,如果你看过 jdk 源码,你会发现,Tread.destroy () 这个方法是被移除的,现在在他里面本体是直接抛出一个 unsupportrdException,这个方法是假的,是不能用的,这个方法是历史上 Java 的线程设计错误遗留下来的,在当时,线程可以直接被 thread.destroy ()

但是很快的,一个事情被暴露出来:假设这个线程手动申请了某个锁(有一个类,叫做 Lock,可以手动申请锁,而不受到程序语法块的限制)那么这个线程一旦被销毁,就再也没有人去释放锁了,这回导致程序运行不正常,所以线程是不能被直接销毁的,线程必须自己被关掉,也就是线程里面的代码运行结束,所以设计了 InterruptedException.

前面我们讲到,在传统设计中,线程大部分时间都在阻塞,此时线程本身处于卡死的状态,代码一直停留在这一行,如果其他线程执行了 thread.interrupt(),那么这个线程会被中断,在这一行立即抛出异常,这个异常叫做 InterruptException,所有的阻塞都有这个异常,此时的代码会进入 catch 体,线程就知道:

我被中断了,catch 里面就可以进行释放锁的操作然后 return,结束自己,因此只需要检查一个地方是否有 InterruptedException,就可以知道这里会不会阻塞。

协程在编译的时候,会检查所有阻塞的地方,然后一旦运行到阻塞的地方代码将跳回协程调度器,协程调度器会执行其他协程,一旦一个阻塞结束了,也就是返回了,那么阻塞代码下面的代码,就会成为他的回调函数;如果下面的代码继续阻塞,这个组的回调里面的阻塞的下面的代码,就会成为他的回调,协程调度器实现了这一切,用户的源码,看起来是同步的,没有回调,其实在运行的时候,他们都变成了回调,简单的说就是语法糖,使得代码整洁干净,程序员不需要考虑什么回调回来之后又回调这种事情,消除了 callbak hell,协程调度器他本身是在不停执行各种协程的过程中,他自己是单线程的,所以协程并不是用来执行计算密集型任务用的,而是用来处理,大多数时间消耗在阻塞上的任务,如果一个东西是计算密集型的,那么不可避免的要使用多线程,因为一个 CPU 核心只能执行一个线程,这就是所谓的:多核心优化

而 kotlin协程 则提供了可嵌套式的线程跳转能力,用户可以简单的在多个线程执行各种协程,而代码依旧整洁如初,详见谷歌搜索 kotlin corountines.

czp: 那,你已经精通协程了

No rights reserved
Except where otherwise noted, content on this page is not copyrighted and is free to use.