就是阻塞IO不好是因为数据没准备好时，线程被阻塞。
然后今天看IO模型发现非阻塞IO好像也不是我想的，Java NIO其实是多路复用IO。
根据IO模型中非阻塞的说法，非阻塞IO模型，如果数据没准备好，会马上返回结果，不阻塞线程，但是会一直轮询数据是否准备完毕，那这样线程不也是一直被占用着吗，而且还占用CPU，这不比阻塞IO更坑，阻塞式IO虽然线程阻塞了，但是会把CPU交出去做其他事
非阻塞IO，是在读写的时候，函数的调用不会被阻塞执行，而是立即返回状态结果。
如果要完成正常的读写操作一般都会选择轮询的方式进行处理。
轮询操作是会消耗CPU指令，但是，一个轮询线程，可以轮询多个IO，从而提高线程的使用效率；
另外，轮询操作可以通过Selector类来实现，这样的话，当所有IO都没有准备好数据时，轮询线程也可以是阻塞状态，而不用空循环。
楼主理解的轮询，可能就是一个死循环，大多会出现没有阻塞的空循环，很明显，这种简单的轮询，不适用CPU密集型的业务场景，空循环的占比太高。
每种技术都会有它的特点以及适用场景。
阻塞IO，由于编程思路简单直接，可以应用在CPU密集型的业务场景，对于线程的生命周期而言，重心在数据的处理过程而非读写（比如文件的加解密）。
非阻塞IO，编程复杂度会上升，但是，由于它可以实现单一线程处理多个IO的读写操作，适用于IO密集型的业务场景（比如大批量的文件拷贝）。
总体来讲，我们对项目进行设计和优化的宗旨都是想最大程度的发挥计算机的性能，提高整体效率。
计算机系统的任何资源尽量别闲着，不用的资源尽量及时回收。
数据量大的时候这点牺牲相对起来就很渺小了
IO阻塞和cpu资源切换分别占用的耗时不是一个量级的