第十五章：选择正确的线程模型

本章介绍

线程模型(thread-model)

事件循环(EventLoop)

并发(Concurrency)

任务执行(task execution)

任务调度(task scheduling)

线程模型定义了应用程序或框架如何执行你的代码，选择应用程序/框架的正确的线程模型是很重要的。Netty提供了一个简单强大的线程模型来帮助咱们简化代码，Netty对全部的核心代码都进行了同步。全部ChannelHandler，包括业务逻辑，都保证由一个线程同时执行特定的通道。这并不意味着Netty不能使用多线程，只是Netty限制每一个链接都由一个线程处理，这种设计适用于非阻塞程序。咱们没有必要去考虑多线程中的任何问题，也不用担忧会抛ConcurrentModificationException或其余一些问题，如数据冗余、加锁等，这些问题在使用其余框架进行开发时是常常会发生的。

读完本章就会深入理解Netty的线程模型以及Netty团队为何会选择这样的线程模型，这些信息可让咱们在使用Netty时让程序由最好的性能。此外，Netty提供的线程模型还可让咱们编写整洁简单的代码，以保持代码的整洁性；咱们还会学习Netty团队的经验，过去使用其余的线程模型，如今咱们将使用Netty提供的更容易更强大的线程模型来开发。

尽管本章讲述的是Netty的线程模型，可是咱们仍然可使用其余的线程模型；至于如何选择一个完美的线程模型应该根据应用程序的实际需求来判断。

本章假设以下：

你明白线程是什么以及如何使用，并有使用线程的工做经验；若不是这样，就请花些时间来了解清楚这些知识。推荐一本书：Java并发编程实战。

你了解多线程应用程序及其设计，也包括如何保证线程安全和获取最佳性能。

你了解java.util.concurrent以及ExecutorService和ScheduledExecutorService。

15.1 线程模型概述

本节将简单介绍通常的线程模型，Netty中如何使用指定的线程模型，以及Netty不一样的版本中使用的线程模型。你会更好的理解不一样的线程模型的全部利弊。

若是思考一下，在咱们的生活中会发现不少状况都会使用线程模型。例如，你有一个餐厅，向你的客户提供食品，食物须要在厨房煮熟后才能给客户；某个客户下了订单后，你须要将煮熟事物这个任务发送到厨房，而厨房能够以不一样的方式来处理，这就像一个线程模型，定义了如何执行任务。

只有一个厨师：

这种方法是单线程的，一次只执行一个任务，完成当前订单后再处理下一个。

你有多个厨师，每一个厨师均可以作，空闲的厨师准备着接单作饭：

这种方式是多线程的，任务由多个线程(厨师)执行，能够并行同时执行。

你有多个厨师并分红组，一组作晚餐，一个作其余：

这种状况也是多线程，可是带有额外的限制；同时执行多个任务是由实际执行的任务类型(晚餐或其余)决定。

从上面的例子看出，平常活动适合在一个线程模型。可是Netty在这里适用吗？

不幸的是，它没有那么简单，Netty的核心是多线程，但隐藏了来自用户的大部分。

Netty使用多个线程来完成全部的工做，只有一个线程模型线型暴露给用户。大多数现代应用程序使用多个线程调度工做，让应用程序充分使用系统的资源来有效工做。在早期的Java中，这样作是经过按需建立新线程并行工做。但很快发现者不是完美的方案，由于建立和回收线程须要较大的开销。

在Java5中加入了线程池，建立线程和重用线程交给一个任务执行，这样使建立和回收线程的开销降到最低。

下图显示使用一个线程池执行一个任务，提交一个任务后会使用线程池中空闲的线程来执行，完成任务后释放线程并将线程从新放回线程池.

上图每一个任务线程的建立和回收不须要新线程去建立和销毁，但这只是一半的问题，咱们稍后学习。你可能会问为何不使用多线程，使用一个ExecutorService能够有助于防止线程建立和回收的成本？

使用多线程会有太多的上下文切换，提升了资源和管理成本，这种反作用会随着运行线程的数量和执行的任务数量的增长而越发明显。使用多线程在刚开始可能没有什么问题，但随着系统的负载增长，可能在某个点就会让系统崩溃。

除了这些技术上的限制和问题，在项目生命周期内维护应用程序/框架可能还会发生其余问题。它有效的说明了增长应用程序的复杂性取决于它是平行的，简单的陈述：编写多线程应用程序时一个辛苦的工做！咱们怎么来解决这个问题呢？在实际的场景中须要多个线程模型。让咱们来看看Netty是如何解决这个问题的。

15.2 事件循环

事件循环所作的正如它的名字，它运行的事件在一个循环中，直到循环终止。这很是适合网络框架的设计，由于它们须要为一个特定的链接运行一个事件循环。这不是Netty的新发明，其余的框架和实现已经很早就这样作了。

在Netty中使用EventLoop接口表明事件循环，EventLoop是从EventExecutor和ScheduledExecutorService扩展而来，因此能够讲任务直接交给EventLoop执行。类关系图以下：

15.2.1 使用事件循环

下面代码显示如何访问已分配给通道的EventLoop并在EventLoop中执行任务：

Channel ch = ...;  
ch.eventLoop().execute(new Runnable() {  
    @Override  
    public void run() {  
        System.out.println("run in the eventloop");  
    }  
});

使用事件循环的好处是不须要担忧同步问题，在同一线程中执行全部其余关联通道的其余事件。这彻底符合Netty的线程模型。检查任务是否已执行，使用返回的Future，使用Future能够访问不少不一样的操做。下面的代码是检查任务是否执行：

Channel ch = ...;  
Future<?> future = ch.eventLoop().submit(new Runnable() {  
    @Override  
    public void run() {  
          
    }  
});  
if(future.isDone()){  
    System.out.println("task complete");  
}else {  
    System.out.println("task not complete");  
}

检查执行任务是否在事件循环中:

Channel ch = ...;  
if(ch.eventLoop().inEventLoop()){  
    System.out.println("in the EventLoop");  
}else {  
    System.out.println("outside the EventLoop");  
}

只有确认没有其余EventLoop使用线程池了才能关闭线程池，不然可能会产生未定义的反作用。

15.2.2 Netty4中的I/O操做

这个实现很强大，甚至Netty使用它来处理底层I/O事件，在socket上触发读和写操做。这些读和写操做是网络API的一部分，经过java和底层操做系统提供。下图显示在EventLoop上下文中执行入站和出站操做，若是执行线程绑定到EventLoop，操做会直接执行；若是不是，该线程将排队执行：

须要一次处理一个事件取决于事件的性质，一般从网络堆栈读取或传输数据到你的应用程序，有时在另外的方向作一样的事情，例如从你的应用程序传输数据到网络堆栈再发送到远程对等通道，但不限于这种类型的事物；更重要的是使用的逻辑是通用的，灵活处理各类各样的案例。

应该指出的是，线程模型(事件循环的顶部)描述并不老是由Netty使用。咱们在了解Netty3后会更容易理解为何新的线程模型是可取的。

15.2.3 Netty3中的I/O操做

在之前的版本有点不一样，Netty保证在I/O线程中只有入站事件才被执行，全部的出站时间被调用线程处理。这看起来是个好方案，但很容易出错。它还将负责同步ChannelHandler来处理这些事件，由于它不保证只有一个线程同时操做；这可能发生在你去掉通道下游事件的同时，例如，在不一样的线程调用Channel.write(...)。下图显示Netty3的执行流程：

除了须要负担同步ChannelHandler，这个线程模型的另外一个问题是你可能须要去掉一个入站事件做为一个出站事件的结果，例如Channel.write(...)操做致使异常。在这种状况下，捕获的异常必须生成并抛出去。乍看之下这不像是一个问题，但咱们知道，捕获异常由入站事件涉及，会让你知道问题出在哪里。问题是，事实上，你如今的状况是在调用线程上执行，但捕获到异常事件必须交给工做线程来执行。这是可行的，但若是你忘了传递过去，它会致使线程模型失效；假设入站事件只有一个线程不是真，这可能会给你各类各样的竞争条件。

之前的实现有一个惟一的积极影响，在某些状况下它能够提供更好的延迟；成本是值得的，由于它消除了复杂性。实际上，在大多数应用程序中，你不会遵照任何差别延迟，还取决于其余因数，如：

字节写入到远程对等通道有多快

I/O线程是否繁忙

上下文切换

锁定

你能够看到不少细节影响总体延迟。

15.2.4 Netty线程模型内部

Netty的内部实现使其线程模型表现优异，它会检查正在执行的线程是不是已分配给实际通道(和EventLoop)，在Channel的生命周期内，EventLoop负责处理全部的事件。若是线程是相同的EventLoop中的一个，讨论的代码块被执行；若是线程不一样，它安排一个任务并在一个内部队列后执行。一般是经过EventLoop的Channel只执行一次下一个事件，这容许直接从任何线程与通道交互，同时还确保全部的ChannelHandler是线程安全，不须要担忧并发访问问题。

下图显示在EventLoop中调度任务执行逻辑，这适合Netty的线程模型：

设计是很是重要的，以确保不要把任何长时间运行的任务放在执行队列中，由于长时间运行的任务会阻止其余在相同线程上执行的任务。这多少会影响整个系统依赖于EventLoop实现用于特殊传输的实现。传输之间的切换在你的代码库中可能没有任何改变，重要的是：切勿阻塞I/O线程。若是你必须作阻塞调用(或执行须要长时间才能完成的任务)，使用EventExecutor。

下一节将讲解一个在应用程序中常用的功能，就是调度执行任务(按期执行)。Java对这个需求提供了解决方案，但Netty提供了几个更好的方案。

15.3 调度任务执行

每隔一段时间须要调度任务执行，也许你想注册一个任务在客户端完成链接5分钟后执行，一个常见的用例是发送一个消息“你还活着？”到远程对等通道，若是远程对等通道没有反应，则能够关闭通道(链接)和释放资源。就像你和朋友打电话，沉默了一段时间后，你会说“你还在吗？”，若是朋友没有回复，就多是断线或朋友睡着了；不论是什么问题，你均可以挂断电话，没有什么可等待的；你挂了电话后，收起电话能够作其余的事。

本节介绍使用强大的EventLoop实现任务调度，还会简单介绍Java API的任务调度，以方便和Netty比较加深理解。

15.3.1 使用普通的Java API调度任务

在Java中使用JDK提供的ScheduledExecutorService实现任务调度。使用Executors提供的静态方法建立ScheduledExecutorService，有以下方法：

newScheduledThreadPool(int)

newScheduledThreadPool(int, ThreadFactory)

newSingleThreadScheduledExecutor()

newSingleThreadScheduledExecutor(ThreadFactory)

看下面代码：

ScheduledExecutorService executor = Executors.newScheduledThreadPool(10);  
ScheduledFuture<?> future = executor.schedule(new Runnable() {  
    @Override  
    public void run() {  
        System.out.println("now it is 60 seconds later");  
    }  
}, 60, TimeUnit.SECONDS);  
if(future.isDone()){  
    System.out.println("scheduled completed");  
}  
//.....  
executor.shutdown();

15.3.2 使用EventLoop调度任务

使用ScheduledExecutorService工做的很好，可是有局限性，好比在一个额外的线程中执行任务。若是须要执行不少任务，资源使用就会很严重；对于像Netty这样的高性能的网络框架来讲，严重的资源使用是不能接受的。Netty对这个问题提供了很好的方法。

Netty容许使用EventLoop调度任务分配到通道，以下面代码：

Channel ch = ...;  
ch.eventLoop().schedule(new Runnable() {  
    @Override  
    public void run() {  
        System.out.println("now it is 60 seconds later");  
    }  
}, 60, TimeUnit.SECONDS);

若是想任务每隔多少秒执行一次，看下面代码：

Channel ch = ...;  
ScheduledFuture<?> future = ch.eventLoop().scheduleAtFixedRate(new Runnable() {  
    @Override  
    public void run() {  
        System.out.println("after run 60 seconds,and run every 60 seconds");  
    }  
}, 60, 60, TimeUnit.SECONDS);  
// cancel the task  
future.cancel(false);

15.3.3 调度的内部实现

Netty内部实现实际上是基于George Varghese提出的“Hashed  and  hierarchical  timing wheels: Data structures  to efficiently implement timer facility(散列和分层定时轮：数据结构有效实现定时器)”。这种实现只保证一个近似执行，也就是说任务的执行可能不是100%准确；在实践中，这已经被证实是一个可容忍的限制，不影响多数应用程序。因此，定时执行任务不可能100%准确的按时执行。

为了更好的理解它是如何工做，咱们能够这样认为：

在指定的延迟时间后调度任务；

任务被插入到EventLoop的Schedule-Task-Queue(调度任务队列)；

若是任务须要立刻执行，EventLoop检查每一个运行；

若是有一个任务要执行，EventLoop将马上执行它，并从队列中删除；

EventLoop等待下一次运行，从第4步开始一遍又一遍的重复。

由于这样的实现计划执行不可能100%正确，对于多数用例不可能100%准备的执行计划任务；在Netty中，这样的工做几乎没有资源开销。可是若是须要更准确的执行呢？很容易，你须要使用ScheduledExecutorService的另外一个实现，这不是Netty的内容。记住，若是不遵循Netty的线程模型协议，你将须要本身同步并发访问。

15.4 I/O线程分配细节

Netty使用线程池来为Channel的I/O和事件服务，不一样的传输实现使用不一样的线程分配方式；异步实现是只有几个线程给通道之间共享，这样可使用最小的线程数为不少的平道服务，不须要为每一个通道都分配一个专门的线程。

下图显示如何分配线程池：

如上图所示，使用一个固定大小的线程池管理三个线程，建立线程池后就把线程分配给线程池，确保在须要的时候，线程池中有可用的线程。这三个线程会分配给每一个新建立的已链接通道，这是经过EventLoopGroup实现的，使用线程池来管理资源；实际会平均分配通道到全部的线程上，这种分布以循环的方式完成，所以它可能不会100%准确，但大部分时间是准确的。

一个通道分配到一个线程后，在这个通道的生命周期内都会一直使用这个线程。这一点在之后的版本中可能会被改变，因此咱们不该该依赖这种方式；不会被改变的是一个线程在同一时间只会处理一个通道的I/O操做，咱们能够依赖这种方式，由于这种方式能够确保不须要担忧同步。

下图显示OIO(Old Blocking I/O)传输：

从上图能够看出，每一个通道都有一个单独的线程。咱们可使用java.io.*包里的类来开发基于阻塞I/O的应用程序，即便语义改变了，但有一件事仍然保持不变，每一个通道的I/O在同时只能被一个线程处理；这个线程是由Channel的EventLoop提供，咱们能够依靠这个硬性的规则，这也是Netty框架比其余网络框架更容易编写的缘由。

15.5 Summary

本章主要讲解Netty的线程模型，其核心接口是EventLoop；并和OIO中的线程模型作了比较，以突显Netty的优异性。