深度思考Netty面经(涉及到同步/异步IO，阻塞/非阻塞，I/O多路复用，reactor，零拷贝之间的关系)

基础

1 什么是零拷贝

2 如何深刻理解Reactor和Proactor？

3 同步/异步，阻塞和非阻塞：完全理解同步/异步与阻塞/非阻塞

4 I/O多路复用相关：I/O多路复用

因为Netty作为一种高性能网络编程框架，结合了以上几个高性能的技术，非常建议把以上几篇文章看完了，再看这下面这篇文章。

5 Netty面试全解

1 零拷贝相关

1.1 文中提到的磁盘高速缓存（pageCache）位于内存中嘛还是磁盘中还是寄存器中？

磁盘高速缓存，也就是PageCache，位于计算机的内存（RAM）中。它是内核的一部分，用于缓存从磁盘读取的数据，以提高后续对相同数据的读取速度。当数据被读取时，它首先检查PageCache是否已经缓存了这些数据。如果是，数据可以直接从内存中读取，这比从磁盘读取快得多。如果不是，数据将从磁盘读取，并缓存在PageCache中以备后续使用

1.2 为什么无法使用pageCache就无法实现传统的零拷贝技术？

首先我们要弄什么是零拷贝：指的是数据只在内核态空间流动，不经过用户空间，不涉及内核到用户态的改变。
如果不能使用PageCache（例如在使用直接I/O时），传统意义上的零拷贝技术可能就无法使用。这是因为这些技术需要只在内核空间中进行数据传输，而不是在用户空间（这里的内核空间就是pageCache）。但这并不意味着在这种情况下就完全不能使用零拷贝。例如，一些高性能的网络设备支持DMA引擎，可以直接将数据从磁盘传输到网络，这也可以被看作是一种零拷贝技术。

1.3 是因为直接I/O时，用户进程直接从磁盘拷贝数据到用户态空间嘛？

是的，直接I/O（Direct I/O）或称为"裸I/O"，它使得应用程序可以直接从磁盘中读取数据，跳过操作系统的内核缓冲区（如PageCache）。在这个过程中，数据从磁盘直接拷贝到用户空间的缓冲区，避免了数据在内核空间和用户空间之间的额外复制。这样可以减少CPU的使用，节省内存，尤其对于大数据量的I/O操作有益。

1.4 像瞬时高并发传输小文件的场景下，应该使用零拷贝技术，跟java的线程池的CachedThreadPool的应用场景-大量生命周期短的任务很像

是的，你的理解是正确的。零拷贝技术适用于需要频繁读取小文件的场景(其实也是相当于生命周期短的I/O)，它通过减少数据拷贝来提高数据传输效率。这与Java的CachedThreadPool的使用场景类似，CachedThreadPool也适用于处理大量生命周期短的任务，通过重用已有线程，减少了线程创建和销毁的开销。两者都是为了针对不同的生命周期短的场景中提出的技术方案，只不过前者是内存拷贝，后者是线程执行。

1.5 零拷贝和异步/直接I/O

1 linux2.1+版本的sendfile方法使用零拷贝技术是基于BIO的嘛
2 零拷贝技术和异步IO的区别，异步IO还是需要4次拷贝，4次上下文切换吗？
3 直接IO和异步IO呢？

1. sendfile方法在Linux 2.1及更高版本中确实实现了零拷贝技术，但这并不是基于BIO（Blocking I/O）的。sendfile通过在内核空间直接将数据从一个文件描述符传输到另一个文件描述符，避免了用户空间的数据拷贝，从而实现零拷贝。实际上，sendfile可以用在BIO、NIO（非阻塞I/O）和AIO（异步I/O）等多种I/O模型中。

2. 零拷贝技术和异步I/O解决的是不同的问题。零拷贝技术旨在减少数据拷贝次数，以减少CPU使用率和提高数据传输性能。而异步I/O主要是通过允许程序在等待数据传输完成时执行其他任务，来提高程序的并发性和效率。在传统的异步I/O中，仍然需要四次数据拷贝和四次上下文切换，即使数据在内核空间内从一个位置移动到另一个位置。然而，有些特定的异步I/O技术，例如Linux的io_uring，通过某些优化可以减少这些拷贝和切换的次数。

3. 直接I/O（Direct I/O）是一种在读取或写入文件时绕过操作系统的缓冲区（如Page Cache）并直接从磁盘读写数据到用户态空间的技术。它通常用于大规模数据传输，如数据库操作，其中缓存的效果可能不大，反而可能占用大量的宝贵内存资源。异步I/O，如前所述，允许程序在等待I/O操作完成时执行其他任务。这两者可以单独使用，也可以结合使用，具体取决于你的应用程序的具体需求。

1.6 直接I/O应该就是一种异步i/o吧

直接I/O和异步I/O是两个不同的概念，虽然它们在某些方面可能会有重叠，但在大多数情况下，它们并不等同。

1. 直接I/O（Direct I/O）：直接I/O是一种数据传输方式，它可以绕过操作系统的缓存（比如Page Cache），直接在硬件（如磁盘）和用户空间的缓冲区之间进行数据传输。这样可以避免数据在用户空间和内核空间之间的多次复制。但是，直接I/O并不意味着这个操作是非阻塞的或者是异步的。也就是说，一个直接I/O操作可能需要应用程序等待其完成。

2. 异步I/O（Asynchronous I/O）：异步I/O是指应用程序可以在发起I/O操作后立即返回，继续执行其他的操作，而不需要等待I/O操作的完成。当I/O操作完成后，应用程序会收到一个通知。这种模式可以提高应用程序的效率，因为它可以在等待I/O操作的同时，进行其他的计算或者处理。

所以，直接I/O并不一定是异步的，而异步I/O也并不一定是直接的。这两者是可以独立存在的，也可以结合起来使用。比如，应用程序可以使用直接I/O来减少数据复制的开销，同时也可以使用异步I/O来提高程序的效率。

1.7 非阻塞I/O肯定不能和直接I/O结合吧

首先，我们需要理解一下阻塞I/O、非阻塞I/O和直接I/O之间的关系和区别：

1. 阻塞I/O和非阻塞I/O主要关注的是I/O操作的等待方式。阻塞I/O在操作没有完成之前，会一直阻塞调用的进程，进程将无法进行其他操作。非阻塞I/O则不会阻塞调用的进程，如果I/O操作未完成，调用会立即返回一个错误，告诉用户现在还不能完成这个操作，所以用户需要反复检查I/O操作是否完成。

2. 直接I/O关注的则是数据的复制方式，直接I/O可以绕过操作系统的缓存（比如Page Cache），直接在硬件（如磁盘）和用户空间的缓冲区之间进行数据传输，避免了数据在用户空间和内核空间之间的多次复制。

可以看出，非阻塞I/O和直接I/O并不冲突，它们处理的是两个不同的问题：非阻塞I/O处理的是操作完成的等待问题，而直接I/O处理的是数据复制的问题。因此，理论上来说，非阻塞I/O和直接I/O是可以结合使用的。

然而，你需要注意的是，这种组合使用的可能性取决于你的操作系统和硬件是否支持。并非所有的操作系统和硬件都支持非阻塞的直接I/O操作。所以，如果你想要实现这种结合使用，你可能需要去查阅相关的文档，以确保你的系统支持这种操作。

这里你讲的异步IO和非阻塞IO很像，它们的区别是？

非阻塞IO和异步IO的主要区别在于如何处理IO操作的完成。在非阻塞IO中，应用程序会不断地询问（也就是polling或轮询）IO操作是否已经完成，这样的操作称为“非阻塞”，因为应用程序在IO操作完成之前可以继续做其他的事情。但是，应用程序仍然需要不断地检查IO操作的状态，这样会消耗一定的CPU资源。

相比之下，异步IO是指应用程序发起IO操作后，就可以立即去做其他的事情，而不需要检查IO操作是否完成。当IO操作完成后，应用程序会收到一个通知（比如一个信号或者一个回调函数被执行），告诉它IO操作已经完成。这样的模型被称为“异步”，因为IO操作的完成是由系统自动通知应用程序的，应用程序不需要主动去检查。

如果sendfile被设置为非阻塞，那么这是一种异步IO嘛？

尽管设置了sendfile为非阻塞，但这并不意味着它就是异步IO。当你设置sendfile为非阻塞时，如果它不能立即发送所有的数据，sendfile将会立即返回已经发送的数据的数量。尽管应用程序在sendfile返回后可以继续做其他的事情，但是，如果想要知道剩余的数据何时可以发送，应用程序仍然需要不断地调用sendfile去检查。所以，这种模式实际上是非阻塞IO，而不是异步IO。

在真正的异步IO模式中，应用程序可以在发起IO操作后，不再关心何时可以发送剩余的数据，因为当这些数据可以发送的时候，它会收到一个通知。这样的模式在Linux中可以通过使用aio（异步IO）接口或者io_uring接口实现。

1.8 sendfile结合SG-DMA技术，拷贝到用户空间的过程由DMA完成，cpu或者用户进程都没有参与，为什么不是一种异步I/O呢？

sendfile结合SG-DMA技术的操作过程是这样的：

1. 磁盘DMA将数据复制到内核空间的PageCache中。
2. 内核将数据从PageCache发送到网络卡，这个过程也可以由DMA完成。

在这个过程中，没有涉及到用户空间，所以减少了数据从内核空间到用户空间的复制操作。然而，这个过程并不是异步的，sendfile函数是有可能阻塞的（取决于应用的场景），也就是说，它会等待所有的数据都从磁盘复制到内核空间，然后再从内核空间发送到网络卡；即使在非阻塞的情况下，OS可能会定期轮询SG-DMA是否完成了IO，这种也不是异步

而异步I/O（Asynchronous I/O）是指应用程序发起一个I/O操作后，不需要等待I/O操作的完成，可以继续执行其他的操作。当I/O操作完成后，应用程序会收到一个通知。这个模式可以提高应用程序的效率，因为它不需要等待I/O操作的完成。

所以，sendfile结合SG-DMA技术虽然减少了数据复制的操作，但是它并不是异步的，因此不能被视为一种异步I/O模式。

为什么可以进行零拷贝？

sendfile可以进行零拷贝是因为它直接在内核空间进行数据的传输，而不需要将数据从内核空间拷贝到用户空间，然后再从用户空间拷贝回内核空间。这种操作模式避免了数据的多次复制，所以被称为零拷贝。

为什么不需要将数据从内核空间（pageCache）拷贝到用户空间?

因为这是用于网络I/O的场景，一般用户进程不会在用户态处理传输的文件，所以就没有必要将数据从内核拷贝到用户进程空间。

举个在netty中的例子，比如在netty的应用场景中，用户的客户端想要请求一张商品图片，这张图片存储在服务端的磁盘中，netty此时就相当于用户进程，此刻它肯定只想着如何将数据尽快传输给用户，而不需要对图片做什么其他处理，所以这个时候就可以避免将数据从pageCache拷贝到用户空间了。

mmap+write结合时涉及到数据映射的过程，这样如果用户需要数据，就可以去pageCache中拷贝吗？

使用mmap和write结合时，数据确实会被映射到内存中（具体是被映射到Page Cache）。用户进程可以通过内存地址直接访问这些数据，不需要再去Page Cache中拷贝。但这并不意味着数据就在用户空间，数据仍然在内核空间，只不过用户进程通过内存映射可以直接访问它。

那sendfile机制中，有没有提供给用户进程使用传输数据的接口？

在sendfile的使用过程中，数据的读取和发送都是在内核空间进行的。虽然用户进程发起了sendfile调用，但实际的数据传输并不会经过用户空间。因此，sendfile并没有提供给用户进程使用传输数据的接口。如果用户进程需要对数据进行处理，那么sendfile可能不是一个好的选择，因为它不提供对数据的访问。在这种情况下，可能需要使用其他的数据传输方法，如read/write或者mmap。

reactor线程模型相关

1，单reactor单进程适用于业务处理速度非常快的场景，和多线程的CachedThreadPool适用于大量短生命周期的任务有什么不同，那不能像redis一样串行化执行吗?

单Reactor单进程和多线程CachedThreadlocal模型的主要区别在于并发模型。在单Reactor单进程模型中，所有的请求都在一个线程中被处理，所以在这种模型中**，业务处理速度非常快的场景是最好的**，因为它避免了线程切换的开销。而在多线程模型中，可以利用多核CPU并行处理多个请求，适用于大量短生命周期的任务。串行化执行虽然简化了编程，但是无法充分利用多核CPU，限制了并发性能。

为什么java多线程模型中的CachedThreadPool不能使用像redis一样的单线程模型？（待定）

答：因为redis是IO密集型应用，也就堆积的IO请求主要存在于IO多路复用器的数据结构上，重点在于IO的迅速响应，这点上单线程模型会适合一些，
但是CachedThreadPool处理任务会堆积在内存中，对于短生命周期的任务，如果使用单线程模型，由于只有一个线程，所以在任何时刻，都只能有一个任务在运行，其他的任务都在等待。如果任务的数量非常多，这会导致大量的任务在等待执行，从而增加了延迟，并可能会导致系统的吞吐量下降。而在多线程模型中，可以同时处理多个任务，提高了系统的并发处理能力，从而可以处理更多的任务，提高了系统的整体吞吐量。

2，redis的性能瓶颈不在CPU，为什么就要应用于单reactor单进程?

Redis选择单Reactor单进程模型主要是因为Redis的主要性能瓶颈在I/O(因为redis的业务处理速度非常快)，而不是CPU。对Redis来说，一个进程就足够快速地处理大部分请求了，多个进程或者线程并不能明显提高其性能，反而可能会带来额外的线程切换和同步的开销。并且，Redis的设计目标是简单高效，单进程模型更加简单，易于开发和维护。

3，redis是IO密集型应用吗? 为什么

是的，Redis是I/O密集型应用。Redis主要用作内存数据库，它需要处理大量的网络I/O操作（一般秒杀场景下缓存作为数据库的前站，会过滤绝大多数流量），此外一般redis用作缓存使用，作为内存数据库，大多与内存读写操作有关，基本很少涉及到cpu的干预。对于Redis来说，**其性能主要受网络I/O和内存I/O的限制，**而不是CPU。因此，我们通常将Redis分类为I/O密集型应用。

4，

Netty相关

自定义协议栈

netty实现udp服务器，那就不使用tcp协议传输了吧

是的，如果你使用Netty来实现UDP服务器，那么你就不再使用TCP协议进行数据传输。UDP（User Datagram Protocol）和TCP（Transmission Control Protocol）是互联网协议（IP）的两种传输协议，它们在网络传输层定义了如何发送和接收数据。二者的主要区别在于，TCP提供了一个面向连接、可靠的字节流服务，而UDP提供的是一个无连接、不可靠的数据报服务。

为什么netty可以实现tcp/udp服务器，然后目的是什么？

Netty提供了对TCP和UDP协议的支持是为了提供更多的选择和灵活性。TCP和UDP各自都有它们的优点和适用场景。例如，如果你需要一个可靠的数据传输服务并且可以接受一定的开销，那么你可能会选择TCP。但是，如果你需要一个低延迟、高效率的服务，并且可以接受数据丢失的风险，那么你可能会选择UDP。Netty支持这两种协议，这意味着你可以根据你的应用的具体需求来选择最适合的协议。

netty允许自定义协议栈，相当于是重新定义了tcp包吗，还是应用层包，应用层协议栈？

当我们说Netty允许自定义协议栈，这里说的是在应用层实现自定义的协议。TCP和UDP协议定义了在网络传输层如何发送和接收数据，但是它们并没有定义如何解释这些数据。这就是应用层协议的作用，它定义了数据的格式和解释的方法。在Netty中，你可以定义自己的应用层协议，这让你可以定制和优化你的数据传输，以满足你的应用的特定需求。

Future、ChannelFuture接口回调

正如前面介绍，在Netty中所有的IO操作都是异步的，不能立刻得知消息是否被正确处理，但是可以过一会等它执行完成或者直接注册一个监听，具体的实现就是通过Future和ChannelFutures，他们可以注册一个监听，当操作执行成功或失败时监听会自动触发注册的监听事件。

这里的”Netty中所有的IO操作都是异步的”，但是IO多路复用不是同步非阻塞的吗

IO操作和IO多路复用是同一件事的两个阶段，IO复用负责非阻塞接收用户请求，IO操作负责依据执行具体的请求。
应该这么理解：IO操作涉及到具体的请求执行过程，会使用到线程执行具体的操作，然后执行完通知reactor的方式是异步的（通过调用回调函数），但是IO多路复用指的是接收网络IO请求的过程，属于同步非阻塞模型，两者是同一个任务的不同阶段。

"Netty中所有的IO操作都是异步的"是指在Netty中，当一个IO操作被调用时，它不会阻塞等待该操作完成，而是立即返回。返回的结果是一个Future，它代表了未来的结果。这种设计可以帮助我们编写非阻塞的代码，从而提高应用程序的性能。

“他们可以注册一个监听，当操作执行成功或失败时监听会自动触发注册的监听事件。”，这里的监听应该是开启一个线程主动轮询吧，还是等待回调呢？

“他们可以注册一个监听，当操作执行成功或失败时监听会自动触发注册的监听事件”，这个设计被称为“观察者模式”。在这个模式中，Future或ChannelFuture扮演着“被观察者”的角色，而注册的监听器则扮演着“观察者”的角色。当IO操作完成（无论成功或失败）时，Future或ChannelFuture会通知它的所有监听器。这个过程不需要额外开启线程去轮询检查IO操作是否完成，因为Netty的IO线程会在操作完成时自动通知所有的监听器，这就是所谓的"回调"。这样做的好处是可以避免不必要的轮询，降低了CPU的使用率，提高了性能。

对于Future、ChannelFuture来说，执行具体的IO操作时，使用了异步非阻塞？

是的，Netty中的Future和ChannelFuture确实是异步的。这两个类都是异步操作结果的占位符。当你执行一个IO操作（例如写入数据，连接到服务器），Netty不会立即返回操作的结果，而是返回一个ChannelFuture。你可以在这个Future上添加一个或多个ChannelFutureListener，然后你的ChannelFutureListener将会在IO操作完成时（无论是否成功）被通知。

这就是Netty实现非阻塞IO的方式。调用一个IO操作后，你不必等待它完成，你可以继续做其他的事情。当IO操作完成时，你的监听器将会被调用。这样，IO操作实际上是在后台异步地进行的，不会阻塞你的应用程序。

值得注意的是，ChannelFuture的完成是通过Netty的事件循环（EventLoop）线程来驱动的。事件循环线程（这个线程相当于后台线程）会一直运行，检查IO事件是否已经完成，如果已经完成，它就会调用相应的ChannelFutureListener。

这种设计方式既实现了非阻塞IO，也实现了高效的并发处理，因为你的应用程序不必在每个IO操作上花费时间等待它完成，而是可以立即进行下一个操作。这是Netty能够高效处理大量并发连接的原因之一。

这里注册一个EventLoop循环线程来监听IO是否完成，不就成了同步操作了吗？

前面我们说到EventLoop循环线程是后台线程，可以用来检测所有的线程是否都完成，如果完成了则调用ChannelFuture提供的回调函数，这种情况对于执行任务的线程来说也是被动接收完成信号的，这恰恰属于异步。

真正的异步方式实现通知，也是需要注册类似于事件循环（EventLoop）线程吗？

通常来说，异步模型会有一个或多个后台线程或进程在不断地检查或等待IO操作是否完成。当IO操作完成时，这些后台线程或进程会触发相应的回调函数或事件。所以，EventLoop线程就是这样一种实现异步模型的机制。然而，这并不是唯一的方式。例如，在某些系统中，可能会使用信号（signal）或者中断（interrupt）来通知程序IO操作已经完成。不过，对于Java NIO和Netty来说，事件循环是一种常见的实现异步模型的方式。

同步/异步与阻塞/非阻塞

netty里用到的reactor是一种同步非阻塞模型吗?

是的，Reactor模式是一种同步非阻塞模型。

在Reactor模式中，一般会有一个或多个Reactor线程，这些线程会不断地轮询IO事件（例如是否有新的连接，是否有新的数据等），这里主动轮询相当于“事情的通知方式”是主动的，符合同步定义。当IO事件发生时，Reactor线程会同步地处理这些事件，比如接收新的连接、读取数据等。

这些操作是非阻塞的，因为Reactor线程在处理IO事件时，如果数据没有准备好，不会等待数据，而是会立即返回，然后继续轮询其他的IO事件。所以，Reactor模式可以高效地处理大量的并发连接。

具体的，Netty就是使用Reactor模式，通过Java NIO（同步非阻塞IO）实现高性能网络通信。

如果多个reactor线程不再主动轮询，而是被动接收通知，那么就相当于是异步非阻塞线程模型了吧？

如果多个Reactor线程被动接收通知，即不再轮询IO事件，而是在IO事件发生时，由操作系统主动通知这些Reactor线程，这种模型称为Proactor模式，或者称为异步IO模型。

为什么netty不采用这种异步非阻塞呢？

Netty为什么没有采用异步IO模型，主要原因可能是在Java中，支持异步IO模型的API（Java NIO.2，也称为Java AIO）在性能和可靠性上都不如Java NIO。在Java NIO.2发布之前，Netty已经使用Java NIO实现了高性能的网络通信。即使Java NIO.2发布之后，由于其性能和可靠性的问题，Netty也没有采用它。

理论上，实现异步非阻塞的性能应该比同步非阻塞的性能要好一些吧，那为什么java AIO的性能还变差了呢？

Java AIO实现的是异步的非阻塞I/O，这是通过底层的操作系统提供的异步I/O支持来实现的。当一个I/O操作完成时，操作系统会通知应用程序，应用程序则可以继续处理这个I/O操作的结果，这是通过回调函数来完成的。

然而，尽管Java AIO是设计为异步的，但在实际运行中，根据操作系统和JVM的实现，可能会创建一些额外的线程来处理异步I/O操作。具体创建多少线程，取决于底层操作系统和Java AIO的具体实现。

有些操作系统的异步I/O实现并不完全是异步的，它们可能会在内部使用线程池来处理一些I/O操作。如果这种情况发生在大量的I/O操作上，就可能导致CPU使用率上升。此外，Java AIO的实现可能也会在内部使用一些线程，这也可能增加CPU的使用。

因此，虽然理论上Java AIO不需要为每个连接创建一个线程，但在实践中，它可能会导致CPU使用率上升。这是因为操作系统和Java AIO的实现可能在内部使用了一些额外的线程，以及Java AIO的性能和可靠性可能不如Java NIO。这也是为什么Netty选择使用Java NIO而不是Java AIO作为其底层I/O模型的原因。

IO多路复用也是同步非阻塞的吧

IO多路复用确实是一种同步非阻塞的IO模型。在这种模型中，一个或多个线程会轮询多个IO事件，当IO事件准备好时，这些线程会同步地处理这些事件，比如接收新的连接、读取数据等。这些操作都是非阻塞的，因为这些线程在处理IO事件时，如果数据没有准备好，不会等待数据，而是会立即返回，然后继续轮询其他的IO事件。

netty里面的IO多路复用的轮询线程是不是复用了reactor的主线程？

在Netty中，网络IO操作的实现基于Java NIO，Java NIO本身使用了IO多路复用的技术。而在Netty的设计中，对于网络事件的处理采用了Reactor模式。Reactor模式中的事件循环线程（也被称为IO线程、event loop线程或者NIO线程）就是用来执行IO多路复用轮询操作的。

在具体的使用中，Netty允许你设置一组独立的线程作为EventLoopGroup，每个EventLoop线程都维护了一个Selector，执行轮询操作，然后处理选出的IO事件。这个EventLoopGroup可以看作是Reactor模式中的Reactor线程组。

所以，你可以说Netty里面的IO多路复用的轮询线程是Reactor的主线程，但是更准确的说法是，Netty实现了一种多Reactor模式，每个Reactor线程（也就是EventLoop线程）都执行IO多路复用的轮询操作，并处理对应的IO事件。

reactor和IO多路复用有什么区别和联系呢，可以认为IO多路复用是reactor模型在处理网络连接上的一种应用吗？

Reactor和IO多路复用实际上描述的是不同级别的概念。它们之间的关系可以理解为：Reactor是一种设计模式，而IO多路复用是这种设计模式在实现时可以采用的一种技术。

Reactor模式是一种事件处理模式，用于处理服务请求，发起者发送请求后不用同步等待应答，而是可以继续进行其他的操作。请求在接收者完成后，将应答发送给发起者，以此来提高并发性和资源利用率。Reactor模式中的主要角色有Reactor，Handler，Events和Demultiplexer。其中，Demultiplexer负责等待多个Event的发生（比如IO事件，信号，用户输入等）。在网络IO中，这通常通过IO多路复用实现。

IO多路复用是操作系统级别的一种技术，是通过一种机制使得一个进程可以监视多个网络连接（socket）的IO事件。这里的“多路”指的是多个网络连接，而复用指的是使用一个线程。IO多路复用可以让单个线程高效地处理多个并发连接。

因此，可以说IO多路复用是在实现Reactor模式中的一种技术，尤其在网络连接的处理上。在Reactor模式中，Demultiplexer通常通过IO多路复用技术来实现，可以监视多个网络连接的IO事件，当某个或某些网络连接上有IO事件发生时（比如可读、可写、连接可接受等），通知Reactor进行处理。