Netty In Action中文版 - 第十五章：选择正确的线程模型

http://blog.csdn.net/abc_key/article/details/38419469

本章介绍

• 线程模型(thread-model)
• 事件循环(EventLoop)
• 并发(Concurrency)
• 任务运行(task execution)
• 任务调度(task scheduling)

线程模型定义了应用程序或框架怎样运行你的代码。选择应用程序/框架的正确的线程模型是非常重要的。Netty提供了一个简单强大的线程模型来帮助我们简化代码，Netty对全部的核心代码都进行了同步。全部ChannelHandler，包含业务逻辑。都保证由一个线程同一时候运行特定的通道。

这并不意味着Netty不能使用多线程，仅仅是Netty限制每一个连接都由一个线程处理。这样的设计适用于非堵塞程序。我们没有必要去考虑多线程中的不论什么问题，也不用操心会抛ConcurrentModificationException或其它一些问题，如数据冗余、加锁等，这些问题在使用其它框架进行开发时是常常会发生的。

读完本章就会深刻理解Netty的线程模型以及Netty团队为什么会选择这种线程模型。这些信息能够让我们在使用Netty时让程序由最好的性能。

此外，Netty提供的线程模型还能够让我们编写整洁简单的代码，以保持代码的整洁性；我们还会学习Netty团队的经验，过去使用其它的线程模型，如今我们将使用Netty提供的更easy更强大的线程模型来开发。

虽然本章讲述的是Netty的线程模型，可是我们仍然能够使用其它的线程模型。至于怎样选择一个完美的线程模型应该依据应用程序的实际需求来推断。

本章如果例如以下：

• 你明确线程是什么以及怎样使用，并有使用线程的工作经验；若不是这样，就请花些时间来了解清楚这些知识。

  推荐一本书：Java并发编程实战。

• 你了解多线程应用程序及其设计，也包含怎样保证线程安全和获取最佳性能。
• 你了解java.util.concurrent以及ExecutorService和ScheduledExecutorService。

15.1 线程模型概述

        本节将简介一般的线程模型，Netty中怎样使用指定的线程模型，以及Netty不同的版本号中使用的线程模型。你会更好的理解不同的线程模型的全部利弊。

        假设思考一下。在我们的生活中会发现非常多情况都会使用线程模型。

比如，你有一个餐厅。向你的客户提供食品，食物须要在厨房煮熟后才干给客户；某个客户下了订单后，你须要将煮熟事物这个任务发送到厨房，而厨房能够以不同的方式来处理，这就像一个线程模型，定义了怎样运行任务。

• 仅仅有一个厨师：
  • 这样的方法是单线程的。一次仅仅运行一个任务。完毕当前订单后再处理下一个。
• 你有多个厨师，每一个厨师都能够做，空暇的厨师准备着接单做饭：
  
  • 这样的方式是多线程的，任务由多个线程(厨师)运行。能够并行同一时候运行。

• 你有多个厨师并分成组，一组做晚餐，一个做其它：
  
  • 这样的情况也是多线程，可是带有额外的限制；同一时候运行多个任务是由实际运行的任务类型(晚餐或其它)决定。

从上面的样例看出。日常活动适合在一个线程模型。可是Netty在这里适用吗？不幸的是，它没有那么简单。Netty的核心是多线程，但隐藏了来自用户的大部分。

Netty使用多个线程来完毕全部的工作。仅仅有一个线程模型线型暴露给用户。大多数现代应用程序使用多个线程调度工作。让应用程序充分使用系统的资源来有效工作。在早期的Java中，这样做是通过按需创建新线程并行工作。

但非常快发现者不是完美的方案，由于创建和回收线程须要较大的开销。

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

        下图显示使用一个线程池运行一个任务。提交一个任务后会使用线程池中空暇的线程来运行，完毕任务后释放线程并将线程又一次放回线程池：

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvYWJjX2tleQ==/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast" alt="">

        上图每一个任务线程的创建和回收不须要新线程去创建和销毁。但这仅仅是一半的问题，我们稍后学习。你可能会问为什么不使用多线程，使用一个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后会更easy理解为什么新的线程模型是可取的。

15.2.3 Netty3中的I/O操作

        在曾经的版本号有点不同，Netty保证在I/O线程中仅仅有入站事件才被运行，全部的出站时间被调用线程处理。这看起来是个好方案，但非常easy出错。它还将负责同步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 调度任务运行

        每隔一段时间须要调度任务运行，或许你想注冊一个任务在client完毕连接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%准确的按时运行。

        为了更好的理解它是怎样工作，我们能够这样觉得：

1. 在指定的延迟时间后调度任务。
2. 任务被插入到EventLoop的Schedule-Task-Queue(调度任务队列)；
3. 假设任务须要立即执行。EventLoop检查每一个执行；
4. 假设有一个任务要运行，EventLoop将立马运行它，并从队列中删除。
5. EventLoop等待下一次执行。从第4步開始一遍又一遍的反复。

由于这种实现计划运行不可能100%正确，对于多数用例不可能100%准备的运行计划任务；在Netty中，这种工作差点儿没有资源开销。可是假设须要更准确的运行呢？非常easy，你须要使用ScheduledExecutorService的还有一个实现，这不是Netty的内容。

记住。假设不遵循Netty的线程模型协议，你将须要自己同步并发訪问。

15.4 I/O线程分配细节

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

        下图显示怎样分配线程池：

        如上图所看到的，使用一个固定大小的线程池管理三个线程，创建线程池后就把线程分配给线程池，确保在须要的时候，线程池中有可用的线程。

这三个线程会分配给每一个新创建的已连接通道，这是通过EventLoopGroup实现的。使用线程池来管理资源；实际会平均分配通道到全部的线程上，这样的分布以循环的方式完毕。因此它可能不会100%准确，但大部分时间是准确的。

        一个通道分配到一个线程后，在这个通道的生命周期内都会一直使用这个线程。这一点在以后的版本号中可能会被改变。所以我们不应该依赖这样的方式；不会被改变的是一个线程在同一时间仅仅会处理一个通道的I/O操作，我们能够依赖这样的方式。由于这样的方式能够确保不须要操心同步。

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

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvYWJjX2tleQ==/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast" alt="">

        从上图能够看出。每一个通道都有一个单独的线程。

我们能够使用java.io.*包里的类来开发基于堵塞I/O的应用程序，即使语义改变了。但有一件事仍然保持不变，每一个通道的I/O在同一时候仅仅能被一个线程处理；这个线程是由Channel的EventLoop提供，我们能够依靠这个硬性的规则，这也是Netty框架比其它网络框架更easy编写的原因。

15.5 Summary

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