深入Linux内核理解epoll

深入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，提升并发能力