深入Linux内核理解epoll

同步和异步

关注的是调用方是否主动获取结果
- 同步
  - 调用方需要主动等待结果的返回
- 异步
  - 调用方不主动等待结果的返回，而是通过通知或回调的方式间接得到结果

阻塞和非阻塞

主要关注的是等待结果返回调用方的状态
- 阻塞
  - 结果返回之前，当前线程被挂起，不做任何事情
- 非阻塞
  - 结果在返回之前，线程不会被挂起，仍可以继续工作

同/异步、阻塞/非阻塞组合

同步阻塞
- 最常见的模型，比如买衣服缺货，等待补货之后才能买到
同步非阻塞
- 可以理解为轮询模式，比如买衣服缺货，不用干等着，可以时不时去问有没有货，有了再去买
异步阻塞
- 类似于线程池，有资源你才可以用，没资源你只能干等着
异步非阻塞
- 基于事件通知，一旦有才会去操作

五种I/O模型

BIO(阻塞I/O)
- 阻塞IO就是JDK里的BIO编程，一个客户端连接对应一个处理线程，如果读写不做操作会导致线程阻塞
- 适用于连接数较小且固定的场景
NIO(非阻塞I/O)
- 一个线程可以处理多个请求，客户端的所有连接请求都会注册到多路复用器selector上，然后轮询连接如果有I/O操作就会去处理
- 适用于连接数多但连接时间较短的场景，比如聊天、弹幕
- AIO(NIO 2.0)
  - 异步非阻塞，由OS完成后回调通知服务端启动线程去处理，一般适用于连接较多且连接时间较长的场景
  - 对于Netty不使用AIO是因为AIO目前还不成熟，底层依旧是使用epoll
IO复用(select、poll、epoll)
- IO复用就是JDK里的NIO编程
  - select
    - 基于数组实现，每次调用都进行遍历，最大连接数有上限
  - poll
    - 通过链表实现，每次调用都进行遍历，最大连接数无上限
  - epoll
    - 通过哈希表实现，通过事件通知，每当有IO事件就绪，系统注册的回调函数就会被调用，最大连接数无上限
- 在选择三者上需要根据实际场景进行选择，表面上看epoll性能最好，但是如果在连接数少并且活跃度较低时，select和poll的性能最好，低效的原因主要在轮询遍历上，所以也得视情况看
信号驱动IO
- 通过轮询模式，不断检测是否有数据到达，大量占用CPU时间，不推荐
异步IO
- 通信时额外使用信号处理函数

Reactor线程模型

单线程模式
- 一个线程负责多个事件处理，当连接数过多时会造成性能瓶颈，适用于连接数较少、复杂度较低的场景
多线程模式(单线程、工作线程池)
- 在单线程Reactor模式的基础上，将业务处理部分交给了线程池，提升并发能力，但是要注意线程安全
主从多线程模式
- 将整体拆分为主、从Reactor，主Reactor负责监听连接事件，将事件分发给从Reactor去处理，从Reactor负责与客户端读写操作，充分利用多核CPU，提升并发能力