AIO,BIO,NIO,IO复用，同步，异步，阻塞和非阻塞
(1)什么是NIO(Non-blocked IO),AIO,BIO
(2) 区别
(3)select 与 epoll,poll区别
1.什么是socket？什么是I/O操作？
什么是socket？
实际上socket是对TCP/IP协议的封装，它的出现只是使得程序员更方便地使用TCP/IP协议栈而已。socket本身并不是协议，它是应用层与TCP/IP协议族通信的中间软件抽象层，是一组调用接口（TCP/IP网络的API函数）。
socket起源于Unix，而Unix/Linux基本哲学之一就是“一切皆文件”，都可以用“打开open –> 读写write/read –> 关闭close”模式来操作。我的理解就是Socket就是该模式的一个实现，socket即是一种特殊的文件，一些socket函数就是对其进行的操作（读/写IO、打开、关闭。
什么是IO操作？
unix世界里，一切皆文件，而文件是什么呢？文件就是一串二进制流而已。在信息交换的过程中，我们都是对这些流进行数据的收发操作，简称为I/O操作(input and output)，往流中读出数据，系统调用read，写入数据，系统调用write。
fd（文件描述符）：
计算机里有这么多的流，我怎么知道要操作哪个流呢？对，就是文件描述符，即通常所说的fd，一个fd就是一个整数，所以，对这个整数的操作，就是对这个文件（流）的操作。我们创建一个socket，通过系统调用会返回一个文件描述符，那么剩下对socket的操作就会转化为对这个描述符的操作。不能不说这又是一种分层和抽象的思想。
2. 同步异步、阻塞非阻塞
实际上同步与异步是针对应用程序与内核的交互而言的。同步过程中进程触发IO操作并等待(也就是我们说的阻塞)或者轮询的去查看IO操作(也就是我们说的非阻塞)是否完成。 异步过程中进程触发IO操作以后，直接返回，做自己的事情，IO交给内核来处理，完成后内核通知进程IO完成。
同步和异步针对应用程序来，关注的是程序中间的协作关系；阻塞与非阻塞更关注的是单个进程的执行状态。
同步有阻塞和非阻塞之分，异步没有，它一定是非阻塞的。
异步必定是非阻塞的，所以不存在异步阻塞和异步非阻塞的说法。真正的异步IO需要CPU的深度参与。换句话说，只有用户线程在操作IO的时候根本不去考虑IO的执行全部都交给CPU去完成，而自己只等待一个完成信号的时候，才是真正的异步IO。所以，拉一个子线程去轮询、去死循环，或者使用select、poll、epoll，都不是异步。
- 同步：执行一个操作之后，进程触发IO操作并等待(也就是我们说的阻塞)或者轮询的去查看IO操作(也就是我们说的非阻塞)是否完成，等待结果，然后才继续执行后续的操作。
- 异步：执行一个操作后，可以去执行其他的操作，然后等待通知再回来执行刚才没执行完的操作。
- 阻塞：进程给CPU传达一个任务之后，一直等待CPU处理完成，然后才执行后面的操作。
- 非阻塞：进程给CPU传达任我后，继续处理后续的操作，隔断时间再来询问之前的操作是否完成。这样的过程其实也叫轮询。
故事：老王烧开水。
出场人物：老张，水壶两把（普通水壶，简称水壶；会响的水壶，简称响水壶）。老王想了想，有好几种等待方式：
1.【同步阻塞】老王用水壶煮水，并且站在那里，不管水开没开，每隔一定时间看看水开了没。
老王想了想，这种方法不够聪明。
2.【同步非阻塞】老王还是用水壶煮水，不再傻傻的站在那里看水开，跑去寝室上网，但是还是会每隔一段时间过来看看水开了没有，水没有开就走人。
老王想了想，现在的方法聪明了些，但是还是不够好。
3.×【异步阻塞】老王这次使用高大上的响水壶来煮水，站在那里，但是不会再每隔一段时间去看水开，而是等水开了，水壶会自动的通知他。－
老王想了想，不会呀，既然水壶可以通知我，那我为什么还要傻傻的站在那里等呢，嗯，得换个方法。
4.【异步非阻塞】老王还是使用响水壶煮水，跑到客厅上网去，等着响水壶自己把水煮熟了以后通知他。
老王豁然，这下感觉轻松了很多。
- 同步和异步：同步就是烧开水，需要自己去轮询（每隔一段时间去看看水开了没），异步就是水开了，然后水壶会通知你水已经开了，你可以回来处理这些开水了。同步和异步是相对于操作结果来说，会不会等待结果返回。
- 阻塞和非阻塞：阻塞就是说在煮水的过程中，你不可以去干其他的事情，非阻塞就是在同样的情况下，可以同时去干其他的事情。阻塞和非阻塞是相对于线程是否被阻塞。
三、IO模型
网络IO的模型大致包括下面几种：
- 同步模型（synchronous IO）
- 阻塞IO（bloking IO） BIO
- 非阻塞IO（non-blocking IO） NIO
- 多路复用IO（multiplexing IO）
- 信号驱动式IO（signal-driven IO）
- 异步IO（asynchronous IO）
- 异步IO AIO
网络IO的本质是socket的读取，socket在linux系统被抽象为流，IO可以理解为对流的操作。对于一次IO访问，数据会先被拷贝到操作系统内核的缓冲区中，然后才会从操作系统内核的缓冲区拷贝到应用程序的地址空间，所以一般会经历两个阶段：
- 等待所有数据都准备好或者一直在等待数据，有数据的时候将数据拷贝到系统内核；
- 将内核缓存中数据拷贝到用户进程中。
对于socket流而言：
- 等待网络上的数据分组到达，然后被复制到内核的某个缓冲区；
- 把数据从内核缓冲区复制到应用进程缓冲区中。
- 同步：不管是BIO,NIO,还是IO多路复用，第二步数据从内核缓存写入用户缓存一定是由用户线程自行读取数据，处理数据。
- 异步：第二步数据是内核写入的，并放在了用户线程指定的缓存区，写入完毕后通知用户线程。
3.1 同步阻塞IO（BIO）
默认情况下，所有套接口都是阻塞的。 进程调用recvfrom系统调用，整个过程是阻塞的，直到数据复制到用户进程缓冲区时才返回（当然，系统调用被中断也会返回）。
用户线程通过系统调用read发起IO读操作，由用户空间转到内核空间。内核等到数据包到达后，然后将接收的数据拷贝到用户空间，完成read操作。 用户需要等待read将socket中的数据读取到buffer后，才继续处理接收的数据。整个IO请求的过程中，用户线程是被阻塞的，这导致用户在发起IO请求时，不能做任何事情，对CPU的资源利用率不够。
3.2 同步非阻塞IO（非java中的NIO）
线程发起io请求后，立即返回（非阻塞io），用户线程不阻塞等待，但是，用户线程要定时轮询检查数据是否就绪。当数据没有准备好时，内核立即返回EWOULDBLOCK错误，当数据准备好后，将数据复制到进程缓冲区中。
同步非阻塞IO是在同步阻塞IO的基础上，将socket设置为非阻塞的方式，因此用户线程发起IO请求时立即返回。但并未读取到任何数据，用户线程需要不断地发起IO请求，直到数据到达后，才真正读取到数据，继续执行。
整个IO请求的过程中，虽然用户线程每次发起IO请求后可以立即返回，但是为了等到数据，仍需要不断地轮询、重复请求，消耗了大量的CPU的资源。
3.3 多路复用IO（Java中的NIO就是采用的此模式）
上述NIO实现中，需要用户线程定时轮训，去检查IO数据是否就绪，占用应用程序线程资源。IO多路复用模型中，将检查IO数据是否就绪的任务，交给系统级别的select或poll模型，由系统进行监控，避免同步非阻塞IO模型中轮询等待的问题，减轻用户线程负担。
当用户线程发起IO请求后，将socket连接及关注事件注册到selector（多路复用器，os级别线程）上，selector循环遍历socket连接，看是否有关注数据就绪，如果连接有数据就绪后，就通知应用程序，建立线程进行数据读写。同BIO对比，多路复用IO中线程处理的都是有效连接（数据就绪），且一个线程可以分管处理多个连接上的就绪数据，节省线程资源开销。
IO多路复用模型使用了Reactor设计模式实现了这一机制。Reactor模式中，用户线程通过向Reactor对象注册感兴趣的事件监听，然后事件触发时调用事件处理函数。
通过Reactor的方式，可以将用户线程轮询IO操作状态的工作统一交给handle_events事件循环进行处理。用户线程注册事件处理器之后可以继续执行做其他的工作（异步），而Reactor线程负责调用内核的select函数检查socket状态。当有socket被激活时，则通知相应的用户线程（或执行用户线程的回调函数），执行handle_event进行数据读取、处理的工作。由于select函数是阻塞的，因此多路IO复用模型也被称为异步阻塞IO模型。注意，这里的所说的阻塞是指select函数执行时线程被阻塞，而不是指socket。一般在使用IO多路复用模型时，socket都是设置为NONBLOCK的，不过这并不会产生影响，因为用户发起IO请求时，数据已经到达了，用户线程一定不会被阻塞。
（1）select：注册的socket事件由数组管理，长度有限制，轮询查找时需要遍历数组。它仅仅知道有I/O事件发生了，却并不知道是哪那几个流（可能有一个，多个，甚至全部），我们只能无差别轮询所有流，找出能读出数据，或者写入数据的流，对他们进行操作。所以select具有O(n)的无差别轮询复杂度，同时处理的流越多，无差别轮询时间就越长。
（2）poll：注册的socket事件由链表实现，数量没有限制，遍历链表轮询查找。poll本质上和select没有区别， 但是它没有最大连接数的限制，原因是它是基于链表来存储的。
（3）epoll：基于事件驱动思想，采用reactor模式，通过事件回调，无需使用某种方式主动检查socket状态，被动接收就绪事件即可。epoll可以理解为event poll，不同于忙轮询和无差别轮询，epoll会把哪个流发生了怎样的I/O事件通知我们。所以我们说epoll实际上是事件驱动（每个事件关联上fd）的，此时我们对这些流的操作都是有意义的。（复杂度降低到了O(1)）。
select的几大缺点：
- 每次调用select，都需要把fd（fd是进程独有的文件描述符表的索引）集合从用户态拷贝到内核态，这个开销在fd很多时会很大。
- 每次调用select都需要在内核遍历传递进来的所有fd，这个开销在fd很多时也很大。
- select支持的文件描述符数量太小了，默认是1024。
epoll既然是对select和poll的改进，就应该能避免上述的三个缺点。那epoll都是怎么解决的呢？在此之前，我们先看一下epoll和select和poll的调用接口上的不同：select和poll都只提供了一个函数——select或者poll函数。而epoll提供了三个函数，epoll_create、epoll_ctl和epoll_wait。
- epoll_create 是创建一个epoll句柄；
- epoll_ctl 是注册要监听的事件类型；
- epoll_wait 则是等待事件的产生。
对于第一个缺点，epoll的解决方案在epoll_ctl函数中。每次注册新的事件到epoll句柄中时（在epoll_ctl中指定EPOLL_CTL_ADD），会把所有的fd拷贝进内核，而不是在epoll_wait的时候重复拷贝。epoll保证了每个fd在整个过程中只会拷贝一次。
对于第二个缺点，epoll的解决方案不像select或poll一样每次都把current轮流加入fd对应的设备等待队列中，而只在epoll_ctl时把current挂一遍（这一遍必不可少）并为每个fd指定一个回调函数，当设备就绪，唤醒等待队列上的等待者时，就会调用这个回调函数，而这个回调函数会把就绪的fd加入一个就绪链表。epoll_wait的工作实际上就是在这个就绪链表中查看有没有就绪的fd（利用schedule_timeout()实现睡一会，判断一会的效果）。
对于第三个缺点，epoll没有这个限制，它所支持的fd上限是最大可以打开文件的数目，这个数字一般远大于2048。举个例子,在1GB内存的机器上大约是10万左右，具体数目可以cat /proc/sys/fs/file-max察看,一般来说这个数目和系统内存关系很大。
总结：
- select，poll实现需要自己不断轮询所有fd集合，直到设备就绪，期间可能要睡眠和唤醒多次交替。而epoll其实也需要调用epoll_wait不断轮询就绪链表，期间也可能多次睡眠和唤醒交替，但是它是设备就绪时，调用回调函数，把就绪fd放入就绪链表中，并唤醒在epoll_wait中进入睡眠的进程。虽然都要睡眠和交替，但是select和poll在“醒着”的时候要遍历整个fd集合，而epoll在“醒着”的时候只要判断一下就绪链表是否为空就行了，这节省了大量的CPU时间。这就是回调机制带来的性能提升。
- select，poll每次调用都要把fd集合从用户态往内核态拷贝一次，并且要把current往设备等待队列中挂一次，而epoll只要一次拷贝，而且把current往等待队列上挂也只挂一次（在epoll_wait的开始，注意这里的等待队列并不是设备等待队列，只是一个epoll内部定义的等待队列）。这也能节省不少的开销。
3.4 异步IO（AIO）
线程发起io请求后，立即返回（非阻塞io），当数据读写完成后，OS通知用户线程（异步）。这里数据写入socket空间，或从socket空间读取数据到用户空间由OS完成，用户线程无需介入，所以也就不会阻塞用户线程，即异步。
“真正”的异步IO需要操作系统更强的支持。在IO多路复用模型中，事件循环将文件句柄的状态事件通知给用户线程，由用户线程自行读取数据、处理数据。而在异步IO模型中，当用户线程收到通知时，数据已经被内核读取完毕，并放在了用户线程指定的缓冲区内，内核在IO完成后通知用户线程直接使用即可。
再强调一下Java中的IO（多路复用IO）：
New IO是对BIO的改进，基于Reactor模型。我们知道，一个socket连接只有在特定时候才会发生数据传输IO操作，大部分时间这个“数据通道”是空闲的，但还是占用着线程。NIO作出的改进就是“一个请求一个线程”，在连接到服务端的众多socket中，只有需要进行IO操作的才能获取服务端的处理线程进行IO。这样就不会因为线程不够用而限制了socket的接入。客户端的socket连接到服务端时，就会在事件分离器注册一个 IO请求事件 和 IO 事件处理器。在该连接发生IO请求时，IO事件处理器就会启动一个线程来处理这个IO请求，不断尝试获取系统的IO的使用权限，一旦成功（即：可以进行IO），则通知这个socket进行IO数据传输。
-
优点：相较于阻塞模型，非阻塞不用再等待任务，而是把时间花费到其它任务上，也就是这个当前线程同时处理多个任务；
-
缺点：导致任务完成的响应延迟增大了，因为每隔一段时间才去执行询问的动作，但是任务可能在两个询问动作的时间间隔内完成，这会导致整体数据吞吐量的降低。
reactor模型：
BIO是“一个连接一个线程”，这样的缺点在于多线程并发模式下，一个连接一个线程资源要求太高，系统中创建线程是需要比较高的系统资源的，如果连接数太高，系统无法承受，而且，线程的反复创建-销毁也需要代价。
改进方法是：采用基于事件驱动的设计，当有事件触发时，才会调用处理器进行数据处理。使用Reactor模式，对线程的数量进行控制，一个线程处理大量的事件。
reactor是一种基于事件驱动模型的设计模式，（事件驱动体系结构会定义一系列的事件处理器来响应事件的发生，并且将服务端接受连接与对事件的处理分离），用于处理多个客户端并发的向服务端请求服务的场景。每种服务在服务端可能由多个方法组成。reactor会解耦并发请求的服务并分发给对应的事件处理器来处理。
首先我们基于Reactor Pattern 处理模式中，定义以下三种角色:
- Reactor：将I/O事件分派给对应的Handler
- Acceptor：处理客户端新连接，并分派请求到处理器链中
- Handlers：执行非阻塞读/写任务
有新连接到来触发connect 事件之后，交由Acceptor进行处理，有IO读写事件之后交给hanlder 处理。也就是所有的读写事件都是在acceptor分发，有读写事件激活时才调用线程资源去执行，不会一直堵塞等着读写操作。
使用单线程模拟多线程，提高资源利用率和程序的效率，增加系统吞吐量。下面例子比较形象的说明了什么是Reactor （反应器）模式：
一个老板经营一个饭店，
传统模式 - 来一个客人安排一个服务员招呼，客人很满意；（相当于一个连接一个线程）
后来客人越来越多，需要的服务员越来越多，资源条件不足以再请更多的服务员了，传统模式已经不能满足需求。老板之所以为老板自然有过人之处，老板发现，服务员在为客人服务时，当客人点菜的时候，服务员基本处于等待状态，（阻塞线程，不做事）。于是乎就让服务员在客人点菜的时候，去为其他客人服务，当客人菜点好后再招呼服务员即可。 --反应器（reactor）模式诞生了
饭店的生意红红火火，几个服务员就足以支撑大量的客流量，老板用有限的资源赚了更多的money~~~~^_^
总结
（1）BIO：同步阻塞式IO。服务器实现模式为一个连接一个线程，即客户端有连接请求时服务器端就需要启动一个线程进行处理，这种模式明显的一个缺陷是：由于客户端连接数与服务器线程数成正比关系，可能造成不必要的线程开销。这种情况可以通过线程池改善。 （JDK1.4出来之前，建立网络连接的时候采用BIO模式）
线程发起io请求后，会一直阻塞(阻塞io)，直到数据就绪后，将数据复制到进程缓冲区中。
（2）NIO：同步非阻塞式IO。服务器实现模式是一个请求一个线程。即客户端发送的连接请求都会注册到多路复用器上，多路复用器轮询到连接有IO请求时才启动一个线程进行处理。
线程发起io请求后，立即返回（非阻塞io）。用户线程不阻塞等待，但是，用户线程要定时轮询检查数据是否就绪。当数据没有准备好时，内核立即返回EWOULDBLOCK错误，当数据准备好后，将数据复制到进程缓冲区中。
（3）IO多路复用：上述NIO实现中，需要用户线程定时轮询，去检查IO数据是否就绪，占用应用程序线程资源。IO多路复用模型中，将检查IO数据是否就绪的任务，交给系统级别的select或poll模型，由系统进行监控，减轻用户线程负担。
（3）AIO：异步非阻塞式IO。服务器实现模式为一个有效请求一个线程。客户端的I/O请求都是由操作系统先完成了再通知服务器应用去启动线程进行处理。（用户进程只需要发起一个IO操作然后立即返回，等IO操作真正的完成以后，应用程序会得到IO操作完成的通知，此时用户进程只需要对数据进行处理就好了，不需要进行实际的IO读写操作，因为真正的IO读取或者写入操作已经由内核完成了）
应用场景：
并发连接数不多时采用BIO，因为它编程和调试都非常简单；但如果涉及到高并发的情况，应选择NIO或AIO，更好的建议是采用成熟的网络通信框架Netty。
参考IO复用,AIO,BIO,NIO,同步，异步，阻塞和非阻塞 区别(百度面试)
