前提概要：
IO的过程：
整个IO的过程其实是应用发起IO的请求，到应用获取到IO请求数据的中间过程。
这个中间，其实主要的时间就是系统准备数据的过程。这也是异步技术的优化所在。
对系统调用的理解：
首先，我们要明确一点。IO的操作属于一种系统调用。也就是应用在运行中，进入到内核代码来执行某些重要的操作。
其实我们可以把系统调用看做是一个通信的过程。应用程序是A，操作系统是K。这就类似于一个C/S的模型。A向K发送请求信息。(系统调用)
K返回给A信息。(返回值)
会话结束。(我们认为，这样就是一个完整的通信过程)
当然，也可能会出现这样的通信过程。B发送给A信息。(比如回调)
会话结束。
一次IO请求，可能是一个通信过程，也可能需要多个通信过程。这就是各种IO的区别。
同步和异步：
同步：
由应用(A)向K发起请求，到A获取数据，期间一直是A作为会话的发起者。
异步：
和同步相反的自然就是异步。异步中，A获取数据这次会话，是由K发起的。
注意：这里有点困惑的是，K通知A时，可以直接把数据给它，也可以告诉A我准备好了，你来请求吧。感觉二者的区别应该就是IOCP和Epoll的区别。后者给人的感觉就是，异步中带有同步。网上的异步阻塞应该也就是这个。
区别：
可以看出，二者的区别就是在于最终获取到数据这个会话，是哪边发起的。对于应用而言，主动就是同步，被动就是异步。(这个有点像CPU的同步/异步中断)
阻塞和非阻塞：
它们的区别主要在于IO请求发起，直到获得数据，这段时间，应用是等着还是不等着。
阻塞：
阻塞，就是应用等待着，不干活。
其实对于操作系统而言，阻塞不是什么坏事，不然要我操作系统干嘛。操作系统功能之一就是系统资源的调度，当某个进程(线程)阻塞了，它就能调度CPU资源给别的进程。这其实能提高不少利用率。
非阻塞：
看网上不少人说，这看上去是个差一点的方案。它是让应用不断的轮询，直到拿到数据。它相比于阻塞，会浪费一些CPU，自然性能也就会差一些了。
总结：
各种IO设计不同，但目的是一样的。都是为了让应用程序跑的更快，系统资源利用的更充分。
异步对于同步的优化点：
我一直觉得异步多进程和同步的性能并没有什么差异。因为我们的优化点是在发起IO请求到获得请求数据之间的这段时间。这段时间如果等着，那就浪费了。同步程序中(阻塞模式)，多进程的情况下，操作系统的调度让阻塞的程序停止，把CPU给另一个需要CPU的进程，比如计算，处理。
异步程序的话，程序自身就不阻塞，像一个工厂流水线一样，只要上面工件下来，干完扔给下一步就行。(有可能回到上一步，也就是回调)
看上去，二者用了不同的方法优化了那段时间。其实把同步的程序从操作系统调度的层面来看，它也是异步的，对于操作系统而言，进程就是一个task_struct嘛，现在的CPU和IO设备其实就是异步的。
所以，准确的说，是应用程序的同步还是异步。二者的区别在于代价，也就是管理的灵活和切换的性能损耗。因为在同步程序中，第一步完成后，需要切换任务。而异步程序就不需要了，它继续干它自己的活。那么切换的代价就小了。
有人说，协程让用户使用同步的方式写出异步的性能。主要也是因为协程的切换代价小。再看IOCP的设计，为了最有效的利用操作系统，它使用了线程池，其目的也就是让线程能保持一个合理的数量。
该阻塞还是非阻塞：
阻塞其实就是把调度的权力给了操作系统，让操作系统来提高利系统用率。非阻塞则是把这个权力给了开发者，因为不阻塞的话我们可以做些别的事情，类似于程序内部的一个调度功能。
协程就是在系统调用时，内部跳转到别的协程代码去执行。类似于是自己实现了一个轻量级的调度。
