Netty学习笔记（七）EventLoop

一、EventLoop接口

Netty 的 EventLoop 是协同设计的一部分，它采用了两个基本的 API：并发和网络编程。 首先，io.netty.util.concurrent 包构建在 JDK 的java.util.concurrent 包上，用 来提供线程执行器。其次，io.netty.channel 包中的类，为了与 Channel 的事件进行交互， 扩展了这些接口/类。其类层次结构如下图所示：

在这个模型中，一个 EventLoop 将由一个永远都不会改变的 Thread 驱动，同时任务 (Runnable 或者 Callable)可以直接提交给 EventLoop 实现，以立即执行或者调度执行。根据配置和CPU可用核心的不同，可能会创建多个 EventLoop 实例用以优化资源的使用，并且单个 EventLoop 可能会被指派用于服务多个 Channel。 

二、线程管理

Netty线程模型的卓越性能取决于对于当前执行的Thread的身份的确定，也就是说，确定它是否是分配给当前Channel以及它的EventLoop的那一个线程。 如果(当前)调用线程正是支撑 EventLoop 的线程，那么所提交的代码块将会被(直接)执行。否则，EventLoop 将调度该任务以便稍后执行，并将它放入到内部队列中。当 EventLoop 下次处理它的事件时，它会执行队列中的那些任务/事件。这也就解释了任何的 Thread 是如何 与 Channel 直接交互而无需在 ChannelHandler 中进行额外同步的。

注意，每个 EventLoop 都有它自已的任务队列，独立于任何其他的 EventLoop。下图展示了 EventLoop 用于调度任务的执行逻辑。这是 Netty 线程模型的关键组成部分。 

 三、EventLoop/线程的分配

服务于 Channel 的 I/O 和事件的 EventLoop 包含在 EventLoopGroup 中。根据不同的传输实现，EventLoop 的创建和分配方式也不同。

1、异步传输

异步传输实现只使用了少量的 EventLoop(以及和它们相关联的Thread)，而且在当前的线程模型中，它们可能会被多个 Channel 所共享。这使得可以通过尽可能少量的 Thread 来支撑大量的 Channel，而不是每个 Channel 分配一个 Thread。下图显示了一个 EventLoopGroup，它具有 3 个固定大小的 EventLoop(每个 EventLoop都由一个 Thread 支撑)。在创建 EventLoopGroup 时就直接分配了 EventLoop(以及支撑它们 的 Thread)，以确保在需要时它们是可用的。 

EventLoopGroup 负责为每个新创建的 Channel 分配一个 EventLoop。在当前实现中， 使用顺序循环(round-robin)的方式进行分配以获取一个均衡的分布，并且相同的 EventLoop 可能会被分配给多个 Channel。(这一点在将来的版本中可能会改变。)一旦一个 Channel 被分配给一个 EventLoop，它将在它的整个生命周期中都使用这个 EventLoop(以及相关联的 Thread)。这样的实现可以使我们不必过度担忧ChannelHandler中的线程安全和同步问题。另外，需要注意的是，EventLoop 的分配方式对 ThreadLocal 的使用的影响。因为一个 EventLoop 通常会被用于支撑多个 Channel，所以对于所有相关联的 Channel 来说， ThreadLocal 都将是一样的。这使得它对于实现状态追踪等功能来说是个糟糕的选择。然而， 在一些无状态的上下文中，它仍然可以被用于在多个 Channel 之间共享一些重度的或者代价昂贵的对象，甚至是事件。 

2、阻塞传输

在阻塞传输下每一个 Channel 都将被分配给一个 EventLoop(以及它的 Thread)。 

但是，正如同之前一样，仍然是每个 Channel 的 I/O 事件都将只会被一个 Thread (用于支撑该 Channel 的 EventLoop 的那个 Thread)处理。这也是Netty设计一致性的体现，这种设计对 Netty 的可靠性和易用性做出了巨大贡献。