Netty实战七之EventLoop和线程模型

简单地说,线程模型指定了操作系统、编程语言、框架或者应用程序的上下文中的线程管理的关键方面。Netty的线程模型强大但又易用,并且和Netty的一贯宗旨一样,旨在简化你的应用程序代码,同时最大限度地提高性能和可维护性。

1、线程模型概述

线程模型确定了代码的执行方式,由于我们总是必须规避并发执行可能会带来的副作用,所以理解所采用的并发模型(也有单线程的线程模型)的影响很重要。

因为具有多核心或多个CPU的计算机现在已经司空见惯,大多数的现代应用程序都利用了复杂的多线程处理技术以有效地利用系统资源。相比之下,在早期的Java语言中,我们使用多线程处理的主要方式无非是按需创建和启动新的Thread来执行并发的任务单元——一种在高负载下工作得很差的原始方式。Java 5随后引入了Executor API,其线程池通过缓存和重用Thread极大地提高了性能。

基本的线程池化模式可以描述为:

——从池的空闲线程列表中选择一个Thread,并且指派它去运行一个已提交的任务(一个Runnable的说笑呢)

——当任务完成时,将该Thread返回给该列表,使其可被重用。

下图说明了这个模型 虽然池化和重用线程相对简单地为每个任务都创建和销毁线程是一种进步,但是它并不能消除由上下文切换所带来的开销,其将随着线程数量的增加很快变得明显,并且在高负载下愈演愈烈。此外,仅仅由于应用程序的整体复杂性或者并发需求,在项目的声明周期内也可能会出现其他的线程相关的问题。

2、EventLoop接口

运行任务来处理在连接的生命周期内发生的事件是任何网络框架的基本功能。与之相应的编程上的构造通常被称为事件循环——一个Netty使用了Interface io.netty.channel.EventLoop来适配的术语。

以下代码说明了事件循环的基本思想,其中的每个任务都是一个Runnable的实例。

while(!terminated){
            //阻塞,直到有事件已经就绪可被运行
            List<Runnable> readyEvents = blockUntilEventReady();
            for (Runnable ev:readyEvents){
                //循环遍历,并处理所有的事件
                ev.run();
            }
        }

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

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

需要注意的是,Netty的EventLoop在继承了ScheduledExecutorService的同时,只定义了一个方法,parent(),用于返回到当前EventLoop实现的实例所属的EventLoopGroup的引用。

事件/任务的执行顺序:事件和任务是以先进先出(FIFO)的顺序执行的,这样可以通过保证字节内容总是按正确的顺序被处理,消除潜在的数据损坏的可能性。

3、Netty4中的I/O和事件处理

由I/O操作触发的事件将流经安装了一个或者多个ChannelHandler的ChannelPipeline。传播这些事件的方法调用可以随后被ChannelHandler所拦截,并且可以按需地处理事件。

事件的性质通常决定了它将被如何处理,他可能将数据从网络栈中传递到你的应用程度中,或者进行逆向操作,或者执行一些截然不同的操作。但是事件的处理逻辑必须足够的通用和灵活,以处理所有可能的用例。因此,在Netty4中,所有I/O操作和事件都由已经被分配给了EventLoop的那个Thread来处理。

4、Netty3中的I/O操作

在以前的版本中所使用的线程模型只保证了入站(之前称为上游)事件会在所谓的I/O线程(对应于Netty4中的EventLoop)中执行。所有的出站(下游)事件都由调用线程处理,其可能是I/O线程也可能是别的线程。开始看起来似乎是好主意,但是已经被发现是有问题的,因为需要在ChannelHandler中对出站事件进行仔细的同步。简而言之,不可能保证多个线程不会再同一时刻尝试访问出站事件。例如,如果你通过在不同的线程中调用Channel.write()方法,针对同一个Channel同时触发出站的事件,就会发生这种情况。

当出站事件触发了入站事件时,将会导致另一个负面影响。当Channel.write()方法导致异常时,需要生成并触发一个exceptionCaught事件。但是在Netty3的模型中,由于这是一个入站事件,需要在调用线程中执行代码,然后将事件移交给I/O线程去执行,然而这将带来额外的上下文切换。

Netty4中所采用的线程模型,通过在同一个线程中处理某个给定的EventLoop中所产生的所有事件,解决了这个问题。这提供了一个更加简单的执行体系架构,并且消除了在多个ChannelHandler中进行同步的需要。

5、JDK的任务调度

你需要调度一个任务以便稍后(延迟)执行或者周期性地执行。例如,你可能想要注册一个在客户端已经连接了5分钟之后触发的任务。一个常见的用例是,发送心跳信息到远程节点,以检查连接是否仍然还活着。如果没有响应,你便知道可以关闭该Channel了。

在Java5之前,任务调度时建立在java.util.Timer类之上,其使用了一个后台Thread,并且具有与标准线程相同的限制。随后,JDK提供了java.util.concurrent包,它定义了interface ScheduledExecutorService。

虽然选择不多,但是这些预置的实现已经足够应对大多数的用例。

以下代码展示了如何使用ScheduledExecutorService来在60秒的延迟之后执行一个任务。

//创建一个其线程池具有10个线程的ScheduledExecutorService
        ScheduledExecutorService executorService = Executors.newScheduledThreadPool(10);
        //创建一个Runnable,以供调度稍后执行
        ScheduledFuture<?> future = executorService.schedule(new Runnable() {
            @Override
            public void run() {
                //该任务要打印的消息
                System.out.println("60 seconds later");
            }
            //调度任务在从现在开始的60秒之后执行
        },60, TimeUnit.SECONDS);
        ...
        //一旦调度任务执行完成,就关闭ScheduledExecutorService以释放资源
        executorService.shutdown();

虽然ScheduledExecutorService API是直接了当的,当时在高负载下它将带来性能上的负担。

6、使用EventLoop调度任务

ScheduledExecutorService的实现具有局限性,例如,事实上作为线程池管理的一部分,将会有额外的线程创建。如果有大量任务被紧凑地调度,那么这将成为一个瓶颈。Netty通过Channel的EventLoop实现任务调度解决了这一问题。

经过60秒之后,Runnable实例将由分配给Channel的EventLoop执行。如果要调度任务以每隔60秒执行一次,请使用sheduleAtFixedRate()方法,如以下代码。

Channel ch = ...;
        ScheduledFuture<?> future = ch.eventLoop().schedule(
                //创建一个Runnable以供调度稍后执行
                new Runnable() {
                    @Override
                    public void run() {
                        //要执行的代码
                        System.out.println("60 seconds later");
                    }
                    //调度任务在从现在开始的60秒之后执行
                },60,TimeUnit.SECONDS
        );

如前面提到的,Netty的EventLoop扩展了ScheduledExecutorService,所有它提供了JDK实现可用的所有方法,包括前面的schedule()和scheduleAtFixedRate()方法。所有操作的完整列表可以在ScheduledExecutorService的Javadoc中找到。

要取消或者检查(被调度任务)执行状态,可以使用每个异步操作所返回的ScheduledFuture。

以下代码展示了一个简单的取消操作。

Channel ch = ...;
        //调度任务,并获得所返回的ScheduledFuture
        ScheduledFuture<?> future = ch.eventLoop().scheduleAtFixedRate(...);
        //some other code that runs...
        boolean mayInterruptIfRunning = false;
        //取消该任务,防止它再次运行
        future.cancel(mayInterruptIfRunning);

7、线程管理

Netty线程模型的卓越性能取决于对于当前执行的Thread的身份的确定,也就是说,确定它是否分配给当前Channel以及它的EventLoop的那一线程。

如果调用线程正是支撑EventLoop的线程,那么所提交的代码块将会被执行。否则,EventLoop将调度该任务以便稍后执行,并将它放入到内部队列中。当EventLoop下次处理它的事件时,它会执行队列中的那些任务/事件。这也是任何的Thread是如何与Channel直接交互而无需在ChannelHandler中进行额外同步的。

注意,每个EventLoop都有它自己的任务队列,独立于任何其他的EventLoop。下图展示了EventLoop用于调度任务的执行逻辑。这也是Netty线程模型的关键组成部分。 之前已经阐明了不要阻塞当前I/O线程的重要性。我们再以另一种方式重申一次:“永远不要将一个长时间运行的任务放入到执行队列中,因为它将阻塞需要在同一线程上执行的任何其他任务。”如果必须要进行阻塞调用或者执行长时间运行的任务,我们建议使用一个专门的EventExecutor。

除了这种受限的场景,如同传输所采用的不同的事件处理实现一样,所使用的线程模型也可以强烈地影响到排队的任务对整体系统性能的影响。

8、EventLoop线程的分配——异步传输

异步传输实现只使用了少量的EventLoop,而且在当前的线程模型中,它们可能会被多个Channel所共享,这使得可以通过尽可能少量的Thread来支撑大量的Channel,而不是每个Channel分配一个Thread。

下图显示了一个EventLoopGroup,它具有3个固定大小的EventLoop(每个EventLoop都由一个Thread支撑)。在创建EventLoopGroup时就直接分配了EventLoop(以及支撑它们的Thread),以确保在需要时它们是可用的。 EventLoopGroup负责为每个新创建的Channel分配一个EventLoop。在当前实现中,使用顺序循环(round-robin)的方式进行分配以获取一个均衡的分布,并且相同的EventLoop可能会被分配给多个Channel。

一旦一个Channel被分配给一个EventLoop,它将在它的整个生命周期中都是用这个EventLoop,请注意,因为它可以使你从担忧你的ChannelHandler实现中的线程安全和同步问题中解脱出来。

另外,需要注意的是,EventLoop的分配方式对ThreadLocal的使用的影响。因为一个EventLoop通常会被用于支撑多个Channel,所以对于所有相关联的Channel来说,ThreadLocal都将是一样的。这使得它对于实现状态追踪等功能来说是个糟糕的选择。然而,在一些无状态的上下文中,它仍然可以被用于在多个Channel之间共享一些重度的或者代价昂贵的对象,甚至是事件。

9、阻塞传输

用于像OIO(旧的阻塞I/O)这样的其它传输的设计略有不同,如下图所示。 这里每一个Channel都将被分配给一个EventLoop(以及他的Thread)。如果你开发的应用程序使用过java.io包中的阻塞I/O实现,你可能就遇到过这种模型。

但是,正如同之前一样,得到的保证是每个Channel的I/O事件都只会被一个Thread(用于支撑该Channel的EventLoop的那个Thread)处理。这也是另一个Netty设计一致性的例子。

原文地址:https://www.cnblogs.com/UncleCatMySelf/p/9190621.html

时间: 2024-10-12 22:42:29

Netty实战七之EventLoop和线程模型的相关文章

Netty in Action (十七) 第七章节 EventLoop和线程模型

本章节包括: 1)线程模型总览 2)Event Loop概念和具体实现 3)任务调度 4)实现细节 简单地陈述一下,对于一个操作系统,编程语言,框架,或者应用来说,线程模型对其都是至关重要的一部分,在什么时间如何创建一个线程都会对你的代码执行有很重要的影响,所以对于开发人员而言,懂得在各种线程模型里面权衡利弊就是一个很重要的事情,是直接使用线程模型本身还是通过一些框架或者语言提供的线程框架对于开发者而言都是需要选择的 在这个章节,我们将会详细地讲解Netty的线程模型,这个模型是很强大的,且易于

Netty线程模型

一.Reactor模型 1.单线程模型 Reactor单线程模型,指的是所有的IO操作都在同一个NIO线程上面完成,NIO线程的职责如下: 1)作为NIO服务端,接收客户端的TCP连接: 2)作为NIO客户端,向服务端发起TCP连接: 3)读取通信对端的请求或者应答消息: 4)向通信对端发送消息请求或者应答消息 Reactor单线程模型示意图如下所示: 由于Reactor模式使用的是异步非阻塞IO,所有的IO操作都不会导致阻塞,理论上一个线程可以独立处理所有IO相关的操作.从架构层面看,一个NI

Netty系列之Netty线程模型

1. 背景 1.1. Java线程模型的演进 1.1.1. 单线程 时间回到十几年前,那时主流的CPU都还是单核(除了商用高性能的小机),CPU的核心频率是机器最重要的指标之一. 在Java领域当时比较流行的是单线程编程,对于CPU密集型的应用程序而言,频繁的通过多线程进行协作和抢占时间片反而会降低性能. 1.1.2. 多线程 随着硬件性能的提升,CPU的核数越来越越多,很多服务器标配已经达到32或64核.通过多线程并发编程,可以充分利用多核CPU的处理能力,提升系统的处理效率和并发性能. 相关

Netty IO线程模型学习总结

Netty框架的 主要线程是IO线程,线程模型的好坏直接决定了系统的吞吐量.并发性和安全性. Netty的线程模型遵循了Reactor的基础线程模型.下面我们先一起看下该模型 Reactor线程模型 Reactor 单线程模型 单线程模型中所有的IO操作都在一个NIO线程上操作: 包含接受客户端的请求,读取客户端的消息和应答.由于使用的是异步非阻塞的IO,所有的IO操作不会阻塞,理论上一个线程就可以处理所有的IO操作. 单线程模型适用小容量的应用.因为在高并发应用 可导致以下问题 一个线程同时处

Mina、Netty、Twisted一起学(十):线程模型

要想开发一个高性能的TCPserver,熟悉所使用框架的线程模型非常重要.MINA.Netty.Twisted本身都是高性能的网络框架,假设再搭配上高效率的代码.才干实现一个高大上的server. 可是假设不了解它们的线程模型.就非常难写出高性能的代码.框架本身效率再高.程序写的太差,那么server总体的性能也不会太高.就像一个电脑,CPU再好.内存小硬盘慢散热差,总体的性能也不会太高. 玩过Android开发的同学会知道,在Android应用中有一个非常重要线程:UI线程(即主线程). UI

Mina、Netty线程模型

Reactor线程模型 ???????Reactor是反应堆的意思,Reactor模式即Dispatcher模式,服务器程序处理传入的多路请求,将他们同步分派给各请求对应的处理线程. ???????Reactor有两个关键角色: ??????? Reactor Reactor在一个单独线程中运行,负责监听和分发事件,将请求事件分发给处理线程来对IO事件作出反应. ??????? Handlers 处理程序执行IO事件完成响应的事件操作. 根据Reactor和Handler数量的不同,Reacto

【转】netty线程模型

Netty服务器线程模型概览 博客分类: netty java 一切从ServerBootstrap开始 ServerBootstrap 负责初始话netty服务器,并且开始监听端口的socket请求. Java代码   bootstrap bootstrap = new ServerBootstrap( new NioServerSocketChannelFactory( Executors.newCachedThreadPool(),//boss线程池 Executors.newCached

Netty的线程模型

当我们讨论Netty线程模型的时候,一般首先会想到的是经典的Reactor线程模型,尽管不同的NIO框架对于Reactor模式的实现存在差异,但本质上还是遵循了Reactor的基础线程模型.下面浅谈一下我对Reactor线程模型的认识 1.Reactor单线程模型,是指所有的I/O操作都在同一个NIO线程上面完成.NIO线程的职责如下 作为NIO服务端,接收客户端的TCP连接 作为NIO客户端,向服务端发起TCP连接 读取通信对端的请求或者应答消息 向通信对端发送消息请求或者应答消息 对于小容量

Netty 线程模型

关于Java NIO Reactor模式http://my.oschina.net/xinxingegeya/blog/339027 下面是线程模型的演进 Thread per Connection Thread per Connection: 在没有nio之前,这是传统的java网络编程方案所采用的线程模型.即有一个主循环,socket.accept阻塞等待,当建立连接后,创建新的线程/从线程池中取一个,把该socket连接交由新线程全权处理.这种方案优缺点都很明显,优点即实现简单,缺点则是方