epoll 本身是同步IO模型，但可以实现异步IO模型

本文链接：https://blog.youkuaiyun.com/qq_38662930/article/details/143587956

目录）

1. epoll 是同步IO模型，还是异步
2.epoll 怎么减少内核到用户的上下文切换，具体需要切换多少次
3.epoll 使用例子
4.epoll 工作原理
4.epoll 水平和边缘模式
- 4.1每个使用ET模式的文件描述符应该是非阻塞的？为什么
- 4.2 文件描述符是阻塞模式或非阻塞模式，是什么意思
5.reactor 与Preactor区别
6. Reactor适合处理大量并发的连接，而Proactor则适合处理高吞吐量的应用。大量并发的连接和高吞吐量区别
7.Reactor 可以处理高吞吐量嘛
8 reactor 为什么是IO串行。
9. reactor为什么单线程事件循环
10 reactor原理：主线程只负责监控，工作线程负责读取数据，接受新的连接。
11 reactor 优化
12. Reactor和Proactor 哪个适合处理大量并发的连接
13.epoll 最适合处理连接数量多，但是活动连接少的情况.

1. epoll 是同步IO模型，还是异步

在这里插入图片描述

epoll 本身是基于同步IO的，主要原因在于它的设计和实现机制。epoll 是 Linux 内核提供的一种 I/O 事件通知机制，它依赖于内核的事件通知机制来通知应用程序有数据可读或可写。当应用程序调用 epoll_wait 函数时，它会阻塞，直到有事件发生或超时。

以下是 epoll 为什么被认为是基于同步IO的几个主要原因：

阻塞调用：epoll_wait 是一个阻塞调用，当调用 epoll_wait 时，调用线程会被阻塞，直到有事件发生或超时。这与异步IO模型中的非阻塞调用不同，异步IO模型中的非阻塞调用不会阻塞调用线程，而是通过回调机制或 futures 来处理 I/O 操作的结果。
事件通知机制：epoll 依赖于内核的事件通知机制，当有事件发生时，内核会通知应用程序。这种机制本身是同步的，因为应用程序在等待事件通知的过程中，会被阻塞，直到有事件发生。
资源管理：epoll 使用事件通知机制，这意味着应用程序需要在内核和用户空间之间进行通信。当有事件发生时，内核会通过系统调用（如 epoll_wait）通知应用程序，然后应用程序可以处理事件。这种机制本身是同步的，因为应用程序在等待事件通知的过程中，会被阻塞，直到有事件发生。
性能优化：**epoll 的设计目标是优化同步IO模型的性能，它通过减少系统调用和内核态到用户态的上下文切换，**提高了同步IO模型的性能。**虽然 epoll 可以用于实现异步IO的效果，**但它本身是基于同步IO模型的。
API 设计：epoll 的 API 设计也反映了它是基于同步IO模型的。例如，epoll_wait 函数的签名如下：

int epoll_wait(int epfd, struct epoll_event *events, int maxevents, int timeout);

这个函数的调用会阻塞，直到有事件发生或超时，这与异步IO模型中的非阻塞调用不同。

综上所述，epoll 本身是基于同步IO的，它依赖于内核的事件通知机制来通知应用程序有数据可读或可写。当应用程序调用 epoll_wait 函数时，它会阻塞，直到有事件发生或超时。这与异步IO模型的非阻塞调用不同，异步IO模型中的非阻塞调用不会阻塞调用线程，而是通过回调机制或 futures 来处理 I/O 操作的结果。

2.epoll 怎么减少内核到用户的上下文切换，具体需要切换多少次

epoll 通过减少系统调用和内核态到用户态的上下文切换，提高了同步IO模型的性能。以下是 epoll 如何减少内核到用户的上下文切换的具体方法：

事件通知机制：epoll 使用事件通知机制，当有事件发生时，内核会通过系统调用（如 epoll_wait）通知应用程序，而不是每次有 I/O 事件发生时，都调用一次系统调用。这样可以减少系统调用次数，从而减少内核态到用户态的上下文切换次数。
epoll 可以同时监控多个IO，如果多个文件描述符上同时发生事件，可以尝试批量处理这些事件，而不是为每个事件都调用一次 epoll_wait。例如，可以在 epoll_wait 返回后，遍历所有返回的事件，批量处理这些事件。
事件注册和取消注册：epoll 允许应用程序在内核中注册和取消注册多个文件描述符，当文件描述符的状态发生变化时，内核会通知应用程序，而不是每次文件描述符的状态发生变化时，都调用一次系统调用。这样可以减少系统调用次数，从而减少内核态到用户态的上下文切换次数。
事件处理：epoll 使用事件处理机制，当有事件发生时，内核会通过系统调用（如 epoll_wait）通知应用程序，然后应用程序可以处理事件。这样可以减少系统调用次数，从而减少内核态到用户态的上下文切换次数。
事件触发机制：epoll 支持水平触发（level-triggered）和边缘触发（edge-triggered）两种触发机制。水平触发机制在文件描述符上有数据可读或可写时，会通知应用程序，而边缘触发机制在文件描述符上有数据可读或可写时，第一次通知应用程序，第二次通知时，数据可能已经读取或写入。因此，边缘触发机制可以减少不必要的 I/O 操作，从而减少内核态到用户态的上下文切换次数。
事件驱动：epoll 是事件驱动的，它可以在内核中注册多个文件描述符，当这些文件描述符有 I/O 事件发生时，内核会通知应用程序。这样可以减少系统调用次数，从而减少内核态到用户态的上下文切换次数。
高效的资源管理：epoll 使用事件通知机制，可以在内核中注册多个文件描述符，当这些文件描述符有 I/O 事件发生时，内核会通知应用程序。这样可以减少系统调用次数，从而减少内核态到用户态的上下文切换次数。

在使用 epoll 时，具体需要切换多少次内核态到用户态的上下文，取决于 I/O 事件的发生频率和应用程序的事件处理机制。通常情况下，epoll 可以显著减少内核态到用户态的上下文切换次数，从而提高系统的响应速度和吞吐量。

3.epoll 使用例子

在使用 epoll 时，可以使用 epoll_create 或 epoll_create1 函数创建一个 epoll 实例，然后使用 epoll_ctl 函数注册文件描述符，使用 epoll_wait 函数等待 I/O 事件。以下是一个简单的 epoll 示例代码：

#include <sys/epoll.h>
#include <unistd.h>
#include <iostream>
#include <vector>
#include <chrono>

int main() {
    int epoll_fd = epoll_create1(0);
    if (epoll_fd == -1) {
        std::cerr << "epoll_create1 failed" << std::endl;
        return 1;
    }

    struct epoll_event event;
    event.events = EPOLLIN;
    event.data.fd = 0; // 标准输入

    if (epoll_ctl(epoll_fd, EPOLL_CTL_ADD, 0, &event) == -1) {
        std::cerr << "epoll_ctl failed" << std::endl;
        return 1;
    }

    std::vector<epoll_event> events(10);
    while (true) {
        int n = epoll_wait(epoll_fd, events.data(), events.size(), -1);
        if (n == -1) {
            std::cerr << "epoll_wait failed" << std::endl;
            return 1;
        }

        for (int i = 0; i < n; ++i) {
            if (events[i].events & EPOLLIN) {
                std::cout << "标准输入有数据可读" << std::endl;
            }
        }
    }

    close(epoll_fd);
    return 0;
}

4.epoll 工作原理

4.epoll 水平和边缘模式

LT模式当调用cpoll_wait 时，检测到就绪列表不为空，会循环的通知应用程序
ET模式当调用epoll wait 时，检测到就绪列表有变化，才会通知应用程序。当某个fd,没有处理完，只要就绪列表不变，则不通知应用程序
对于采用 LT工作模式的文件描述符,当cpoll_wait 检测到其上有事件发生并将此事件通知应用程序后**,应用程序可以不立即处理该事件**。这样,当应用程序下一次调用poll_wait 时,cpoll_wait 还会再次向应用程序通告此事件,直到该事件被处理。而对于
采用 ET 工作模式的文件描述符,当cpoll_wait 检测到其上有事件发生并将此事件通知应用程序后,应用程序必须立即处理该事件（while循环）,因为后续的 epoll_wait 调用将不再向应用程序通知这一事件。可见,ET模式在很大程度上降低了同一个cpoll事件被重复触发的次数,
因此效率要比 LT 模式高。

4.1每个使用ET模式的文件描述符应该是非阻塞的？为什么

是的，在使用边缘触发（ET）模式时，每个文件描述符都应该设置为非阻塞模式。边缘触发模式的关键在于它只在事件刚刚发生时触发一次事件，之后该事件不会再次触发，直到事件再次发生。因此，如果文件描述符没有设置为非阻塞模式，当事件发生后，read 或 write 调用可能会阻塞，直到事件再次发生，这与边缘触发的设计理念相悖。

为什么需要非阻塞模式
边缘触发的特性：边缘触发模式的特性是，只有在事件刚刚发生时才会触发事件，之后该事件不会再次触发，直到事件再次发生。如果文件描述符是阻塞模式，当事件发生后，read 或 write 调用可能会阻塞，直到事件再次发生，这会破坏边缘触发的特性。

事件处理的及时性：在边缘触发模式下，事件发生后，应用程序需要立即处理事件。如果文件描述符是阻塞模式，应用程序可能会在等待事件的过程中被阻塞，这会导致事件处理的及时性降低。

减少系统调用的次数：在边缘触发模式下，epoll_wait 只会在事件发生时被调用，而不是在每次检查时都调用。如果文件描述符是阻塞模式，可能会导致多次系统调用，因为 read 或 write 调用可能会阻塞，直到事件再次发生。

4.2 文件描述符是阻塞模式或非阻塞模式，是什么意思

文件描述符（File Descriptor）是操作系统内核和应用程序之间的一种接口，用于表示打开的文件、网络连接、设备等资源。在文件描述符的上下文中，阻塞模式（Blocking）和非阻塞模式（Non-blocking）是两种不同的操作模式，它们决定了文件描述符在处理 I/O 操作时的行为。

阻塞模式（Blocking）
在阻塞模式下，当应用程序尝试进行 I/O 操作（如读取或写入）时，如果 I/O 操作无法立即完成（例如，数据尚未准备好或目标设备暂时不可用），应用程序将被挂起（即进入睡眠状态），直到 I/O 操作完成。这种模式下，应用程序不会主动通知操作系统它已经准备好处理 I/O 操作，而是等待操作系统通知它 I/O 操作已经完成。

非阻塞模式（Non-blocking）
在非阻塞模式下，当应用程序尝试进行 I/O 操作时，如果 I/O 操作无法立即完成，应用程序不会被挂起，而是立即返回一个特定的错误码（如 EAGAIN 或 EWOULDBLOCK），表示 I/O 操作尚未完成。应用程序可以选择在接收到这个错误码后，继续尝试进行 I/O 操作，或者选择在稍后某个时间点再次尝试。

选择阻塞模式还是非阻塞模式
选择阻塞模式还是非阻塞模式，主要取决于应用程序的需求和具体的使用场景：

阻塞模式：

适用于简单的、对 I/O 操作时间敏感的应用程序。
简化了 I/O 操作的处理逻辑，因为应用程序不需要处理错误码或状态变化。
可能会导致应用程序在 I/O 操作等待期间无法执行其他任务。
非阻塞模式：

适用于需要高并发处理能力的应用程序，如网络服务器、聊天室等。
允许应用程序在 I/O 操作等待期间可以执行其他任务，从而提高整体的响应速度和处理能力。
复杂了 I/O 操作的处理逻辑，因为应用程序需要处理错误码和状态变化，可能需要使用多线程或事件循环来管理 I/O 操作。

5.reactor 与Preactor区别

Reactor和Proactor是两种常见的IO模型，它们主要用于处理异步IO操作。

Reactor模型：
- 同步：Reactor模型本身是同步的。它的核心思想是通过一个事件循环（event loop）来监听多个IO事件，当某个IO事件发生时，事件循环会将控制权交给相应的处理函数进行处理。整个处理过程是同步的，即处理函数在处理完一个事件后，才会继续处理下一个事件。
Proactor模型：
- 异步：Proactor模型是异步的。它的特点是IO操作是立即返回的，而不是等待IO操作完成。IO操作的实际处理是由操作系统或库进行的，通过回调函数或Completion Port（在Windows中）来通知处理结果。

因此，Reactor模型是同步的，而Proactor模型是异步的。它们各自适用于不同的场景，Reactor适合处理大量并发的连接，而Proactor则适合处理高吞吐量的应用。

6. Reactor适合处理大量并发的连接，而Proactor则适合处理高吞吐量的应用。大量并发的连接和高吞吐量区别

7大量并发的连接和高吞吐量在某种程度上是相关的，但它们描述的侧重点有所不同：

大量并发的连接：
- 描述对象：指的是在同一时间内，有大量的客户端连接到服务器。这些连接可能不会同时发起IO操作，但系统需要能够同时处理这些连接的请求。
- 关键挑战：主要挑战在于如何高效地管理和分配系统资源（如CPU、内存、网络资源等），以及如何在高并发的情况下保持系统的稳定性和响应速度。
- 典型应用场景：例如聊天室、在线游戏服务器、Web服务器处理大量短连接等。
高吞吐量：
- 描述对象：指的是在单位时间内，系统能够处理的请求或数据的数量。高吞吐量通常意味着系统能够高效地处理大量的数据或请求。
- 关键挑战：主要挑战在于如何提高系统的处理能力，减少请求的响应时间，提高整体的系统性能。
- 典型应用场景：例如高性能计算、实时数据处理系统、大型电子商务网站的高峰期流量等。

总结来说，大量并发的连接更强调的是系统能够同时处理的连接数量，而高吞吐量更强调的是系统在单位时间内处理的请求或数据的数量。两者在设计高性能系统时都非常重要，通常需要在架构设计中找到平衡点，以满足具体应用的需求。

7.Reactor 可以处理高吞吐量嘛

Reactor模式本身在处理高吞吐量方面有一定的局限性，主要体现在以下几个方面：

单线程事件循环：Reactor模式通常使用一个单线程的事件循环来监听和处理事件。如果事件循环是单线程的，那么它的处理能力受到CPU核心数的限制。相比之下，Proactor模式可以利用多个线程或进程来并行处理IO操作，从而在多核系统中获得更好的并行处理能力。
事件调度和上下文切换：在Reactor模式中，事件循环需要不断地检查和调度事件，这可能会导致较多的上下文切换开销。虽然现代操作系统和编程语言提供了优化的调度机制，但在高并发、高吞吐量的场景下，上下文切换仍然可能成为性能瓶颈。
IO操作的串行处理：Reactor模式通常会将IO操作串行处理，即一个IO操作完成后，才会处理下一个IO操作。如果IO操作的处理时间较长，可能会导致处理速度下降，尤其是在高并发场景下。

尽管如此，Reactor模式在处理大量并发连接方面表现良好，特别是在处理大量短连接的场景下，如Web服务器处理大量HTTP请求。为了提高Reactor模式的吞吐量，可以考虑以下几种优化策略：

多线程事件循环：使用多个事件循环，每个事件循环处理一部分连接，从而提高整体的处理能力。
非阻塞IO：使用非阻塞IO操作，减少IO操作的等待时间，提高系统的响应速度。
连接池：使用连接池来复用连接，减少连接创建和销毁的开销。

通过这些优化策略，可以在一定程度上提高Reactor模式在高吞吐量场景下的性能，但可能仍然无法与Proactor模式在某些场景下提供的并行处理能力相媲美。

8 reactor 为什么是IO串行。

Reactor模式中的IO操作并非是真正的并行处理，而是事件驱动的非阻塞处理。Reactor模式的核心思想是通过一个事件循环来监听多个IO事件，当某个IO事件发生时，事件循环会将控制权交给相应的处理函数进行处理。这个处理过程是同步的，即处理函数在处理完一个事件后，才会继续处理下一个事件。

在Reactor模式中，IO操作的处理是通过以下步骤进行的：

事件注册：将IO事件注册到事件循环中，例如注册一个网络连接的读事件。
事件循环：事件循环不断地检查是否有IO事件发生。如果有事件发生，例如网络连接有数据可读，事件循环会将控制权交给相应的处理函数。
事件处理：处理函数读取数据，处理完数据后，可能会触发其他事件，例如写事件或错误事件。
事件调度：事件循环再次检查IO事件，重复上述过程。

由于事件处理是同步进行的，因此Reactor模式中的IO操作并不是真正的并行处理。相反，它通过非阻塞IO和事件驱动机制，避免了IO操作阻塞线程，从而提高了系统的响应速度和吞吐量。

然而，为了提高Reactor模式的处理效率，可以考虑以下几种优化策略：

多线程事件循环：使用多个事件循环，每个事件循环处理一部分连接，从而提高整体的处理能力。
异步IO操作：使用异步IO操作，例如异步读取数据，而不是阻塞等待数据可读。
连接池：使用连接池来复用连接，减少连接创建和销毁的开销。

通过这些优化策略，可以在一定程度上提高Reactor模式的处理效率，但并不能实现真正的并行处理。

9. reactor为什么单线程事件循环

Reactor模式使用单线程事件循环的设计主要是为了简化事件处理的逻辑和提高系统的响应速度。以下是一些关键原因：

简化逻辑：单线程事件循环使得事件处理的逻辑相对简单。事件循环只需要管理一个调用栈，避免了线程间的上下文切换开销。这种简单的设计使得Reactor模式在实现和维护上更加容易。
响应速度：单线程事件循环可以更快地响应事件。这是因为在单线程环境中，事件处理是顺序进行的，没有线程间的竞争和上下文切换开销。虽然多线程事件循环可以并行处理事件，但也会带来线程间的同步和通信开销，可能会影响系统的整体响应速度。
资源效率：单线程事件循环在处理大量并发连接时，能够更高效地利用系统资源。因为事件处理是顺序进行的，可以更好地利用CPU的多核特性，避免了多线程环境中可能出现的资源浪费。
调试和分析：单线程事件循环使得调试和性能分析更加容易。由于事件处理是顺序进行的，可以更容易地追踪和分析事件处理的流程，找出性能瓶颈。

尽管单线程事件循环有这些优点，但在处理高并发、高吞吐量的场景下，可能会受到资源限制，尤其是在多核系统中。为了提高Reactor模式的处理能力，可以考虑以下几种优化策略：

多线程事件循环：使用多个单线程事件循环，每个事件循环处理一部分连接，从而提高整体的处理能力。
异步IO操作：使用异步IO操作，例如异步读取数据，而不是阻塞等待数据可读。
连接池：使用连接池来复用连接，减少连接创建和销毁的开销。

通过这些优化策略，可以在一定程度上提高Reactor模式的处理效率，但可能仍然无法与多线程事件循环在某些场景下提供的并行处理能力相媲美。

10 reactor原理：主线程只负责监控，工作线程负责读取数据，接受新的连接。

Reactor 是这样一种模式,它要求主线程(1/O处理单元,下同)只负责监听文件描述上
是否有事件发生,有的话就立即将该事件通知工作线程(逻辑单元,下同)。除此之外,主
线程不做任何其他实质性的工作。读写数据,接受新的连接,以及处理客户请求均在工作线
程中完成。的
使用同步 I/O 模型(以epoll_wait 为例)实现的 Reactor 模式的工作流程是:的
1)主线程往 epoll 内核事件表中注册 socket 上的读就绪事件。
2)主线程调用 epoll_wait 等待 socket 上有数据可读。的
3)当 socket上有数据可读时,epoll_wait 通知主线程。主线程则将 socket 可读事件放入
请求队列。的
4)睡眠在请求队列上的某个工作线程被唤醒,它从 socket 读取数据,并处理客户请求,
然后往cpoll 内核事件表中注册该 socket 上的写就绪事件。的
5)主线程调用 epoll_wait 等待 socket 可写。
6)当 socket 可写时,epoll_wait 通知主线程。主线程将 socket 可写事件放入请求队列。
7)睡眠在请求队列上的某个工作线程被唤醒,它往 socket 上写人服务器处理客户请求
的结果。

11 reactor 优化

为了提高Reactor模式的性能和处理能力，可以考虑以下几种优化策略：

多线程事件循环：使用多个单线程事件循环，每个事件循环处理一部分连接，从而提高整体的处理能力。这种策略可以充分利用多核系统的资源，提高系统的吞吐量。
异步IO操作：使用异步IO操作，例如异步读取数据，而不是阻塞等待数据可读。异步IO可以避免线程阻塞，提高系统的响应速度和吞吐量。
连接池：使用连接池来复用连接，减少连接创建和销毁的开销。连接池可以显著提高系统的性能，特别是在处理大量短连接的场景下。
事件分发优化：优化事件分发机制，例如使用更高效的事件分发算法，减少事件分发的开销。
非阻塞IO：使用非阻塞IO操作，减少IO操作的等待时间，提高系统的响应速度。
负载均衡：使用负载均衡策略，将连接分配到不同的事件循环或服务器，从而提高系统的处理能力。
缓存机制：使用缓存机制，例如缓存频繁访问的数据，减少数据库查询次数，提高系统的响应速度。
优化事件处理：优化事件处理逻辑，例如减少事件处理的复杂度，提高事件处理的效率。

通过这些优化策略，可以在一定程度上提高Reactor模式的处理效率，但可能仍然无法与多线程事件循环在某些场景下提供的并行处理能力相媲美。选择哪种优化策略，取决于具体的应用场景和需求。

12. Reactor和Proactor 哪个适合处理大量并发的连接

在处理大量并发连接时，Reactor和Proactor模式各有其优势，具体选择哪种模式，取决于具体的应用场景和系统资源。

Reactor模式在处理大量并发连接时，主要是因为其事件驱动和非阻塞的特性，使得系统能够高效地处理大量并发连接。Reactor模式的单线程事件循环和事件分发机制，可以避免线程间的上下文切换开销，提高系统的响应速度和吞吐量。此外，Reactor模式的事件处理逻辑相对简单，可以更容易地进行调试和性能分析。

Proactor模式在处理大量并发连接时，可以充分利用操作系统或底层库的异步IO能力，避免了应用程序在等待IO操作完成时的阻塞，从而提高了系统的响应速度和吞吐量。在高并发连接场景中，每个连接可能需要频繁的IO操作，Proactor模式可以更好地利用系统资源，提高系统的处理能力。

然而，Proactor模式的实现依赖于操作系统或底层库的异步IO能力，因此在某些平台上可能无法实现。另外，Proactor模式的事件处理是异步进行的，可能需要更复杂的错误处理和资源管理。

总之，Reactor模式和Proactor模式在处理大量并发连接时都有其优势，但具体的性能优势取决于操作系统或底层库的异步IO能力。选择Reactor模式还是Proactor模式，应根据具体的应用场景和系统资源进行权衡。