异步的概念和同步相对。
（1）当一个同步调用发出后，调用者要一直等待返回消息（结果）通知后，才能进行后续的执行；
（2）当一个异步过程调用发出后，调用者不能立刻得到返回消息（结果）。实际处理这个调用的部件在完成后，通过状态、通知和回调来通知调用者。
这里提到执行部件和调用者通过三种途径返回结果：状态、通知和回调。使用哪一种通知机制，依赖于执行部件的实现，除非执行部件提供多种选择，否则不受调用者控制。
如果执行部件用状态来通知，那么调用者就需要每隔一定时间检查一次，效率就很低（有些初学多线程编程的人，总喜欢用一个循环去检查某个变量的值，这其实是一种很严重的错误）；
如果是使用通知的方式，效率则很高，因为执行部件几乎不需要做额外的操作。至于回调函数，其实和通知没太多区别。
（A）阻塞调用是指调用结果返回之前，当前线程会被挂起，一直处于等待消息通知，不能够执行其他业务
(B)非阻塞调用是指在不能立刻得到结果之前，该函数不会阻塞当前线程，而会立刻返回
场景比喻：
举个例子，比如我去银行办理业务，可能会有两种方式：
选择排队等候；
另种选择取一个小纸条上面有我的号码，等到排到我这一号时由柜台的人通知我轮到我去办理业务了；
在上面的场景中，如果：
a)如果选择排队(同步)，且排队的时候什么都不干(线程被挂起，什么都干不了)，是同步阻塞模型；
b)如果选择排队(同步)，但是排队的同时做与办银行业务无关的事情，比如抽烟，（线程没有被挂起，还可以干一些其他的事），是同步非阻塞模型；
c）如果选择拿个小票，做在位置上等着叫号（通知），但是坐在位置上什么都不干（线程被挂起，什么都干不了），这是异步阻塞模型；
d）如果选择那个小票，坐在位置上等着叫号(通知)，但是坐着的同时还打电话谈生意(线程没有被挂起，还可以干其他事情)，这是异步非阻塞模型。
对这四种模型做一个总结：
1：同步阻塞模型，效率最低，即你专心排队，什么都不干。
2：异步阻塞，效率也非常低，即你拿着号等着被叫（通知），但是坐那什么都不干
3：同步非阻塞，效率其实也不高，因为涉及到线程的来回切换。即你在排队的同时打电话或者抽烟，但是你必须时不时得在队伍中挪动。程序需要在排队和打电话这两种动作之间来回切换，系统开销可想而知。
4：异步非阻塞，效率很高，你拿着小票在那坐着等叫号(通知)的同时，打电话谈你的生意。
linux下几个基本概念
1：用户控件和内核空间。现代操作系统都是采用虚拟存储器，在32位操作系统下，它的寻址空间(虚拟存储空间)为4G(2的32次方)。为了保证用户进程补鞥呢直接操作内核，保证内核的安全，操作系统将虚拟空间划分为两部分，一部分为内核空间，一部分为用户空间。对linux操作系统而言，将最高的1G字节空间分给了内核使用，称为内核空间，将较低的3G字节的空间划分为用户空间。
2：进程切换很耗资源，为了控制进程的执行，内核必须有能力挂起正在cpu上运行的进程，并恢复以前挂起的某个进程的执行，这种行为叫进程的切换。每次切换，要保存上一个的上下文环境等等，总之记住进程切换很耗资源。
3：文件描述符：文件描述符在形式上是一个非负整数。实际上，他是一个索引，指向内核为每个进程所维护的该进程打开文件的记录表。当程序打开一个文件时，内核就会向进程返回一个非负整数的文件描述符。但是文件描述符一般在unix，linux系统中才讲。
缓存IO，大多数系统的默认IO操作都是缓存IO,在linux的缓存IO机制中，操作系统会将IO的数据缓存在系统的页缓存(page cache)中，也就是说，数据会先被拷贝到操作系统内核的缓冲区，然后才会从操作系统内核的缓冲区拷贝到应用程序的地址空间。缓存IO的缺点：数据在传输过程中需要在应用程序和地址空间和内核进行多次数据拷贝操作，这种数据拷贝操作锁带来的cpu以及内存消耗是很大的。
LINUX的IO模型
网络IO的本质是socket的读取。socket在linux系统被抽象为流，故对网络IO的操作可以理解为对流的操作。
对于一次IO访问，比如以read操作为例，数据会先被拷贝到操作系统内核的缓冲区，然后才会从内核缓冲区拷贝到进程的用户层，即应用程序的地址空间。故当一个read操作发生时，其实是经历了两个阶段：
1：内核缓冲区的数据就位
2：数据从内核缓冲区拷贝到用户程序地址空间
那么具体到socket io的一次read操来说，这两步分别是：
1：等待网络上的数据分组到达，然后复制到内核缓冲区中
2：数据从内核缓冲区拷贝到用户程序的地址空间(缓冲区)
所以说网络应用要处理的无非就两个问题：网络IO和数据计算，一般来说网络io带来的延迟影响比较大。
网络IO的模型大致有如下几种：
同步模型（synchronous IO）
阻塞IO（bloking IO）
非阻塞IO（non-blocking IO）
多路复用IO（multiplexing IO）
信号驱动式IO（signal-driven IO）
异步IO（asynchronous IO）
熟悉不？我们常说的select，poll和epoll就是属于同步模型中多路复用IO的不同实现方法罢了。下面分别对同步阻塞，同步不阻塞，同步io复用进行说明。
一：同步阻塞
它是最简单也最常用的网络IO模型。linux下默认的socket都是blocking的。
从图中可以看到，用户进程调用recvfrom这个系统调用后，就处于阻塞状态。然后kernel就开始了IO的第一个阶段：数据准备。等第一个阶段准备完成之后，kernel开始第二阶段，将数据从内核缓冲区拷贝到用户程序缓冲区（需要花费一定时间）。然后kernel返回结果（确切的说是recvfrom这个系统调用函数返回结果），用户进程才结束blocking，重新运行起来。
总结：同步阻塞模型下，用户程序在kernel执行io的两个阶段都被blocking住了。但是优点也是因为这个，无延迟能及时返回数据，且程序模型简单。
二：同步非阻塞
同步非阻塞就是隔一会瞄一下的轮询方式。同步非阻塞模式其实是可以看做一小段一小段的同步阻塞模式。
如图所示，用户进程在read过程中，同样也是先发起recvfrom这个系统调用，不同的是，如果io第一阶段还没准备好，也即内核缓冲区中的数据还没到位的话，recvfrom不会等待数据到位，而是直接给用户程序返回一个error，用户程序收到error后就知道kernel的数据没到位，用户程序可以先去干点别的事，等过了一会再发起recvfrom调用来看看kernel的数据有没有到位。经过一次次的轮询。。。终于当内核中的数据准备就绪且又收到了用户程序发起的recvfrom调用后，kernel会将kernel缓冲区中的数据拷贝到用户程序地址空间。但是请注意：在第二阶段将数据从kernel缓冲区拷贝到用户程序空间的这段时间内，用户程序是阻塞的。
总结：
优点：能够在等待任务完成的时间里干其他活了（包括提交其他任务，也就是 “后台” 可以有多个任务在同时执行）。
缺点：任务完成的响应延迟增大了，因为每过一段时间才去轮询一次read操作，而任务可能在两次轮询之间的任意时间完成。这会导致整体数据吞吐量的降低。
三：IO多路复用
由于同步非阻塞方式需要不断的轮询，光轮询就占据了很大一部分过程，且消耗cpu资源。而这个用户进程可能不止对这个socket的read，可能还有对其他socket的read或者write操作，那人们就想到了一次轮询的时候，不光只查询询一个socket fd，而是在一次轮询下，查询多个任务的socket fd的完成状态，只要有任何一个任务完成，就去处理它。而且，轮询人不是进程的用户态，而是有人帮忙就好了。那么这就是所谓的IO多路复用。总所周知的linux下的select，poll和epoll就是这么干的。。。
selelct调用是内核级别的，selelct轮询相比较同步非阻塞模式下的轮询的区别为：前者可以等待多个socket，能实现同时对多个IO端口的监听，当其中任何一个socket数据准备好了，就返回可读。select或poll调用之后，会阻塞进程，与blocking IO 阻塞不用在于，此时的select不是等到所有socket数据达到再处理，而是某个socket数据就会返回给用户进程来处理。
其实select这种相比较同步non-blocking的效果在单个任务的情况下可能还更差一些，因为这里调用了select和recvfrom两个system call，而non-blocking只调用了一个recvfrom，但是用select的优势在于它可以同时处理多个socket fd。
在io复用模型下，对于每一个socket，一般都设置成non-blocking，但是其实整个用户进程是一直被block的，只不过用户process不是被socket IO给block住，而是被select这个函数block住的。
与多进程多线程技术相比，IO多路复用的最大优势是系统开销小。
一：select
select函数监视多个socket fs，直到有描述符就绪或者超时，函数返回。当select函数返回后，可以通过遍历fdset，来找到就绪的描述符。select的基本流程为：
select的特点：
1：最大缺陷是单个进程锁打开的fd是有限制的，32位机器上是1024个，64位机器上是2048个，虽然可以改这个数值，但是会造成性能下降。
2：对socket进行扫描时是线性扫描，当套接字比较多时，不管哪个socket是活跃的，都要遍历一遍fdset，很耗时耗cpu（如果能给套接字注册某个回调函数，当本套接字活跃时，自动完成相关操作，就不用轮询，实际上epoll就是改了这儿）
3：需要维护一个用来存放大量fd的数据结构，且在kernel缓冲区和用户缓冲区之间拷贝这个结构的开销很大。
二：poll
poll本质上跟select没有区别，它将用户传入的数组拷贝到内核空间，然后查询每个fd的状态，如果某个fd的状态为就绪，则将此fd加入到等待队列中并继续遍历。如果遍历完所有的fd后发现没有就绪的，则挂起当前进程，直到设备就绪或者主动超时。被唤醒后它又要再次遍历fd。
特点：
1：poll没有最大连接数限制，因为它是用基于链表来存储的，跟selelct直接监听fd不一样。
2：同样的大量的fd的数组被整体复制与用户态和内核地址空间之间。
3：poll还有一个特点是水平触发：如果报告了fd后没有被处理，则下次poll时还会再次报告该fd。
4：跟select一样，在poll返回后，还是需要通过遍历fdset来获取已经就绪的socket。当fd很多时，效率会线性下降。
三：epoll
epoll支持水平触发和边缘触发，最大的特点在于边缘触发，它只告诉进程哪些fd刚刚变为就绪态，并且只会通知一次。还有一个特点是，epoll使用“事件”的就绪通知方式，通过epoll_ctl注册fd，一旦该fd就绪，内核就会采用类似callback的回调机制来激活该fd，epoll_wait便可以收到通知。
没有最大并发连接的限制，能打开的FD的上限远大于1024（1G的内存上能监听约10万个端口）。
效率提升，不是轮询的方式，不会随着FD数目的增加效率下降。只有活跃可用的FD才会调用callback函数；即Epoll最大的优点就在于它只管你“活跃”的连接，而跟连接总数无关，因此在实际的网络环境中，Epoll的效率就会远远高于select和poll。
内存拷贝，利用mmap()文件映射内存加速与内核空间的消息传递；即epoll使用mmap减少复制开销。
