同步（synchronous） I/O和异步（asynchronous） I/O，阻塞（blocking） I/O和非阻塞（non-blocking）I/O分别是什么，到底有什么区别？这个问题其
实不同的人给出的答案都可能不同，
比如wiki，就认为asynchronous I/O和non-blocking I/O是一个东西。这其实是因为不同的人的知识背景不同，并且在讨论这个问题的时候上下文(context)也不相同。所以，为了更好的回答这个问题，
我先限定一下本文的上下文。

住这两点很重要，因为这些I/O模型的区别就是在两个阶段上各有不同的情况。

在网络环境下，再通俗的讲，将I/O分为两步：

等；

数据搬迁。

如果要想提高I/O效率，需要将等的时间降低。

五种I/O模型包括：阻塞I/O、非阻塞I/O、信号驱动I/O、I/O多路转接、异步I/O。其中，前四个被称为同步I/O。

通俗理解阻塞Io模型    以买票的例子举例，该模型小结为

# 老王去火车站买票，排队三天买到一张退票。 

# 耗费：在车站吃喝拉撒睡 3天，其他事一件没干

当用户进程调用了recvfrom这个系统调用，kernel就开始了I/O的第一个阶段：准备数据。对于network I/O来说，很多时候数据在一开始还没有到达（比如，还没有收到一个完整的UDP包）
这个时候kernel就要等待足够的数据到来。

而在用户进程这边，整个进程会被阻塞。当kernel一直等到数据准备好了，它就会将数据从kernel中拷贝到用户内存，然后kernel返回结果，用户进程才解除block的状态，
重新运行起来。所以，
blocking I/O的特点就是在I/O执行的两个阶段
（等待数据和拷贝数据两个阶段）都被block了。

几乎所有的程序员第一次接触到的网络编程都是从listen()、send()、recv() 等接口开始的，使用这些接口可以很方便的构建服务器/客户机的模型。然而大部分的socket接口都是阻塞型的。如下图

所谓阻塞型接口是指系统调用（一般是I/O接口）不返回调用结果并让当前线程一直阻塞，只有当该系统调用获得结果或者超时出错时才返回。

1.简单的解决方案 (这个方法有一些弊端)

在服务器端使用多线程（或多进程）。多线程（或多进程）的目的是让每个连接都拥有独立的线程（或进程），这样任何一个连接的阻塞都不会影响其他的连接

改进后方案的问题

1. 很多程序员可能会考虑使用“线程池”或“连接池”。“线程池”旨在减少创建和销毁线程的频率，其维持一定合理数量的线程，并让空闲的线程重新承担新的执行任务。“连接池”维持连接的缓存池，尽量重用已有的连接、减少创建和关闭连接的频率。

    这两种技术都可以很好的降低系统开销，都被广泛应用很多大型系统，如websphere、tomcat和各种数据库等。

2.“线程池”和“连接池”技术也只是在一定程度上缓解了频繁调用I/O接口带来的资源占用。而且，所谓“池”始终有其上限，当请求大大超过上限时，“池”构成的系统对外界

   的响应并不比没有池的时候效果好多少所以使用“池”必须考虑其面临的响应规模，并根据响应规模调整“池”的大小。

3. 对应上例中的所面临的可能同时出现的上千甚至上万次的客户端请求，“线程池”或“连接池”或许可以缓解部分压力，但是不能解决所有问题。总之，

   多线程模型可以方便高效的解决小规模的服务请求，但面对大规模的服务请求，多线程模型也会遇到瓶颈，可以用非阻塞接口来尝试解决这个问题。

通俗理解非阻塞IO模型   以买票的例子举例，该模型小结为：

# 老王去火车站买票，隔12小时去火车站问有没有退票，三天(72个小时)后买到一张票。

# 耗费：往返车站6次，路上6小时，其他时间做了好多事。