1. 从点外卖看IO模型底层逻辑：先搞懂同步、异步、阻塞、非阻塞

聊IO模型之前，我强烈建议你先忘掉那些晦涩的术语，我们用一个生活场景把这四个词彻底掰扯清楚——点外卖。

想象你是一个正在写代码的程序员，肚子饿了要吃东西。把“获取食物”当成一次IO操作，“你”就是发起调用的应用程序线程，“外卖小哥”就是操作系统内核或底层IO设备，“食物到达”就是数据就绪的事件。整个过程有两个核心阶段：

**阶段一：发起请求。**你掏出手机下单（发起系统调用），此刻你面临两个选择：下单之后一直盯着手机等外卖小哥敲门，什么都干不了——这是“阻塞”；下单之后继续刷会儿代码，时不时看两眼手机，外卖到了再取——这是“非阻塞”。

**阶段二：数据准备与拷贝。**外卖小哥在路上（内核等待数据就绪），食物送到你家门口（数据从内核缓冲区拷贝到用户空间）。这个阶段同样存在“等”和“不等”的选择。

把这两个阶段组合起来，就是经典的四象限。同步阻塞就是你死等外卖；同步非阻塞是你反复查看手机外卖到哪了，但每次查询都没到，你得接着干活再接着查；异步阻塞其实很少见——相当于你委托平台，到餐了平台会主动推送通知，但在收到通知前你什么都不干；异步非阻塞则是委托平台，到餐通知推送给你，你该干嘛干嘛，收到推送再去拿，全程没有被“等”这件事卡住。

请注意，同步和异步在这里描述的是“由谁来处理就绪事件”，阻塞和非阻塞描述的是“调用方在等待结果时是否被挂起”。这两组概念是正交的，很多人把它们混为一谈，这是理解IO模型的第一道坎。

Java中对应的模型是这样的：BIO是同步阻塞，NIO通常指同步非阻塞加IO多路复用，AIO是异步非阻塞。后面所有内容都围绕这三者展开，先把这个坐标系定住，后面看代码才有底气。

为什么说阻塞反而是最自然的起点？因为人脑天然适应“等待一个确定结果”的模式，你调用socket.accept()，没有连接来就等着，逻辑直观、排错容易、代码从上到下线性执行，没有任何回调。BIO是IO模型的“地基”，把它吃透了，你才能真正理解NIO和AIO到底“解决”了什么。

2. BIO：多线程方案如何从“够用”走向“爆炸”

2.1 经典BIO服务端长什么样

先看一段最基础的服务端代码，这是理解后续所有模型的原点：

public class BioServer { public static void main(String[] args) throws IOException { ServerSocket serverSocket = new ServerSocket(8080); System.out.println("BIO Server started on port 8080"); while (true) { // 阻塞点1：没有客户端连接时，线程卡在这里 Socket socket = serverSocket.accept(); System.out.println("Accept connection from " + socket.getRemoteSocketAddress()); // 每个连接一个线程，阻塞点2：读数据时线程也卡住 new Thread(() -> handleRequest(socket)).start(); } } private static void handleRequest(Socket socket) { try (BufferedReader reader = new BufferedReader( new InputStreamReader(socket.getInputStream())); PrintWriter writer = new PrintWriter(socket.getOutputStream(), true)) { String line; while ((line = reader.readLine()) != null) { System.out.println("Received: " + line); writer.println("Echo: " + line); if ("quit".equalsIgnoreCase(line)) { break; } } } catch (IOException e) { e.printStackTrace(); } finally { try { socket.close(); } catch (IOException e) { e.printStackTrace(); } } } }

代码很短，但你要注意两个关键阻塞点。第一个是accept()，它会一直阻塞到有新的TCP连接完成三次握手；第二个是reader.readLine()，它会一直阻塞到对端真的发来一行数据。这两处阻塞意味着：每来一个连接，服务端就必须分配一个线程去伺候它，这个线程在连接存活期间可能大部分时间都在傻等——等数据、等对端回应。

我早年写过一个简单的聊天室就用这个模型，本地测试三五个连接完全没问题，一放到测试环境模拟几百个并发客户端，机器CPU直接飙到100%，随后就是大量Connection refused。这就是BIO典型的问题：并发量一上来，线程数呈线性增长，而每个线程默认栈大小1MB，操作系统创建一个线程约需几微秒到几十毫秒不等的开销，上下文切换成本更是随着线程数增长急剧放大。

2.2 C10K问题：BIO的死穴到底在哪

C10K全称是“处理一万个并发连接”，这个经典命题最早由Dan Kegel在1999年前后提出，它把BIO的困境暴露得淋漓尽致。

一万个并发连接意味着服务端至少要创建一万个线程。一台普通的服务器，操作系统默认线程数上限通常在几百到几千，即便你把ulimit调大，线程切换带来的CPU消耗也会把系统拖垮。原因在于：一万个线程中，绝大多数都阻塞在等数据上，真正处于可运行状态的少之又少。CPU的时间片却要在这一万个线程之间来回切换，保存和恢复线程上下文本身就是巨大的浪费。

更关键的是，连接越多，“空转”比例越高。一个线程收到请求、解析、响应，真正工作的时间可能只有几毫秒，但它占用的资源（内核线程、栈空间、文件描述符）却是持续存在的。你可以想象一家餐厅，来一个客人就配一个专职服务员，客人用餐期间服务员只能干站着，一旦客流量上来，哪怕把全城服务员都雇来也不够用，而且服务员之间挤来挤去反而更乱。

2.3 伪异步IO：线程池为什么也救不了

后来有人提出改进：既然连接多、线程多，那把“每连接一线程”换成线程池，限制线程数量不就行了吗？这就是所谓的“伪异步IO”，代码大致长这样：

ExecutorService executor = Executors.newFixedThreadPool(20); while (true) { Socket socket = serverSocket.accept(); executor.submit(() -> handleRequest(socket)); }

表面上线程数被限制在了20个，看起来解决了线程爆炸问题。但你要仔细想一下：线程池里一个线程在处理连接A时，如果A一直不发数据，这个线程就阻塞在read()上，池子里其他线程也被其他连接类似地占住。当所有线程都被阻塞时，新的连接只能排队等待，响应延迟急剧拉高，甚至出现连接超时。

线程池解决的是“线程创建销毁的开销”，并没有解决“线程被无效等待占住”的本质问题。只要IO读写是阻塞的，一个线程同一时刻就只能服务一个连接的完整生命周期，线程资源永远和连接数成正比，而不是和真正活跃的连接数成正比。这就是伪异步IO的局限，不少老项目直到现在还在用这种方案，说实话能跑，但天花板非常低。

3. NIO：事件驱动如何改写服务端架构

3.1 Channel、Buffer、Selector三件套的角色分工

NIO（New IO，也叫Non-blocking IO）引入了一套全新的抽象：Channel（通道）、Buffer（缓冲区）、Selector（选择器）。我第一次接触的时候觉得这三个名字太抽象，后来用一句话就记住它们的关系：Buffer是装卸货物的仓库，Channel是连接两地的传送带，Selector是调度员，它决定哪条传送带上的货物能卸了。

Channel和传统Stream最大的区别在于双向性。流只能单向读或者单向写，Channel可以同时读写；流是阻塞的，Channel可以设为非阻塞模式。你可以把Channel理解为一张“随时可以查看状态”的传送带，数据在它上面流动，但你不必死盯着它。

Buffer就是缓冲区本身，在NIO里所有读写操作都必须经过Buffer——读是把Channel里的数据装进Buffer，写是把Buffer里的数据推到Channel上。Buffer内部有position、limit、capacity三个核心指针，flip()和clear()这两个方法的语义我后面会在代码里演示，现在先说结论：NIO的数据操作是面向缓冲区的，这意味着你可以一次读一批数据，而不是像流一样一个字节一个字节地挤。

Selector是整个NIO的调度中心。它做的事情很简单：你把自己感兴趣的Channel注册给它，告诉它“这个通道我想读数据”“那个通道我想写数据”，然后调用select()。这个调用会阻塞（注意，这里又有阻塞，但阻塞的是Selector线程，而不是每个连接一个线程），直到至少有一个Channel变得可读或可写，它返回就绪集合，你逐个处理即可。

3.2 一个完整NIO服务端的源码实现

下面这个例子是我在本地反复验证过的，没有依赖任何第三方框架，纯JDK实现，你可以直接跑：

public class NioServer { public static void main(String[] args) throws IOException { // 1. 打开ServerSocketChannel，并设置为非阻塞 ServerSocketChannel serverChannel = ServerSocketChannel.open(); serverChannel.configureBlocking(false); serverChannel.bind(new InetSocketAddress(8080)); // 2. 打开Selector，并把serverChannel注册到selector上，关注OP_ACCEPT Selector selector = Selector.open(); serverChannel.register(selector, SelectionKey.OP_ACCEPT); System.out.println("NIO Server started on port 8080"); // 3. 为每个连接创建一个对应的Buffer（用HashMap存储，实际情况可以用附件） Map<SocketChannel, ByteBuffer> bufferMap = new HashMap<>(); while (true) { // 4. 核心：阻塞等待至少一个通道就绪 selector.select(); Iterator<SelectionKey> iterator = selector.selectedKeys().iterator(); while (iterator.hasNext()) { SelectionKey key = iterator.next(); iterator.remove(); // 必须手动移除，否则会重复处理 if (key.isAcceptable()) { // 5. 处理新连接 SocketChannel clientChannel = serverChannel.accept(); clientChannel.configureBlocking(false); clientChannel.register(selector, SelectionKey.OP_READ); bufferMap.put(clientChannel, ByteBuffer.allocate(1024)); System.out.println("Accept connection from " + clientChannel.getRemoteAddress()); } else if (key.isReadable()) { // 6. 处理读事件 SocketChannel clientChannel = (SocketChannel) key.channel(); ByteBuffer buffer = bufferMap.get(clientChannel); buffer.clear(); int readBytes = clientChannel.read(buffer); if (readBytes > 0) { // 手动flip切换到读模式，再写回客户端 buffer.flip(); clientChannel.write(buffer); bufferMap.put(clientChannel, buffer); } else if (readBytes < 0) { // 对端关闭 clientChannel.close(); bufferMap.remove(clientChannel); System.out.println("Connection closed"); } } } } } }

你仔细看这个代码，它和BIO版本有一个本质区别：selector.select()所阻塞的，是整个服务端唯一的调度线程；而真正处理每个连接数据的时候，用的是非阻塞的read()——读不到数据立刻返回0，不会卡死线程。

这里最值得品味的是SelectionKey这个对象。它把channel、selector、感兴趣的操作（OP_ACCEPT/OP_READ/OP_WRITE）以及一个可选的附件对象绑定在一起。当某个事件就绪时，你从selectedKeys里拿到对应的key，就能立刻知道是哪个通道、发生了什么事件，然后精准处理。这相当于调度员给你一份“活干完了的工单列表”，你照着工单干活，不用挨个巡查。

3.3 单线程处理海量连接：真正的原因在select()

很多人第一次看完NIO代码会困惑：怎么就一个线程，它能同时处理成千上万个连接？关键就在selector.select()这个调用背后——它让应用线程只关注“哪些连接有事可做”，而不是盯着连接本身。

打个比方，BIO方案是服务员守在客人桌前，眼睛一刻不离客人嘴巴，等客人说话；NIO方案是服务员站在大厅中央，耳朵听着所有桌子的按铃声，谁按铃就过去处理谁。客人不说话的时候，服务员可以完全闲着，不需要为任何客人“站岗”。这就是事件驱动模型的威力：线程从“为连接服务”变成“为事件服务”，资源消耗不再与连接数成正比，而与就绪事件的频率成正比。

我在压测这个NIO Server时，在一台4核8G的虚拟机上用wrk开了2000个并发连接，CPU占用始终没有超过30%，而同样的机器跑BIO在200连接时就开始力不从心。需要提醒的是，单线程NIO在处理某个Channel的读写时，如果数据量很大，确实会阻塞住其他Channel的处理。所以生产环境里通常用少量线程跑select()循环，比如Netty默认的EventLoop线程数就是CPU核数的两倍，这就是后话了。

4. IO多路复用：NIO与select、poll、epoll的真实关系

4.1 用户态NIO与内核多路复用是怎么配合的

有一件事很多人一开始搞混：Java NIO里的Selector并不是Java自己发明的东西，它是对操作系统提供的IO多路复用机制（select/poll/epoll/kqueue）的封装。换句话说，Selector.select()最终会调用操作系统底层的epoll_wait（Linux）或kqueue（macOS/BSD）。

IO多路复用的核心思想是：**一个线程注册多个文件描述符（fd），内核帮你盯着这堆fd，一旦某个fd上的IO事件就绪，内核通知用户线程来处理。**这样用户线程的调度开销从“每连接一个线程”降成了“无论多少连接都只需要少量线程”。

Java NIO选择器在不同平台上有不同的底层实现：Linux上是epoll，macOS上是kqueue，Windows上是IOCP的模拟封装。所以你会发现同样的NIO代码，在不同操作系统上表现的细节略有差异，比如Windows下选择器默认是水平触发，而Linux的epoll默认也是水平触发，但支持边缘触发模式。

4.2 select和poll的线性扫描困境

在epoll出现之前，select和poll是多路复用的主力。它们的机制说起来很简单：你告诉内核“我关心这些fd”，内核遍历一遍这些fd，检查哪些已经就绪，然后返回就绪列表。

问题在于，每次调用select()，用户空间都要把整个fd集合拷贝到内核空间，内核再线性扫描整个集合，扫描完再整体拷贝回用户空间。fd数量少的时候没问题，一旦fd数量上万，每次调用的拷贝和扫描成本就非常可观。而且select还有一个著名的限制：单一进程能监控的fd数量上限通常是1024（FD_SETSIZE），虽然可以改编译参数，但治标不治本。

poll相比select的改进是去掉了1024上限，基于链表存fd，但依然是线性扫描——每次调用仍然要遍历所有注册的fd，哪怕其中只有1个就绪。

用一个生活化场景帮助记忆：select和poll就像保安每个月挨家挨户敲门问“你家来客人了吗”，不管有没有客人，每家每户都被问到，门敲得多了，小区一大，成本自然爆炸。

4.3 epoll事件驱动：就绪队列与回调机制

epoll从根子上改变了这个逻辑。它在内核里维护了一个事件表（用红黑树存储注册的fd），当某个fd上的IO事件发生时，内核驱动程序会主动通过回调机制把这个fd加入一个就绪链表，用户线程调用epoll_wait()时，只需要从就绪链表里摘取事件即可。换句话说，epoll是“有事件才通知”，select/poll是“无差别轮询”，一个主动，一个被动。

epoll有三个关键方法：

• epoll_create：在内核创建事件表，返回一个fd句柄
• epoll_ctl：把要监控的fd注册进事件表，可以添加、修改、删除
• epoll_wait：等待事件就绪，返回就绪fd集合

对应到Java NIO的源码层面，EPollSelectorImpl内部就是这三个系统调用的封装，Selector.open()对应epoll_create，SelectionKey的注册对应epoll_ctl，selector.select()对应epoll_wait。你可以用strace命令去跟踪一个NIO服务的系统调用，会看到epoll_ctl和epoll_wait交替出现，非常直观。

n个连接只有1个活跃时，epoll只需要处理那1个就绪事件，时间复杂度是O(1)级别；而select/poll无论如何都要扫描全部n个fd。这就是为什么高并发场景下，Linux上几乎清一色选择epoll。

4.4 边缘触发与水平触发：最容易忽略的坑

epoll还提供两种触发模式，这是很多人容易栽跟头的地方。

水平触发（LT）是默认模式，也是Java NIO实际使用的模式：只要fd上还有数据没读完，每次调用epoll_wait都会把该fd返回给你。好处是代码不容易漏读，坏处是你可能反复收到同一个事件的提醒；边缘触发（ET）只在fd状态发生变化的那一刻通知一次，比如缓冲区从“无数据”变成“有数据”，你收到一次通知后必须把数据一次性读完，否则剩下的数据可能要等到下一次状态变化才会通知你（而TCP流式数据往往不会再有新的状态变化，数据就卡在那里）。

我在C语言里用epoll写过边缘触发的高并发代理，踩过最大的坑就是read()读取不干净导致数据残留，后来不得不改成循环调用read()直到返回EAGAIN才罢休。Java平台封装的主要是水平触发，所以业务代码层面基本不用关心这个问题，但如果你到Go的runtime源码或者Netty的EpollTransport源码里去翻，会发现边缘触发在底层实现中经常被用到，因为它能减少系统调用次数，性能更好，代价是编程复杂度更高。

**这里有一个重要结论：Java NIO并不等于epoll，它是epoll之上的一个包装，而且默认走的是水平触发路线。**很多面试题问“NIO和epoll什么关系”，其实它们不在一个抽象层上，NIO是用户态的多路复用框架，epoll是内核态的IO事件通知机制，搞清这个层次关系，理解IO模型就不会再混淆了。

5. AIO：为什么说Proactor模式在Java里是个“半成品”

5.1 异步IO的服务端代码长什么样

AIO（Asynchronous IO，异步非阻塞IO）也叫NIO.2，JDK 1.7引入。它的核心特点是：你发起一个读或写操作，立刻返回，等操作真正完成时，系统通过回调或者Future通知你。整个过程调用方完全没有阻塞。

用Java的AsynchronousServerSocketChannel写一个服务端，看起来是这样的：

public class AioServer { public static void main(String[] args) throws IOException { AsynchronousServerSocketChannel serverChannel = AsynchronousServerSocketChannel.open().bind(new InetSocketAddress(8080)); System.out.println("AIO Server started on port 8080"); // 1. 第一个accept调用，传入CompletionHandler serverChannel.accept(null, new CompletionHandler<AsynchronousSocketChannel, Object>() { @Override public void completed(AsynchronousSocketChannel client, Object attachment) { // 2. 递归调用accept，继续接受下一个连接 serverChannel.accept(null, this); // 3. 分配缓冲区，发起异步读 ByteBuffer buffer = ByteBuffer.allocate(1024); client.read(buffer, null, new CompletionHandler<Integer, Object>() { @Override public void completed(Integer result, Object attachment) { if (result > 0) { buffer.flip(); // 异步写回客户端 client.write(buffer, null, new CompletionHandler<Integer, Object>() { @Override public void completed(Integer result, Object attachment) { buffer.clear(); } @Override public void failed(Throwable exc, Object attachment) { exc.printStackTrace(); } }); } } @Override public void failed(Throwable exc, Object attachment) { exc.printStackTrace(); } }); } @Override public void failed(Throwable exc, Object attachment) { exc.printStackTrace(); } }); // 主线程不能退出，这里用一个CountDownLatch挂住 new CountDownLatch(1).await(); } }

这段代码从风格上就能看出和BIO、NIO完全不同。accept和read都带一个CompletionHandler回调，操作发起后立即返回，底层的工作线程负责IO执行，完成后自动回调你定义的方法。

AIO背后的设计模式叫Proactor：主动事件分发器。你告诉系统“帮我做一次异步读，做完了告诉我结果”，系统全程代办，数据都拷贝到你的Buffer里了才通知你。对比NIO的Reactor模式——系统只告诉你“可以读了”，实际读还是你要自己动手。一个是“做完再喊你”，一个是“能做才喊你”，这是Reactor和Proactor的本质差别。

5.2 Linux平台上的AIO真相：底层还是epoll

AIO看起来很美，但在Linux平台上，Java的AIO实现并没有真正使用Linux内核的native AIO接口（io_uring或libaio），而是依然基于epoll模拟出来的异步。什么意思呢？它内部仍然是一个事件循环线程池，用epoll等就绪事件，事件就绪后再把IO操作交给工作线程执行，完成回调再触发你的CompletionHandler。也就是说，Linux上的Java AIO本质是“用线程池+epoll模拟了Proactor”，并不是操作系统的真正异步IO。

真正意义上的native AIO，是指通过io_uring这样的内核接口发起IO请求后，内核在执行IO的同时，用户线程可以完全释放去做别的事，IO完成后通过完成队列通知。这个概念在Java里目前还没有成熟的官方支持（Netty倒是提供了一些底层能力，但也需要JNI或第三方库）。所以当你听到“AIO性能更强”这种说法时，一定要问一句：在哪个平台？怎么实现的？Linux下Java AIO相比NIO并没有代差级优势，反而因为线程调度和回调机制的额外开销，某些场景下性能甚至不如精心调优的NIO。

Windows平台则不同，Java AIO底层真正使用了IOCP（IO Completion Ports），这是Windows自带的原生异步IO模型，由系统完成IO操作并通过完成端口通知。所以一个很有意思的结论是：**AIO在Windows上才是“血统纯正”的异步IO，在Linux上更像是“换了个壳的NIO”。**如果你在Linux上部署应用，选择AIO没有太大必要；如果你在Windows上有高并发IO需求，AIO反而值得一试。

5.3 回调地狱与异常处理：AIO难用的原因

真正让我对AIO“劝退”的，是代码复杂度的急剧上升。你对比一下BIO的线性代码和AIO的回调嵌套——一个简单的“收数据、回写数据”动作，BIO只有几行，AIO要写两层回调，每个回调还要分别处理completed和failed，如果业务逻辑再叠加超时处理、半包粘包、断线重连，嵌套深度会非常恐怖。

这种写法在工程上俗称“回调地狱”。出错时异常堆栈的追踪也变得困难，因为IO操作早就返回了，真正报错发生在回调线程里，线程上下文已经切换了好几次，你很难直观地看到是哪个环节出了问题。另一个麻烦是资源释放：阻塞IO可以用try-with-resources优雅关闭，AIO的异步操作可能在主流程走到close()时还没有完成，必须自己在回调里保证释放逻辑，稍不留神就连接泄漏。

我在一个内部工具里试过AIO做简单的文件异步读写，功能是能跑通的，但调试数据的流向极其痛苦，打的日志往往因为线程顺序问题乱序。后来项目上线时，我还是换回了Netty——不是因为AIO不正确，而是因为它需要投入的工程成本太高，而收益在Linux上又不明显。

6. 源码级对比与工程选型：从BIO到AIO，最终该用谁

6.1 五种模型的核心维度对比表

把前面讲的内容压缩成一张表，方便你面试或者项目选型时快速对照：

一个很重要的经验：模型之间不是简单的新旧替代关系。有些老项目用BIO跑得好好的，没必要为了“新”而迁移；反之，如果你的服务面对的是长连接、高并发、低延迟需求，BIO的天花板在那里，躲不掉的。选型的关键是看你的连接模型和活跃度：连接数小于几百，BIO完全够用；连接数上万但活跃比例低，NIO/多路复用是绝对主力；连接数和活跃度都极高，且对CPU利用率极致敏感，才需要考虑async IO，并且要评估平台支持度。

6.2 什么时候该用AIO，什么时候该用Netty

现在的Java后端写网络服务，几乎没人直接裸写NIO的Selector循环了，大家普遍直接用Netty。Netty是什么？它本质上是一个基于NIO的封装框架，但做了大量优化：内存池化、零拷贝、无锁串行化、背压处理、自定义编解码器等等。你要自己用NIO实现Netty的可靠性和易用性，工程量至少以月计。

回到AIO的话题。在Linux下，我不建议你把核心服务架构在Java的AIO上，理由前面讲了：底层是epoll模拟，没有质变，回调与线程切换的额外开销倒是不小。在Windows下，如果项目确实需要高并发IO，AIO基于IOCP是有实际价值的，但考虑到Java生态里Windows服务器占比偏低，大部分团队也不会把它作为主要方向。

如果你纯粹想研究异步IO的完整语义，或者做一些文件IO的异步处理（比如日志异步落盘），Java AIO倒是可以玩一玩。但如果你是做网络服务端，我的建议非常直接：NIO + Netty，是把“正确性”和“性能”平衡得最好的方案，没有之一。市面上那些号称百万级并发的Java服务端，绝大多数底层跑的就是Netty，不是AIO。

6.3 从面试到实战：IO模型到底应该怎么学

聊聊我自己的经验。很多初学者学IO模型最大的问题是“背了名词但缺乏图像”。你想真正吃透这个主题，我给你一套经过验证的学习路径：

第一步，把今天这篇文章里BIO、NIO的两个Server代码自己敲一遍跑起来，用jstack看看线程状态，观察多少线程处于BLOCKED或WAITING，这能帮你建立“阻塞”的直观感受。

第二步，用strace -ff -p <pid>跟踪NIO进程的系统调用，看到epoll_wait被阻塞、epoll_ctl注册事件这些底层细节后，你对“NIO封装了epoll”这句话才有真正的体感。

第三步，读Netty源码里NioEventLoop的run()方法，看它如何循环处理select()、processSelectedKeys()、runAllTasks()，你会发现它本质上就是为“事件循环”而生的精心打磨版。

第四步，如果你想深入AIO，可以去看sun.nio.ch包下的WindowsAsynchronousChannelProvider和LinuxAsynchronousChannelProvider实现差异。前者基于IOCP，后者用epoll模拟，这个源码级差异你看一眼就会明白Linux下AIO“有名无实”的真正原因。

我个人在实际项目里的体会是：IO模型这块知识，面试时能画出四个象限、讲清BIO到AIO的演化逻辑，基本就能超过大多数人；真正拉开差距的，是你能不能在项目里遇到连接瓶颈时，快速判断出问题出在线程模型还是IO模型，并且有底气给出切换方案。这些能力没有捷径，只有把底层机制玩明白了，遇到线上故障才不会被表象带偏。