从历史进程来看可能会比较好
早期计算机性能较差的情况下反正你同时也没法同时处理很多io,不如开一个就阻塞在那边,程序员编程也省事,别的花里胡哨的骚操作还未必有这种方式性能高,这个叫做bio
后面cpu内存性能上去了,磁盘还那样,磁盘io成瓶颈了,就弄了新api出来,扫描出传输完毕数据就绪的io句柄进行操作,这里因为早期cpu核心数少,所以扫描出就绪的io句柄都是同步一个个执行的,这个叫nio
再后来,cpu核心数多了,发现这种按模式就是一核有难3核围观,就使用空间复杂度更高的实现方式把处理就绪io句柄异步分发到线程池里执行,这个叫做aio
同期,互联网用户的量上来了,然后网络通信占用的连接数指数增加,然后发现linux最早提供的把所有io句柄放在一个list里scan就绪io句柄的实现在1w链接情况下因为o(n)时间复杂度变成了性能瓶颈,于是就提供了一个基于二叉树实现的发现就绪句柄的api,叫做epoll
再后来,程序员把网络这块的性能反复挖掘,发现每次网络io数据都要从网卡拷贝到操作系统,然后操作系统再拷贝到应用内,应用内自身可能又被反复拷贝来拷贝去做处理,于是就弄出来各种框架,有用于应用内零拷贝的封装实现(netty的bytebuffer),有直接访问操作系统数据的零拷贝实现(堆外内存映射),甚至有框架直接旁路了操作系统,在应用层直接访问网卡数据(dpdk)
各种api基本上就是个填坑史