本文转载自：https://www.jianshu.com/p/444646e02ef7  感谢原作者“大宽宽”的精心总结。

本文从操作系统的角度来解释BIO，NIO，AIO的概念，含义和背后的那些事。本文主要分为3篇。

• 第一篇 讲解BIO和NIO以及IO多路复用
• 第二篇 讲解磁盘IO和AIO
• 第三篇 讲解在这些机制上的一些应用的实现方式，比如nginx，nodejs，Java NIO等

磁盘IO

磁盘IO，简单来说就是读取硬盘一类设备的IO。这类设备包括传统的磁盘、SSD、闪存、CD等。操作系统将其统一抽象为”块设备“。所以磁盘IO又可以叫做”块IO“。这些设备上的数据一般用文件系统来组织，所以又可以成为”文件IO“。本文统一用”磁盘IO“这个术语。

簇（sector）和块（block）

对于磁盘的驱动来说，存在一个最小的操作单位。这个单位被称为“簇”（sector）。对磁盘的操作不可以小于这个单位，比如整簇读取/整簇写入。比如硬盘的簇很多都是512Byte，而CD上的簇是2KB。

对于Linux来说，虚拟文件系统（VFS）抽象了磁盘设备，统一称为“块设备”（block device）。数据是按照一块块来组织的。操作系统可以随机的定位到某个“块”，读写某个“块”。

很不巧，“阻塞”和“块”的英文单词都是“block”，请读者留意区分。

块到簇的转换，是由设备驱动来完成的。一个“块”的大小必须大于等于一个“簇”。并且块的大小必须是簇的整倍数（否则转换起来就太麻烦了）。块的大小一般有512Byte，1KB，2KB等。

在VFS上层的应用是感受不到“簇”的，他们只能感受到“块”。同时，对于操作系统在驱动程序之上的层次来说，访问磁盘数据的最小单位是“块”。即，即使你只想读取1个Byte，磁盘也至少要读取1个块；要写入1个Byte，磁盘也至少要写入一个块。

这里简单介绍“簇”和“块”，是因为读写磁盘数据要求“块”对齐。下文中会提到。

Page Cache

在虚拟文件系统层之上，是内存。这一层被称为Page Cache。详见下图。

这个层次是用页面（Page）来组织的。一般来讲一个页面是4KB，一个页面对应若干个“块”。

Page Cache对于磁盘IO的性能表现极度重要。比如，当通过writeAPI写入数据到磁盘时，数据先会被写入到Page Cache。此时，这个Page被称为“dirty page”。dirty page会最终被写入到磁盘上，这个过程为称之为“写回”（writeback）。写回往往不会立刻发生。写回可能由于调用者直接使用类似于fsync这样的API，也有可能因为操作系统根据某种策略和算法决定自动写回。写回发生之前，如果机器挂了，就有可能丢失数据。这也是为什么有持久性要求的程序都需要用fsync来保证数据落地的原因。

当读取数据时，操作系统会先尝试从Page Cache里找，如果找到了就会直接返回给应用程序。如果找不到，就会触发“页错误”（Page Fault），迫使操作系统去读取磁盘数据，在Page Cache里进行缓存，然后将数据返回给上层应用程序。

Page Cache的基本维护算法是基于“时间局部性”（Temporal Locality)。下面是wiki的解释：

Temporal locality refers to the reuse of specific data, and/or resources, within a relatively small time duration.

用人类语言解释就是假设“被访问的数据在短时间内再次被访问的几率会很大”。具体算法一般就是基于Least Recent Use，LRU——即把最不经常访问的Cache删除掉。

“时间局部性“作为通用规则，可以应付大部分情况。但是凡事总有特殊。比如把一个巨大的文件从头读到尾。此时“时间局部性”肯定是不起作用的（已经读取过的数据反而不需要了）。这时就要用一些定制的手段来定制“如何做Cache”。比如可以预取——预先把即将访问的数据读取到Cache；可以强制一个Page常驻——手工管理一个Page的存活等。这些工作可以由fadvise等api来完成。

大家都知道内存的读写延迟要比磁盘高2～3个数量级。对于磁盘数据，就可以长期的保存在Cache中。这样可以极大的提升磁盘IO读取的效率。

应用程序

Page Cache的上层是应用程序，就是我们平时写的程序了。

磁盘IO的应用程序大概长这样:

char buffer[BUF_SIZE];      /* buffer */
int fd1 = /* ... 打开一个文件并获得fd */
int fd2 = /* ... 打开另一个文件并获得fd */
read (fd1, &buffer, BUF_SIZE); /* 读文件数据到buffer */
/* processing buffer ... */
write (fd2, &buffer, ret_in); /* 将buffer数据写入文件 */
/* 如果需要，可以调用fsync(fd2); 将数据刷到磁盘*/
/* close fd */

在处理IO数据时，应用程序总是需要在用户态分配一段内存空间作为buffer，然后将Page Cache中的数据copy出来进行处理。处理完成后，将数据写回（copy回）到Page Cache。

如果你留意这个图，就会发现，这里会多额外两次数据的copy（并且是CPU copy）。但是有两种方法可以避免这两次copy，分别是mmap和sendfile。

mmap

mmap可以将Page Cache中的内核空间内存地址直接映射到用户空间中，于是应用程序可以直接对Page Cache中的数据进行读写操作。

mmap的一个巨大好处是可以让开发人员像是访问常规变量那样随机访问文件中的数据。如果不用mmap，开发人员就得自己用lseek去频繁定位文件的位置。这样一来是非常麻烦，代码写的会相当臃肿啰嗦；二是lseek也是系统调用，频繁使用的话会造成大量上下文切换，带来性能上的无谓损耗。

现实当中，mmap有相当花样的玩法，可以实现多进程数据共享和通讯，实现跨进程锁等。但这些功能不是本文的重点就不展开了。

sendfile

sendfile可以直接将Page Cache中某个fd的一部分数据传递给另外一个fd，而不用经过到应用层的两次copy。值得注意的是，sendfile的原始fd必须是一个磁盘文件对应的fd；而其目标fd可以是磁盘文件，也可以是socket。当为socket时，sendfile就非常高效的实现了一个功能——通过网络serving文件。一般称这种实现为“Zero Copy”。

其实这里还是会copy，只不过只有DMA copy，没有CPU copy，不浪费CPU

上图是一个使用sendfile将一个文件直接发到网络的示意图。调用sendfile使得文件数据进入到Page Cache，然后让网卡直接从Page Cache中获取数据发送给网络。期间不出现任何CPU Copy。如果调用sendfile时，数据已经在Page Cache了，就会被直接使用。
但是sendfile也有一个严重的缺点。因为数据是两个fd在内核直接传输的，所以无法做任何修改。你只能原封不动的传输原始的数据文件。一旦你想在数据上做一些额外的加工，就无法使用sendfile。比如磁盘上存储的是原始的文件，而你想压缩文件后再传输给socket，就必须放弃sendfile，老老实实的把文件读到用户态buffer，然后做压缩处理，再写回到内核态的socket buffer。

Direct IO

上面介绍的是用了Page Cache的IO一般被称为Buffered IO。之所以不叫Cached IO，是因为早年Linux的磁盘iOS设计中在Page Cache 里还有一个内部的”内核buffer“。在Linux 2.6之后，这个设计被统一到了只使用Page。然而，Buffered IO的名字被保留了下来。

与Buffered IO相对的，是Direct IO。即应用程序直接读写块设备，不再经过Page Cache。

要使用这种IO，只要在打开文件时，增加一个O_DIRECT标记。

int fd = open("path/to/the/file", O_DIRECT | O_RDWR);

相比“Buffered IO”，Direct IO必然会带来性能上的降低。所以Direct IO有特定的应用场景。比如，在数据库的实现中，为了保证数据持久，写入新数据到WAL（Write Ahead Log）必须直接写入到磁盘，不能等待。这里用Direct IO来实现WAL就非常理想。

使用Direct IO的另外一种场景是，应用程序对磁盘数据缓存有特别定制的需要，而常规的Page Cache的各种策略并不能满足这种需要。于是开发人员可以自己设计和实现一套“Cache”，配合Direct IO。毕竟最熟悉数据访问场景的，是应用程序自己的需求。

然而，Direct IO有一个很大的问题是要求如果是写入到磁盘，开发者必须自行保证“块对齐”。即write时给的buffer的offset和size要刚好与VFS中的“块”对应，不然就会得到EINVAL错误。如果用了“Buffered IO”，Page Cache内部就可以自动搞定对齐这件事情了。没有Page Cache，对齐要就得自己做。比如，需要手工调用posix_memalign分配块对齐的内存地址。

磁盘IO的优化

除非用Direct IO，对于磁盘IO的优化主要在读取操作上。这是因为写入时总是写到Page Cache，而写内存比写磁盘要高效的多。从业务上讲，一般来讲上传文件的请求量要远远小于获取文件（图片、html、js、css……），所以在Web场景下，对磁盘IO的优化的主要思路其实很简单——尽量保证要读取的文件在内存里，而不是取磁盘上读取。如果数据已经到了Page Cache，你可以

• 选择用read将其从Page Cache读取到应用程序的buffer，然后做后续处理。
• 选择用sendfile直接将数据复制到另外一个fd里（另外一个文件或者socket）
• 选择用mmap直接读写操作

但如果数据没有到Page Cache，read可能就会“卡”一下（虽然操作系统并不认为这是阻塞）。对于高性能服务，这可能是无法接受的的。我们需要一种不会“卡”当前线程的磁盘数据读取方式。

正如第一篇文章所说，在Linux中，磁盘IO不支持NON_BLOCKING模式。但是Linux提供了磁盘的异步IO接口（Asynchronous IO，AIO）。

AIO

Linux中有两套“AIO”接口。这两套接口都只支持磁盘IO，不支持网络IO。

POSIX AIO

第一套被称作POSIX AIO。顾名思义，这套接口是POSIX标准规定的。这套AIO的接口的定义可以参考这里。其大致的使用方式是：

1. POSIX AIO用信号（signal）来通知进程IO完成了。所以要先注册一个IO完成时对应的信号的handler。
2. 用aio_read或者aio_write来发起要读/写的操作。这个接口会立刻返回。
3. IO完成后，信号被触发，相应的handler会执行。
4. 你也可以选择不使用信号，而主动调用aio_suspend来主动等待IO的完成，就像第一篇文章中的select那样。

POSIX AIO还支持用线程来做通知，但这需要额外处理线程协作的问题。

这套接口没有得到广泛的使用，原因是其有很大的局限性——这套接口并不能算是"真・AIO"。这套接口是完全在用户态实现的（libc），完全没有深入到操作系统内核中。

此外，用信号做AIO的触发在工程中有很多问题。信号是一个“数字”，而且是全局有效的。所以比如你用POSIX AIO实现了一个lib，选用数字M做信号；但是你无法阻止其他人用POSIX AIO实现另外一个lib，也选用数字M做信号。这样如果一个程序同时用了两套lib，就会彼此干扰。POSIX AIO无法实现类似于epoll中可以创建多个epoll fd，彼此隔离的使用方式。

如果用aio_suspend，就不满足使用AIO的最初目标。你还是得让程序主动“等”一下。并且aio_suspend并不支持eventfd（下文会讲到为什么eventfd很重要）。

此外POSIX AIO因为是POSIX指定的标准，所以其存在的一个重要意义是不同操作系统的实现要一致，便于跨平台使用。但实际上各个操作系统对此标准实现的相当不一致（尤其是MacOS），所以这个标准实际上没有什么用处。可以参考这篇吐槽。

所以，对于POSIX AIO大家看看就好。Linux下实际使用比较多的是Linux AIO。

Linux AIO

Linux中的另外一套AIO接口被称为Linux AIO，是Linux在内核实现的一套AIO接口。这套是"真・AIO"。接口的详细用法可以参考这里。我这里给出一个极度精简版的例子，里面所有的错误处理都被我忽略了，只是想体现一下Linux AIO的使用方式：

aio_context_t ctx;
struct iocb cb;
struct iocb *cbs[1];
char data[4096];
struct io_event events[1];
int ret;
int fd = /* 打开一个文件，获得fd */;
ctx = 0;ret = io_setup(128, &ctx); // 初始化一个同时处理最大128个fd的aio ctx/* 初始化 IO control block */
memset(&cb, 0, sizeof(cb));
cb.aio_fildes = fd;
cb.aio_lio_opcode = IOCB_CMD_PWRITE; // 设置要“写入”
cb.aio_buf = (uint64_t)data; // aio用的buffer
cb.aio_offset = 0; // aio要写入的offset
cb.aio_nbytes = 4096; // aio要写入的字节个数cbs[0] = &cb;
ret = io_submit(ctx, 1, cbs); // 提交io进行异步处理/* 等待aio完成 */
ret = io_getevents(ctx, 1, 1, events, NULL);
/* 对events进行处理 */
io_destroy(ctx);

大意是：

• 使用io_setup创建一个AIO的上下文aio_context_t（就像epoll会有一个fd）
• 初始化iocb结构体（io control block），每一个要进行AIO的操作都要一个对应的iocb数据
• 用io_submit将iocb提交（支持提交多个）。接口会立刻返回。然后，你的程序就可以做其他事情了。
• 希望处理IO事件时，调用io_getevents。该接口会阻塞。如果IO事件完成了，就能拿到events，于是可以后续处理数据了。
• 最终调用io_destroy把ctx清理掉。

这套接口在Linux内核中实现，看上去靠谱多了。但是这套接口有三个比较令人郁闷的问题。

第一个问题是，它只支持Direct IO的IO操作。也许这套接口是专门给数据库领域专门定制的（更多的人会吐槽这个接口的作者脑筋有问题）。尽管Linux社区有很多争论和提案（比如这里）。但是现状就是只有Direct IO被支持。这就意味着，选择使用了Linux AIO就无法享受Page Cache带来的好处；此外，只要使用Linux AIO，就意味着必须自己做块对齐（见上文Direct IO的介绍）。

BSD系统的AIO接口是支持buffered IO的

第二个问题是，这套接口支持的功能有限，比如对于fsync，stat等API，压根就不能真的做到异步。此外Linux AIO对一些特定的文件系统支持不好（比如ext4，在这种操作系统上调用io_submit，还是会“卡”）。

第三个问题是io_getevents，它和epoll一起使用会让程序有两个阻塞点。这样程序就没法写了。Linux提供了eventfd解决这个问题。

使用eventfd协调epoll和Linux AIO

如果在Linux下编写一个高性能文件服务器，就需要同时用到epoll和Linux AIO。但是epoll_wait和io_getevents就会引入两个阻塞点，这样，等待文件IO的时候，网络请求就会被延迟。这可不是我们希望的。

eventfd可以帮助把两个阻塞点二合为一。eventfd，顾名思义，就是表达事件的fd。它的本意是利用fd来简化跨进程的通讯——比如AB两个进程共享同一个eventfd，A进程对eventfd写入，B进程就能感知到。当然，eventfd也能在同一个进程里用。eventfd能协调epoll和Linux AIO是因为：

• epoll支持监听eventfd，并且
• Linux AIO中被提交的events如果完成，就会触发eventfd，于是监听该eventfd的epoll就能察觉到

这样对于同时使用eventfd和Linux AIO的程序就可以把阻塞点统一到epoll_wait上。下面是一个例子（我依然忽略所有错误处理，尽量简化）：

int efd, fd, epfd;
io_context_t ctx;
struct timespec tms;
struct io_event events[NUM_EVENTS];
struct iocb iocbs[NUM_EVENTS];
struct iocb *iocb;int i, j, r;
void *buf;
struct epoll_event epevent;efd = eventfd(0, EFD_NONBLOCK | EFD_CLOEXEC); // 使用“eventfd”系统调用创建一个eventfd实例fd = open(TEST_FILE, O_RDWR | O_CREAT | O_DIRECT, 0644); // 打开一个要真实操作的文件ctx = 0;
io_setup(128, &ctx)；
posix_memalign(&buf, 512, 1024); // 对齐bufferfor (i = 0, iocb = iocbs; i < NUM_EVENTS; ++i, ++iocb) {io_prep_pread(&iocb, fd, buf, RD_WR_SIZE, i * RD_WR_SIZE);io_set_eventfd(&iocb, efd); // 对于这个AIO注册eventfdio_set_callback(&iocb, aio_callback); // 假设有这么个回调函数
}io_submit(ctx, NUM_EVENTS, iocbps); // 提交所有的iocbepfd = epoll_create(1); // 创建epoll fd
epevent.events = EPOLLIN | EPOLLET;
epevent.data.ptr = NULL;
epoll_ctl(epfd, EPOLL_CTL_ADD, efd, &epevent); // 让epoll监听eventfdi = 0;
while (i < NUM_EVENTS) {uint64_t finished_aio;epoll_wait(epfd, &epevent, 1, -1); // epoll阻塞，开始等待/* epoll_wait 返回了，说明eventfd有事发生了 */read(efd, &finished_aio, sizeof(finished_aio)); // eventfd的值是这次AIO完成事件的个数printf("已经完成的IO个数: %"PRIu64"\n", finished_aio);while (finished_aio > 0) {tms.tv_sec = 0;tms.tv_nsec = 0;/* 既然AIO已经完事了，调用io_gevents就会立刻返回了，不会阻塞 */r = io_getevents(ctx, 1, NUM_EVENTS, events, &tms); if (r > 0) {// 处理AIO的事件i += r;finished_aio -= r;}}
}

上面的例子首先创建了一个eventfd，并且挂到了AIO上下文中。然后epoll_wait监听这个eventfd。在现实中，epoll可以同时监听此eventfd和所有其他socket的fd。一旦IO完成，eventfd被触发，epoll_wait返回。程序就可以调用io_getevents，这时铁定是不会阻塞的，所以可以立刻拿到返回的事件，并作处理。

反思AIO

上面讨论了这么多操作系统接口层面上的AIO，有很多细节和不完善的。但是，AIO在概念上却很简单，意思是通过一个回调处理数据。比如在nodejs中，读取文件的用法可以非常清晰的反映出什么才是AIO。

const fs = require('fs'); // 引入fs这个包
fs.read('/path/to/file', function(data) {// 处理文件的数据console.log('文件数据处理完成');
});
console.log('开始读取文件');

程序员可以指定要读取一个文件，并且指定当读取完成后要处理的函数。这个指定立刻执行，不会等待文件的读取。这个模式可以清晰的反映出我们脑海中那个理想的AIO的样子。

但是现实是很悲催的，因为操作系统层面的AIO没法变成理想中的样子。

• 操作系统的AIO接口只支持文件操作。对于网络，需要用epoll这样的IO多路复用技术。如果要统一网络和磁盘IO都可以AIO就必须在上层进行封装，屏蔽掉操作系统这么不一致的细节（比如libuv就是这么干的）。
• 由于系统调用并不只直接支持”回调”（“信号”在工程上难以应用于IO回调这个场景，不算数），程序员需要自行使用io_getevents这样的API来主动等事件。在操作系统层面上，能做的最舒服的就是统一用epoll_wait做这个“等事件”的核心。这时需要借助eventfd。POSIX AIO并不支持eventfd，所以虽然有这么套接口，但是一般没机会用。
• Linux AIO只支持Direct IO，所以无法利用Page Cache。所以现实当中，用不用是要做取舍的（nginx有一个选项aio就是配置这个功能的，见这里)。
• Linux AIO不能100%实现所有文件操作api都能“异步”。

所以在操作系统上这个级别上，AIO非常的“别扭”。

基于以上的这些问题，一般上层（nodejs，Java NIO）都会选择用线程池+BIO来模拟文件AIO。好处是：

• BIO这一套接口非常完备，文件IO除了read，write，还有stat，fsync，rename等接口在现实中也是经常需要”异步“的；
• 编程容易。看看上面的例子，是不是非常容易晕。而这些已经是非常简化的例子了，现实中的代码要处理相当多的细节；
• 不用在AIO和Buffered IO中做取舍。BIO天然可以利用Page Cache来提高性能；
• 容易跨平台。不同操作系统的线程实现和BIO的实现基本上完备一致，不会像AIO那样细节差异相当巨大。

再下一篇文章中，会介绍上层系统的高性能IO部分是如何使用操作系统API的。