简单地说，线程模型指定了操作系统、编程语言、框架或者应用程序的上下文中的线程管理的关键方面。 显而易见地，如何以及何时创建线程将对应用程序代码的执行产生显著的影响，因此开发人员需要理解与不同模型相关的权衡。
在本文中，我们将详细地探讨 Netty 的线程模型。它强大但又易用，并且和 Netty 的一贯宗旨一样，旨在简化你的应用程序代码，同时最大限度地提高性能和可维护性。我们还将讨论致使选择当前线程模型的经验。
如果你对 Java 的并发 API（java.util.concurrent）有比较好的理解，那么你应该会发 现在本章中的讨论都是直截了当的。如果这些概念对你来说还比较陌生，或者你需要更新自己的 相关知识，那么由 Brian Goetz 等编写的《Java 并发编程实战》 （Addison-Wesley Professional， 2006）这本书将是极好的资源。
1 线程模型概述
在早期的 Java 语言中，我们使用多线程处理的主要方式无非是按需创建和启动新的 Thread 来执行并发的任务单元——一种在高负载下工作得很差的原始方式。Java 5 随后引入了 Executor API，其线程池通过缓存和重用Thread 极大地提高了性能。 基本的线程池化模式可以描述为：
- 从池的空闲线程列表中选择一个 Thread，并且指派它去运行一个已提交的任务（一个 Runnable 的实现）
- 当任务完成时，将该 Thread 返回给该列表，使其可被重用
Executor 的执行逻辑 虽然池化和重用线程相对于简单地为每个任务都创建和销毁线程是一种进步，但是它并不能消除由上下文切换所带来的开销，其将随着线程数量的增加很快变得明显，并且在高负载下愈演愈烈。此外，仅仅由于应用程序的整体复杂性或者并发需求，在项目的生命周期内也可能会出现其他和线程相关的问题。 简而言之，多线程处理是很复杂的。在接下来的章节中，我们将会看到 Netty 是如何帮助简化它的。
2 EventLoop 接口
运行任务来处理在连接的生命周期内发生的事件是任何网络框架的基本功能。
与之相应的编程上的构造通常被称为事件循环—一个Netty 使用了 interface io.netty.channel.EventLoop来适配的术语。
代码清单
Netty 的 EventLoop 是协同设计的一部分，它采用了两个基本的 API：并发和网络编程。
- 首先，
io.netty.util.concurrent包构建在 JDK 的java.util.concurrent包基础上，用 来提供线程执行器 - 其次，
io.netty.channel包中的类，为了与 Channel 的事件进行交互，扩展了这些接口/类
EventLoop 的类层次结构
在这个模型中，一个 EventLoop 将由一个永远都不会改变的 Thread 驱动，同时任务（Runnable 或者 Callable）可以直接提交给 EventLoop 实现，以立即执行或者调度执行。
根据配置和可用核心的不同，可能会创建多个 EventLoop 实例用以优化资源的使用，并且单个
EventLoop 可能会被指派用于服务多个 Channel。
需要注意的是，Netty的EventLoop在继承了ScheduledExecutorService的同时，只定义了一个方法，parent() (这个方法重写了 EventExecutor 的 EventExecutorGroup.parent()方法),这个方法，如下面的代码片断所示，用于返回到当前EventLoop实现的实例所属的EventLoopGroup的引用。
- 事件/任务的执行顺序 事件和任务是以先进先出（FIFO）的顺序执行的。这样可以通过保证字节内容总是按正确的顺序被处理，消除潜在的数据损坏的可能性。
2.1Netty 4 中的 I/O 和事件处理
由 I/O 操作触发的事件将流经安装了一个或者多个ChannelHandler 的 ChannelPipeline。
传播这些事件的方法调用可以随后被 ChannelHandler所拦截，并且可以按需地处理事件。
事件的性质通常决定了它将被如何处理；它可能将数据从网络栈中传递到你的应用程序中，或者进行逆向操作，或者执行一些截然不同的操作。 但是事件的处理逻辑必须足够的通用和灵活，以处理所有可能的用例。因此，在Netty 4 中，所有的I/O操作和事件都由已经被分配给了EventLoop的那个Thread来处理(这里使用的是“来处理”而不是“来触发”，其中写操作是可以从外部的任意线程触发的)
2.2 Netty 3 中的 I/O 操作
在以前的版本中所使用的线程模型只保证了
- 入站（之前称为上游）事件会在所谓的 I/O 线程（对应于 Netty 4 中的 EventLoop）中执行
- 所有的出站（下游）事件都由调用线程处理，其可能是 I/O 线程也可能是别的线程
开始看起来这似乎是个好主意，但是已经被发现是有问题的，因为需要在ChannelHandler中对出站事件进行仔细的同步。简而言之，不可能保证多个线程不会在同一时刻尝试访问出站事件。例如，如果你通过在不同的线程中调用 Channel.write()方法，针对同一个 Channel 同时触发出站的事件，就会发生这种情况。
当出站事件触发了入站事件时，将会导致另一个负面影响。当 Channel.write()方法导致异常时，需要生成并触发一个 exceptionCaught 事件。但是在 Netty 3 的模型中，由于这是一个入站事件，需要在调用线程中执行代码，然后将事件移交给 I/O 线程去执行，然而这将带来额外的上下文切换。
Netty 4 中所采用的线程模型，通过在同一个线程中处理某个给定的 EventLoop中所产生的所有事件，解决了这个问题。这提供了一个更加简单的执行体系架构，并且消除了在多个ChannelHandler中进行同步的需要（除了任何可能需要在多个 Channel 中共享的）。
现在，已经理解了 EventLoop 的角色，让我们来看看任务是如何被调度执行的吧。
3 任务调度
偶尔，你将需要调度一个任务以便稍后（延迟）执行或者周期性地执行。 例如，你可能想要注册一个在客户端已经连接了 5 分钟之后触发的任务。一个常见的用例是，发送心跳消息到远程节点，以检查连接是否仍然还活着。如果没有响应，你便知道可以关闭该 Channel 了。
在接下来的几节中，我们将展示如何使用核心的 Java API 和 Netty 的EventLoop来调度任务。然后，我们将研究 Netty 的内部实现，并讨论它的优点和局限性。
3.1 JDK 的任务调度 API
在 Java 5 之前，任务调度是建立在 java.util.Timer类之上的，其使用了一个后台 Thread，并且具有与标准线程相同的限制。
随后，JDK 提供了java.util.concurrent包，它定义了interface ScheduledExecutorService
