Netty In Action中文版 - 第十五章:选择正确的线程模型
本章介绍
- 线程模型(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使用多个线程来完成所有的工作,只有一个线程模型线型暴露给用户。大多数现代应用程序使用多个线程调度工作,让应用程序充分使用系统的资源来有效工作。在早期的Java中,这样做是通过按需创建新线程并行工作。但很快发现者不是完美的方案,因为创建和回收线程需要较大的开销。在Java5中加入了线程池,创建线程和重用线程交给一个任务执行,这样使创建和回收线程的开销降到最低。
15.2 事件循环
15.2.1 使用事件循环
- Channel ch = ...;
- ch.eventLoop().execute(new Runnable() {
- @Override
- public void run() {
- System.out.println("run in the eventloop");
- }
- });
- 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操作
15.2.3 Netty3中的I/O操作
- 字节写入到远程对等通道有多快
- I/O线程是否繁忙
- 上下文切换
- 锁定
你可以看到很多细节影响整体延迟。
15.2.4 Netty线程模型内部
15.3 调度任务执行
15.3.1 使用普通的Java API调度任务
- 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对这个问题提供了很好的方法。
- 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的线程模型协议,你将需要自己同步并发访问。