（二）IO模型之阻塞与非阻塞
一、阻塞IO（blocking IO）
在 linux中，默认情况下所有的 socket都是blocking，一个典型的读操作流程大概是这样：
当用户进程调用了 recvfrom这个系统调用，kernel就开始了IO的第一个阶段：准备数据。
对于 network io来说，很多时候数据在一开始还没有到达（比如，还没有收到一个完整的UDP包），这个时候 kernel就要等待足够的数据到来。
而在用户进程这边，整个进程会被阻塞。当 kernel一直等到数据准备好了，它就会将数据从 kernel中拷贝到用户内存，然后 kernel返回结果，用户进程才解除 block的状态，重新运行起来。
所以，blocking IO的特点就是在IO执行的两个阶段（等待数据和拷贝数据两个阶段）都被 block了。
几乎所有的程序员第一次接触到的网络编程都是从 listen()，send()，recv()，等接口开始的，使用这些接口可以很方便的构建服务器/客户机的模型。然而大部分的 socket接口都是阻塞型的，如下图：
Tip：所谓阻塞型接口是指系统调用（一般是IO接口）不返回调用结果并让当前线程一直阻塞，只有当该系统调用获得结果或者超时出错时才返回。
实际上，除非特别指定，几乎所有的 IO接口 ( 包括socket接口 ) 都是阻塞型的。这给网络编程带来了一个很大的问题，如在调用 recv(1024)的同时，线程将被阻塞，在此期间，线程将无法执行任何运算或响应任何的网络请求。
一个简单地解决方案：
# 在服务器端使用多线程（或多进程）。 # 多线程（或多进程）的目的是让每个连接都拥有独立的线程（或进程），这样任何一个连接的阻塞都不会影响其他的连接。
该方案的问题是：
# 开启多进程或都线程的方式，在遇到要同时响应成百上千路的连接请求，则无论多线程还是多进程都会严重占据系统资源， # 降低系统对外界响应效率，而且线程与进程本身也更容易进入假死状态。
改进方案：
# 很多程序员可能会考虑使用“线程池”或“连接池”。 # “线程池”旨在减少创建和销毁线程的频率，其维持一定合理数量的线程，并让空闲的线程重新承担新的执行任务。 # “连接池”维持连接的缓存池，尽量重用已有的连接、减少创建和关闭连接的频率。 # 这两种技术都可以很好的降低系统开销，都被广泛应用很多大型系统，如websphere、tomcat和各种数据库等。
改进后方案其实也存在着问题：
# “线程池”和“连接池”技术也只是在一定程度上缓解了频繁调用IO接口带来的资源占用。 # 而且，所谓“池”始终有其上限，当请求大大超过上限时，“池”构成的系统对外界的响应并不比没有池的时候效果好多少。 # 所以使用“池”必须考虑其面临的响应规模，并根据响应规模调整“池”的大小。
对应上例中的所面临的可能同时出现的上千甚至上万次的客户端请求，“线程池”或“连接池”或许可以缓解部分压力，但是不能解决所有问题。总之，多线程模型可以方便高效的解决小规模的服务请求，但面对大规模的服务请求，多线程模型也会遇到瓶颈，可以用非阻塞接口来尝试解决这个问题。
二、非阻塞IO（non-blocking IO）
Linux下，可以通过设置socket使其变为non-blocking。当对一个non-blocking socket执行读操作时，流程是这个样子：
从图中可以看出，当用户进程发出 read操作时，如果 kernel中的数据还没有准备好，那么它并不会 block用户进程，而是立刻返回一个 error。
从用户进程角度讲 ，它发起一个 read操作后，并不需要等待，而是马上就得到了一个结果。
用户进程判断结果是一个 error时，它就知道数据还没有准备好，于是用户就可以在本次到下次再发起 read询问的时间间隔内做其他事情，或者直接再次发送 read操作。
一旦 kernel中的数据准备好了，并且又再次收到了用户进程的 system call，那么它马上就将数据拷贝到了用户内存（这一阶段仍然是阻塞的），然后返回。
也就是说非阻塞的 recvform系统调用之后，进程并没有被阻塞，内核马上返回给进程，如果数据还没准备好，此时会返回一个 error。
进程在返回之后，可以干点别的事情，然后再发起 recvform系统调用。
重复上面的过程，循环往复的进行 recvform系统调用。这个过程通常被称之为轮询。
轮询检查内核数据，指导数据准备好，再拷贝数据到进程，进行数据处理。
需要注意，拷贝数据的整个过程，进程仍然是属于阻塞的状态。
所以，在非阻塞式 IO中，用户进程其实是需要不断的主动询问 kernel数据准备好了没有。
非阻塞 IO示例：
服务端：
# 实现自己监测IO，遇到IO，就切到我单个线程的其他用户去运行了，实现单线程下的并发，并把单线程的效率提到了最高。 from socket import * server = socket(AF_INET, SOCK_STREAM) server.bind(("192.168.2.209",8800)) server.listen(5) server.setblocking(False) # 默认是 True(阻塞)，改成 False(非阻塞) print("starting...") rlist = [] wlist = [] while True: try: conn, addr = server.accept() rlist.append(conn) print(rlist) except BlockingIOError: # 收消息 del_rlist = [] # 要删除的链接 for conn in rlist: try: data = conn.recv(1024) if not data: del_rlist.append(conn) continue # conn.send(data.upper()) wlist.append((conn,data.upper())) except BlockingIOError: continue except Exception: conn.close() # 服务端单方面断开，这个链接就可以回收掉了 del_rlist.append(conn) # 发消息 del_wlist = [] for item in wlist: try: conn = item[0] data = item[1] # 如果这里抛异常，那么下行代码运行不了，如果没抛异常，发成功了，就把链接加到删除的列表 conn.send(data) del_wlist.append(item) except BlockingIOError: pass for item in del_wlist: wlist.remove(item) for conn in del_rlist: rlist.remove(conn) server.close()
客户端：
from socket import * client = socket(AF_INET,SOCK_STREAM) client.connect(("192.168.2.209",8800)) while True: msg = input(">>:").strip() if not msg:continue client.send(msg.encode("utf-8")) data = client.recv(1024) print("收到的数据：%s" % data.decode("utf-8")) client.close()
但是非阻塞 IO模型绝不被推荐。
我们不能否定其优点：
能够在等待任务完成的时间里干其他活了（包括提交其他任务，也就是 “后台” 可以有多个任务在“”同时“”执行）。
但是也难掩其缺点：
# 1，循环调用 recv()将大幅度推高 CPU占用率；这也是我们在代码中留一句time.sleep(2)的原因，否则在低配主机下极容易出现卡机情况。 # 2，任务完成的响应延迟增大了，因为每过一段时间才去轮询一次 read操作，而任务可能在两次轮询之间的任意时间完成。这会导致整体数据吞吐量的降低。
此外，在这个方案中 recv()更多的是起到检测“操作是否完成”的作用，实际操作系统提供了更为高效的检测“操作是否完成“作用的接口，例如 select()多路复用模式，可以一次检测多个连接是否活跃。
