计算机基础

title: 计算机基础
date: 2018-03-18 23:20:16

进程与线程

进程和线程都是一个时间段的描述，是CPU工作时间段的描述

一个最最基础的事实：CPU太快，太快，太快了，寄存器仅仅能够追的上他的脚步，RAM和别的挂在各总线上的设备完全是望其项背。那当多个任务要执行的时候怎么办呢？轮流着来?或者谁优先级高谁来？不管怎么样的策略，一句话就是在CPU看来就是轮流着来。
一个必须知道的事实：执行一段程序代码，实现一个功能的过程介绍，当得到CPU的时候，相关的资源必须也已经就位，就是显卡啊，GPS啊什么的必须就位，然后CPU开始执行。这里除了CPU以外所有的就构成了这个程序的执行环境，也就是我们所定义的程序上下文。当这个程序执行完了，或者分配给他的CPU执行时间用完了，那它就要被切换出去，等待下一次CPU的临幸。在被切换出去的最后一步工作就是保存程序上下文，因为这个是下次他被CPU临幸的运行环境，必须保存。
串联起来的事实：前面讲过在CPU看来所有的任务都是一个一个的轮流执行的，具体的轮流方法就是：先加载程序A的上下文，然后开始执行A，保存程序A的上下文，调入下一个要执行的程序B的程序上下文，然后开始执行B,保存程序B的上下文。。。

进程就是包换上下文切换的程序执行时间总和 = CPU加载上下文+CPU执行+CPU保存上下文
进程的颗粒度太大，每次都要有上下的调入，保存，调出。如果我们把进程比喻为一个运行在电脑上的软件，那么一个软件的执行不可能是一条逻辑执行的，必定有多个分支和多个程序段，就好比要实现程序A，实际分成 a，b，c等多个块组合而成。那么这里具体的执行就可能变成：

程序A得到CPU => CPU加载上下文，开始执行程序A的a小段，然后执行A的b小段，然后再执行A的c小段，最后CPU保存A的上下文。

这里a，b，c的执行是共享了A的上下文，CPU在执行的时候没有进行上下文切换的。这里的a，b，c就是线程，也就是说线程是共享了进程的上下文环境，的更为细小的CPU时间段。

开个QQ，开了一个进程；开了迅雷，开了一个进程。
在QQ的这个进程里，传输文字开一个线程、传输语音开了一个线程、弹出对话框又开了一个线程。
所以运行某个软件，相当于开了一个进程。在这个软件运行的过程里（在这个进程里），多个工作支撑的完成QQ的运行，那么这“多个工作”分别有一个线程。
所以一个进程管着多个线程。
通俗的讲：“进程是爹妈，管着众多的线程儿子”…

一个进程可以包括多个线程
每个线程可以使用进程的共享内存（互斥锁）

操作系统的设计，因此可以归结为三点：

以多进程形式，允许多个任务同时运行；
以多线程形式，允许单个任务分成不同的部分运行；
提供协调机制，一方面防止进程之间和线程之间产生冲突，另一方面允许进程之间和线程之间共享资源。

异步，非阻塞和 IO 复用

https://segmentfault.com/a/1190000007614502

同步与异步

同步与异步的重点在消息通知的方式上，也就是调用结果通知的方式。

同步: 当一个同步调用发出去后，调用者要一直等待调用结果的通知后，才能进行后续的执行。
异步：当一个异步调用发出去后，调用者不能立即得到调用结果的返回。
异步调用，要想获得结果，一般有两种方式

主动轮询异步调用的结果;

被调用方通过callback来通知调用方调用结果。

demo：
同步买奶茶：小明点单交钱，然后等着拿奶茶；异步买奶茶：小明点单交钱，店员给小明一个小票，等小明奶茶做好了，再来取。

异步买奶茶: 小明要想知道奶茶是否做好了，有两种方式：

小明主动去问店员，一会就去问一下：“奶茶做好了吗？”…直到奶茶做好。这叫轮训。

等奶茶做好了，店员喊一声：“小明，奶茶好了！”，然后小明去取奶茶。这叫回调。

阻塞与非阻塞

阻塞与非阻塞的重点在于进/线程等待消息时候的行为，也就是在等待消息的时候，当前进/线程是挂起状态，还是非挂起状态。

阻塞调用在发出去后，在消息返回之前，当前进/线程会被挂起，直到有消息返回，当前进/线程才会被激活.
非阻塞调用在发出去后，不会阻塞当前进/线程，而会立即返回。

demo：
阻塞买奶茶：小明点单交钱，干等着拿奶茶，什么事都不做；
非阻塞买奶茶：小明点单交钱，等着拿奶茶，等的过程中，时不时刷刷微博、朋友圈。

总结：

同步与异步，重点在于消息通知的方式;
阻塞与非阻塞，重点在于等消息时候的行为。

demo

同步阻塞：小明在柜台干等着拿奶茶；
同步非阻塞：小明在柜台边刷微博边等着拿奶茶；
异步阻塞：小明拿着小票啥都不干，一直等着店员通知他拿奶茶；
异步非阻塞：小明拿着小票，刷着微博，等着店员通知他拿奶茶。

IO复用

在一个进程处理所有的并发I/O呢?
答案是有的，这就是I/O复用技术。

最初级的I/O复用

所谓的I/O复用，就是多个I/O可以复用一个进程。
当一个连接过来时，我们不阻塞住，这样一个进程可以同时处理多个连接了。
比如一个进程接受了10000个连接，这个进程每次从头到尾的问一遍这10000个连接：“有I/O事件没？有的话就交给我处理，没有的话我一会再来问一遍。”
然后进程就一直从头到尾问这10000个连接，如果这1000个连接都没有I/O事件，就会造成CPU的空转，并且效率也很低

升级版的I/O复用

上面虽然实现了基础版的I/O复用，但是效率太低了。于是伟大的程序猿们日思夜想的去解决这个问题…终于！
我们能不能引入一个代理，这个代理可以同时观察许多I/O流事件呢？
当没有I/O事件的时候，这个进程处于阻塞状态；当有I/O事件的时候，这个代理就去通知进程醒来？
于是，早期的程序猿们发明了两个代理—select、poll。
select、poll代理的原理是这样的：

当连接有I/O流事件产生的时候，就会去唤醒进程去处理。

但是进程并不知道是哪个连接产生的I/O流事件，于是进程就挨个去问：“请问是你有事要处理吗？”……问了99999遍，哦，原来是第100000个进程有事要处理。那么，前面这99999次就白问了，白白浪费宝贵的CPU时间片了

注:select与poll原理是一样的，只不过select只能观察1024个连接，poll可以观察无限个连接。

上面看了，select、poll因为不知道哪个连接有I/O流事件要处理，性能也挺不好的。

那么，如果发明一个代理，每次能够知道哪个连接有了I/O流事件，不就可以避免无意义的空转了吗？

于是，超级无敌、闪闪发光的epoll被伟大的程序员发明出来了。

epoll代理的原理是这样的：

当连接有I/O流事件产生的时候，epoll就会去告诉进程哪个连接有I/O流事件产生，然后进程就去处理这个进程。

如此，多高效！