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

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个套接字:如果使用阻塞IO，可能因为读取一个没有数据的套接字而阻塞剩下的99个套接字的数据处理，那么就会造成服务器的响应性很差。如果使用非阻塞IO，那么就需要轮询这一百个套接字到底可不可以读取到数据，这个轮询操作会浪费CPU时间片，照样也不是一个高效的方式，套接字多了，照样性能很差。那有没有一种比较好的方式来同时检测多个套接字是否可读可写，并且不浪费CPU时间片呢？那就是要用IO多路复用了，使用IO多路复用可以同时检测多个不同的套接字是否就绪。有多种IO多路复用的实现，其中包括select，poll,epoll,/dev/poll,kqueue等。