阻塞和非阻塞 都有优点, 我理解的对么

Question

最近在网上看了一些有关IO模型的资料, 有人说 "阻塞模式挺好的, 应为在阻塞状态下, 用户进程会被挂起, 挂起就是说不会再占用cpu资源了"

我觉着 阻塞模型这不挺好么, 自己所请求的网络数据没有准备好, 然后把cpu让给别人用, 这不是很好么?

对于非阻塞, 又有些人说 "非阻塞好, 非阻塞可以在用户进程请求的数据没有准备好的时候, 让内核立即给予响应, 然后用户进程可以干别的, 一会儿再来检查一下, 这样轮循" 我觉着这样也没问题啊, 至少进程也没闲着啊, 只不过 进程虽然干了别的, 但也多干了一些活,例如轮询

相比起来, 貌似比阻塞省下了cpu资源给别人用; 而非阻塞是抓紧利用cpu资源, 但为了抓紧使用,缺同时走了不少多余的路, 比如不断地轮询 所以......

到底.... 各自解决什么问题, 蒙了

Answer 1

说个场景吧。

假设你用 php-fpm，你的 php 程序中需要向外部接口请求。php-fpm 是阻塞的模型，那么每一个 Worker 进程在执行这些网络 I/O 的时候，是不是都阻塞了？假设你的 php-fpm 最大进程数有 500 个，那么同时进来了 500 个请求，是不是都阻塞在了网络 I/O 上了？那么接下来，php-fpm 已经无法处理第 501 个请求了。可是此时，由于在等待网络 I/O 响应，CPU 实际上并没有做什么工作，你会发现，CPU 闲的要死，但是却无法处理请求了。

那么非阻塞呢？用 Swoole 举例子。我们在网络 I/O 的时候，让它去等待响应，与此同时，处理下一个请求。那么，我们会发现，并发数上去了，CPU 的利用率变高了。

假设你在用 Redis 的时候，它返回数据是毫秒级别的，那么你认为，它是阻塞呢还是非阻塞呢？这个时候，这两个的概念就模糊了。具体你还是要实际判断。

Answer 2

如果只有一个套接字的情况下，使用阻塞IO是极好的，读到数据就返回。

但是如果在有很多套接字的情况下，比如有100个套接字:

1. 如果使用阻塞IO，可能因为读取一个没有数据的套接字而阻塞剩下的99个套接字的数据处理，那么就会造成服务器的响应性很差。
2. 如果使用非阻塞IO，那么就需要轮询这一百个套接字到底可不可以读取到数据，这个轮询操作会浪费CPU时间片，照样也不是一个高效的方式，套接字多了，照样性能很差。

那有没有一种比较好的方式来同时检测多个套接字是否可读可写，并且不浪费CPU时间片呢？那就是要用IO多路复用了，使用IO多路复用可以同时检测多个不同的套接字是否就绪。有多种IO多路复用的实现，其中包括select，poll, epoll, /dev/poll, kqueue等。