论事件驱动与异步IO
看图说话讲事件驱动模型
在UI编程中，常常要对鼠标点击进行相应，首先如何检测到鼠标点击呢？
方式一：创建一个线程，该线程一直循环检测是否有鼠标点击，那么这个方式有以下几个缺点： 1. CPU资源浪费，可能鼠标点击的频率非常小，但是扫描线程还是会一直循环检测，这会造成很多的CPU资源浪费；如果扫描鼠标点击的接口是阻塞的呢？ 2. 如果是堵塞的，又会出现下面这样的问题，如果我们不但要扫描鼠标点击，还要扫描键盘是否按下，由于扫描鼠标时被堵塞了，那么可能永远不会去扫描键盘； 3. 如果一个循环需要扫描的设备非常多，这又会引来响应时间的问题； 所以，该方式是非常不好的。
方式二：就是事件驱动模型 目前大部分的UI编程都是事件驱动模型，如很多UI平台都会提供onClick()事件，这个事件就代表鼠标按下事件。事件驱动模型大体思路如下： 1. 有一个事件（消息）队列； 2. 鼠标按下时，往这个队列中增加一个点击事件（消息）； 3. 有个循环，不断从队列取出事件，根据不同的事件，调用不同的函数，如onClick()、onKeyDown()等； 4. 事件（消息）一般都各自保存各自的处理函数指针，这样，每个消息都有独立的处理函数；
我只管往里面扔任务就可以了。
注册一个事件的时候，还可以增加一个回调函数。可以自己定义回调函数，做完这个动作的下一步干什么。
事件驱动编程是一种编程范式，这里程序的执行流由外部事件来决定。它的特点是包含一个事件循环，当外部事件发生时使用回调机制来触发相应的处理。另外两种常见的编程范式是（单线程）同步以及多线程编程。
让我们用例子来比较和对比一下单线程、多线程以及事件驱动编程模型（三种常用的网络编程范式）。
A-单线程：完全线程执行三个任务，最耗时间。
B-多线程：同时起3个线程，但在每个线程里面，还是有自己的IO会被卡住。效率也是比较低。
C-协程：把所有的IO都挤掉了。（IO操作是由操作系统完成的。那么我怎么才能知道什么时候IO操作完成了呢。）
一出现IO操作，我就注册一个IO事件，然后交给操作系统，操作系统有一个队列，操作完了以后，返回结果，
并且通过回调函数通知你。
下图展示了随着时间的推移，这三种模式下程序所做的工作。这个程序有3个任务需要完成，每个任务都在等待I/O操作时阻塞自身。阻塞在I/O操作上所花费的时间已经用灰色框标示出来了。
IO操作实际上是由操作系统的IO接口完成的，告诉操作系统，你处理完了的时候，调用一下回调函数。这个回调函数就会通知我。
一出现IO操作，我就注册一个IO事件交给操作系统。操作系统里面有个队列，处理完了以后返回结果并且通过回调函数通知你。
2. IO多路复用
要访问的数据--------->内存里的内核空间---->内存里的用户空间。
二 IO模式
刚才说了，对于一次IO访问（以read举例），数据会先被拷贝到操作系统内核的缓冲区中，然后才会从操作系统内核的缓冲区拷贝到应用程序的地址空间。所以说，当一个read操作发生时，它会经历两个阶段： 1. 等待数据准备 (Waiting for the data to be ready) 2. 将数据从内核拷贝到进程中 (Copying the data from the kernel to the process)
正式因为这两个阶段，linux系统产生了下面五种网络模式的方案。 - 阻塞 I/O（blocking IO） - 非阻塞 I/O（nonblocking IO） - I/O 多路复用（ IO multiplexing） - 信号驱动 I/O（ signal driven IO） - 异步 I/O（asynchronous IO）
blocking I/O模式： 当没有数据返回的时候，就一直处于等待状态。
Nonblocking I/O 模式： 当没有数据返回的时候，就先通过。所以可以提高效率。