线程阻塞:通常是指一个线程在执行过程中暂停,以等待某个条件的触发。以下是理解:
"阻塞模式挺好的,应为在阻塞状态下,用户进程会被挂起,挂起就是说不会再占用cpu资源了"
我觉着阻塞模型这不挺好么,自己所请求的网络数据没有准备好,然后把cpu让给别人用,这不是很好么?对于非阻塞,又有些人说"非阻塞好,非阻塞可以在用户进程请求的数据没有准备好的时候,让内核立即给予响应,然后用户进程可以干别的,一会儿再来检查一下,这样轮循"我觉着这样也没问题啊,至少进程也没闲着啊,只不过进程虽然干了别的,但也多干了一些活,例如轮询相比起来,貌似比阻塞省下了cpu资源给别人用;而非阻塞是抓紧利用cpu资源,但为了抓紧使用,缺同时走了不少多余的路,比如不断地轮询所以......到底....各自解决什么问题,蒙了
HUH函数
说个场景吧。假设你用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的时候,它返回数据是毫秒级别的,那么你认为,它是阻塞呢还是非阻塞呢?这个时候,这两个的概念就模糊了。具体你还是要实际判断。
如果只有一个套接字的情况下,使用阻塞IO是极好的,读到数据就返回。但是如果在有很多套接字的情况下,比如有100个套接字:如果使用阻塞IO,可能因为读取一个没有数据的套接字而阻塞剩下的99个套接字的数据处理,那么就会造成服务器的响应性很差。如果使用非阻塞IO,那么就需要轮询这一百个套接字到底可不可以读取到数据,这个轮询操作会浪费CPU时间片,照样也不是一个高效的方式,套接字多了,照样性能很差。那有没有一种比较好的方式来同时检测多个套接字是否可读可写,并且不浪费CPU时间片呢?那就是要用IO多路复用了,使用IO多路复用可以同时检测多个不同的套接字是否就绪。有多种IO多路复用的实现,其中包括select,poll,epoll,/dev/poll,kqueue等。