新手入门：目前为止最透彻的的Netty高性能原理和框架架构解析(阿里)

想了解AIO,BIO NIO Reactor 请参考：IO复用,AIO,BIO,NIO,同步，异步，阻塞和非阻塞 区别(百度)

一、引言

Netty 是一个广受欢迎的异步事件驱动的Java开源网络应用程序框架，用于快速开发可维护的高性能协议服务器和客户端。

本文基于 Netty 4.1 展开介绍相关理论模型，使用场景，基本组件、总体架构，知其然且知其因此然，但愿给你们在实际开发实践、学习开源项目方面提供参考。

本文做者的另两篇《高性能网络编程(五)：一文读懂高性能网络编程中的I/O模型》、《高性能网络编程(六)：一文读懂高性能网络编程中的线程模型》也写的很好，有兴趣的读者能够一并看看。

二、相关资料

Netty源码在线阅读：

Netty-4.1.x地址是：http://docs.52im.net/extend/docs/src/netty4_1/

Netty-4.0.x地址是：http://docs.52im.net/extend/docs/src/netty4/

Netty-3.x地址是：http://docs.52im.net/extend/docs/src/netty3/

Netty在线API文档：

Netty-4.1.x API文档(在线版)：http://docs.52im.net/extend/docs/api/netty4_1/

Netty-4.0.x API文档(在线版)：http://docs.52im.net/extend/docs/api/netty4/

Netty-3.x API文档(在线版)：http://docs.52im.net/extend/docs/api/netty3/

有关Netty的其它精华文章：

《有关“为什么选择Netty”的11个疑问及解答》

《开源NIO框架八卦——究竟是先有MINA仍是先有Netty?》

《选Netty仍是Mina：深刻研究与对比（一）》

《选Netty仍是Mina：深刻研究与对比（二）》

《Netty 4.x学习（一）：ByteBuf详解》

《Netty 4.x学习（二）：Channel和Pipeline详解》

《Netty 4.x学习（三）：线程模型详解》

《实践总结：Netty3.x升级Netty4.x遇到的那些坑（线程篇）》

《实践总结：Netty3.x VS Netty4.x的线程模型》

《详解Netty的安全性：原理介绍、代码演示（上篇）》

《详解Netty的安全性：原理介绍、代码演示（下篇）》

《详解Netty的优雅退出机制和原理》

《NIO框架详解：Netty的高性能之道》

《Twitter：如何使用Netty 4来减小JVM的GC开销（译文）》

《绝对干货：基于Netty实现海量接入的推送服务技术要点》

《Netty干货分享：京东京麦的生产级TCP网关技术实践总结》

三、JDK 原生 NIO 程序的问题

JDK 原生也有一套网络应用程序 API，可是存在一系列问题，主要以下：

1）NIO 的类库和 API 繁杂，使用麻烦：你须要熟练掌握 Selector、ServerSocketChannel、SocketChannel、ByteBuffer 等。

2）须要具有其余的额外技能作铺垫：例如熟悉 Java 多线程编程，由于 NIO 编程涉及到 Reactor 模式，你必须对多线程和网路编程很是熟悉，才能编写出高质量的 NIO 程序。

3）可靠性能力补齐，开发工做量和难度都很是大：例如客户端面临断连重连、网络闪断、半包读写、失败缓存、网络拥塞和异常码流的处理等等。NIO 编程的特色是功能开发相对容易，可是可靠性能力补齐工做量和难度都很是大。

4）JDK NIO 的 Bug：例如臭名昭著的 Epoll Bug，它会致使 Selector 空轮询，最终致使 CPU 100%。官方声称在 JDK 1.6 版本的 update 18 修复了该问题，可是直到 JDK 1.7 版本该问题仍旧存在，只不过该 Bug 发生几率下降了一些而已，它并无被根本解决。

四、Netty 的特色

Netty 对 JDK 自带的 NIO 的 API 进行了封装，解决了上述问题。

Netty的主要特色有：

1）设计优雅：适用于各类传输类型的统一 API 阻塞和非阻塞 Socket；基于灵活且可扩展的事件模型，能够清晰地分离关注点；高度可定制的线程模型 - 单线程，一个或多个线程池；真正的无链接数据报套接字支持（自 3.1 起）。

2）使用方便：详细记录的 Javadoc，用户指南和示例；没有其余依赖项，JDK 5（Netty 3.x）或 6（Netty 4.x）就足够了。

3）高性能、吞吐量更高：延迟更低；减小资源消耗；最小化没必要要的内存复制。

4）安全：完整的 SSL/TLS 和 StartTLS 支持。

5）社区活跃、不断更新：社区活跃，版本迭代周期短，发现的 Bug 能够被及时修复，同时，更多的新功能会被加入。

五、Netty 常见使用场景

Netty 常见的使用场景以下：

1）互联网行业：在分布式系统中，各个节点之间须要远程服务调用，高性能的 RPC 框架必不可少，Netty 做为异步高性能的通讯框架，每每做为基础通讯组件被这些 RPC 框架使用。典型的应用有：阿里分布式服务框架 Dubbo 的 RPC 框架使用 Dubbo 协议进行节点间通讯，Dubbo 协议默认使用 Netty 做为基础通讯组件，用于实现各进程节点之间的内部通讯。

2）游戏行业：不管是手游服务端仍是大型的网络游戏，Java 语言获得了愈来愈普遍的应用。Netty 做为高性能的基础通讯组件，它自己提供了 TCP/UDP 和 HTTP 协议栈。

很是方便定制和开发私有协议栈，帐号登陆服务器，地图服务器之间能够方便的经过 Netty 进行高性能的通讯。

3）大数据领域：经典的 Hadoop 的高性能通讯和序列化组件 Avro 的 RPC 框架，默认采用 Netty 进行跨界点通讯，它的 Netty Service 基于 Netty 框架二次封装实现。

有兴趣的读者能够了解一下目前有哪些开源项目使用了 Netty的Related Projects。

六、Netty 高性能设计

Netty 做为异步事件驱动的网络，高性能之处主要来自于其 I/O 模型和线程处理模型，前者决定如何收发数据，后者决定如何处理数据。

6.1 I/O 模型

用什么样的通道将数据发送给对方，BIO、NIO 或者 AIO，I/O 模型在很大程度上决定了框架的性能。

【阻塞 I/O】：

传统阻塞型 I/O(BIO)能够用下图表示：

 

特色以下：

每一个请求都须要独立的线程完成数据 Read，业务处理，数据 Write 的完整操做问题。

当并发数较大时，须要建立大量线程来处理链接，系统资源占用较大。

链接创建后，若是当前线程暂时没有数据可读，则线程就阻塞在 Read 操做上，形成线程资源浪费。

【I/O 复用模型】：

 

在 I/O 复用模型中，会用到 Select，这个函数也会使进程阻塞，可是和阻塞 I/O 所不一样的是这两个函数能够同时阻塞多个 I/O 操做。

并且能够同时对多个读操做，多个写操做的 I/O 函数进行检测，直到有数据可读或可写时，才真正调用 I/O 操做函数。

Netty 的非阻塞 I/O 的实现关键是基于 I/O 复用模型，这里用 Selector 对象表示：

 

Netty 的 IO 线程 NioEventLoop 因为聚合了多路复用器 Selector，能够同时并发处理成百上千个客户端链接。

当线程从某客户端 Socket 通道进行读写数据时，若没有数据可用时，该线程能够进行其余任务。

线程一般将非阻塞 IO 的空闲时间用于在其余通道上执行 IO 操做，因此单独的线程能够管理多个输入和输出通道。

因为读写操做都是非阻塞的，这就能够充分提高 IO 线程的运行效率，避免因为频繁 I/O 阻塞致使的线程挂起。

一个 I/O 线程能够并发处理 N 个客户端链接和读写操做，这从根本上解决了传统同步阻塞 I/O 一链接一线程模型，架构的性能、弹性伸缩能力和可靠性都获得了极大的提高。

【基于 Buffer】：

传统的 I/O 是面向字节流或字符流的，以流式的方式顺序地从一个 Stream 中读取一个或多个字节, 所以也就不能随意改变读取指针的位置。

在 NIO 中，抛弃了传统的 I/O 流，而是引入了 Channel 和 Buffer 的概念。在 NIO 中，只能从 Channel 中读取数据到 Buffer 中或将数据从 Buffer 中写入到 Channel。

基于 Buffer 操做不像传统 IO 的顺序操做，NIO 中能够随意地读取任意位置的数据。

6.2 线程模型

数据报如何读取？读取以后的编解码在哪一个线程进行，编解码后的消息如何派发，线程模型的不一样，对性能的影响也很是大。

【事件驱动模型】：

一般，咱们设计一个事件处理模型的程序有两种思路：

1）轮询方式：线程不断轮询访问相关事件发生源有没有发生事件，有发生事件就调用事件处理逻辑；

2）事件驱动方式：发生事件，主线程把事件放入事件队列，在另外线程不断循环消费事件列表中的事件，调用事件对应的处理逻辑处理事件。事件驱动方式也被称为消息通知方式，实际上是设计模式中观察者模式的思路。

以 GUI 的逻辑处理为例，说明两种逻辑的不一样：

1）轮询方式：线程不断轮询是否发生按钮点击事件，若是发生，调用处理逻辑。

2）事件驱动方式：发生点击事件把事件放入事件队列，在另外线程消费的事件列表中的事件，根据事件类型调用相关事件处理逻辑。

这里借用 O'Reilly 大神关于事件驱动模型解释图：

 

主要包括 4 个基本组件：

1）事件队列（event queue）：接收事件的入口，存储待处理事件；

2）分发器（event mediator）：将不一样的事件分发到不一样的业务逻辑单元；

3）事件通道（event channel）：分发器与处理器之间的联系渠道；

4）事件处理器（event processor）：实现业务逻辑，处理完成后会发出事件，触发下一步操做。

能够看出，相对传统轮询模式，事件驱动有以下优势：

1）可扩展性好：分布式的异步架构，事件处理器之间高度解耦，能够方便扩展事件处理逻辑；

2）高性能：基于队列暂存事件，能方便并行异步处理事件。

【Reactor 线程模型】：

Reactor 是反应堆的意思，Reactor 模型是指经过一个或多个输入同时传递给服务处理器的服务请求的事件驱动处理模式。

服务端程序处理传入多路请求，并将它们同步分派给请求对应的处理线程，Reactor 模式也叫 Dispatcher 模式，即 I/O 多了复用统一监听事件，收到事件后分发(Dispatch 给某进程)，是编写高性能网络服务器的必备技术之一。

Reactor 模型中有 2 个关键组成：

1）Reactor：Reactor 在一个单独的线程中运行，负责监听和分发事件，分发给适当的处理程序来对 IO 事件作出反应。它就像公司的电话接线员，它接听来自客户的电话并将线路转移到适当的联系人；

2）Handlers：处理程序执行 I/O 事件要完成的实际事件，相似于客户想要与之交谈的公司中的实际官员。Reactor 经过调度适当的处理程序来响应 I/O 事件，处理程序执行非阻塞操做。

 

取决于 Reactor 的数量和 Hanndler 线程数量的不一样，Reactor 模型有 3 个变种：

1）单 Reactor 单线程；

2）单 Reactor 多线程；

3）主从 Reactor 多线程。

能够这样理解，Reactor 就是一个执行 while (true) { selector.select(); …} 循环的线程，会源源不断的产生新的事件，称做反应堆很贴切。

篇幅关系，这里再也不具体展开 Reactor 特性、优缺点比较，有兴趣的读者能够参考我以前另一篇文章：《高性能网络编程(五)：一文读懂高性能网络编程中的I/O模型》、《高性能网络编程(六)：一文读懂高性能网络编程中的线程模型》。

【Netty 线程模型】：

Netty 主要基于主从 Reactors 多线程模型（以下图）作了必定的修改，其中主从 Reactor 多线程模型有多个 Reactor：

1）MainReactor 负责客户端的链接请求，并将请求转交给 SubReactor；

2）SubReactor 负责相应通道的 IO 读写请求；

3）非 IO 请求（具体逻辑处理）的任务则会直接写入队列，等待 worker threads 进行处理。

这里引用 Doug Lee 大神的 Reactor 介绍——Scalable IO in Java 里面关于主从 Reactor 多线程模型的图：

 

特别说明的是：虽然 Netty 的线程模型基于主从 Reactor 多线程，借用了 MainReactor 和 SubReactor 的结构。可是实际实现上 SubReactor 和 Worker 线程在同一个线程池中： 

EventLoopGroup bossGroup = newNioEventLoopGroup(); EventLoopGroup workerGroup = newNioEventLoopGroup(); ServerBootstrap server = newServerBootstrap(); server.group(bossGroup, workerGroup) .channel(NioServerSocketChannel.class)

 

上面代码中的 bossGroup 和 workerGroup 是 Bootstrap 构造方法中传入的两个对象，这两个 group 均是线程池：

1）bossGroup 线程池则只是在 Bind 某个端口后，得到其中一个线程做为 MainReactor，专门处理端口的 Accept 事件，每一个端口对应一个 Boss 线程；

2）workerGroup 线程池会被各个 SubReactor 和 Worker 线程充分利用。

【异步处理】：

异步的概念和同步相对。当一个异步过程调用发出后，调用者不能马上获得结果。实际处理这个调用的部件在完成后，经过状态、通知和回调来通知调用者。

Netty 中的 I/O 操做是异步的，包括 Bind、Write、Connect 等操做会简单的返回一个 ChannelFuture。

调用者并不能马上得到结果，而是经过 Future-Listener 机制，用户能够方便的主动获取或者经过通知机制得到 IO 操做结果。

当 Future 对象刚刚建立时，处于非完成状态，调用者能够经过返回的 ChannelFuture 来获取操做执行的状态，注册监听函数来执行完成后的操做。

常见有以下操做：

1）经过 isDone 方法来判断当前操做是否完成；

2）经过 isSuccess 方法来判断已完成的当前操做是否成功；

3）经过 getCause 方法来获取已完成的当前操做失败的缘由；

4）经过 isCancelled 方法来判断已完成的当前操做是否被取消；

5）经过 addListener 方法来注册监听器，当操做已完成(isDone 方法返回完成)，将会通知指定的监听器；若是 Future 对象已完成，则理解通知指定的监听器。

例以下面的代码中绑定端口是异步操做，当绑定操做处理完，将会调用相应的监听器处理逻辑： 

serverBootstrap.bind(port).addListener(future -> { if(future.isSuccess()) { System.out.println(newDate() + ": 端口["+ port + "]绑定成功!"); } else{ System.err.println("端口["+ port + "]绑定失败!"); } });

 

相比传统阻塞 I/O，执行 I/O 操做后线程会被阻塞住, 直到操做完成；异步处理的好处是不会形成线程阻塞，线程在 I/O 操做期间能够执行别的程序，在高并发情形下会更稳定和更高的吞吐量。

七、Netty框架的架构设计

前面介绍完 Netty 相关一些理论，下面从功能特性、模块组件、运做过程来介绍 Netty 的架构设计。

7.1 功能特性

 

Netty 功能特性以下：

1）传输服务：支持 BIO 和 NIO；

2）容器集成：支持 OSGI、JBossMC、Spring、Guice 容器；

3）协议支持：HTTP、Protobuf、二进制、文本、WebSocket 等一系列常见协议都支持。还支持经过实行编码解码逻辑来实现自定义协议；

4）Core 核心：可扩展事件模型、通用通讯 API、支持零拷贝的 ByteBuf 缓冲对象。

7.2 模块组件

【Bootstrap、ServerBootstrap】：

Bootstrap 意思是引导，一个 Netty 应用一般由一个 Bootstrap 开始，主要做用是配置整个 Netty 程序，串联各个组件，Netty 中 Bootstrap 类是客户端程序的启动引导类，ServerBootstrap 是服务端启动引导类。

【Future、ChannelFuture】：

正如前面介绍，在 Netty 中全部的 IO 操做都是异步的，不能马上得知消息是否被正确处理。

可是能够过一会等它执行完成或者直接注册一个监听，具体的实现就是经过 Future 和 ChannelFutures，他们能够注册一个监听，当操做执行成功或失败时监听会自动触发注册的监听事件。

【Channel】：

Netty 网络通讯的组件，可以用于执行网络 I/O 操做。Channel 为用户提供：

1）当前网络链接的通道的状态（例如是否打开？是否已链接？）

2）网络链接的配置参数 （例如接收缓冲区大小）

3）提供异步的网络 I/O 操做(如创建链接，读写，绑定端口)，异步调用意味着任何 I/O 调用都将当即返回，而且不保证在调用结束时所请求的 I/O 操做已完成。

4）调用当即返回一个 ChannelFuture 实例，经过注册监听器到 ChannelFuture 上，能够 I/O 操做成功、失败或取消时回调通知调用方。

5）支持关联 I/O 操做与对应的处理程序。

不一样协议、不一样的阻塞类型的链接都有不一样的 Channel 类型与之对应。

下面是一些经常使用的 Channel 类型：

NioSocketChannel，异步的客户端 TCP Socket 链接。

NioServerSocketChannel，异步的服务器端 TCP Socket 链接。

NioDatagramChannel，异步的 UDP 链接。

NioSctpChannel，异步的客户端 Sctp 链接。

NioSctpServerChannel，异步的 Sctp 服务器端链接，这些通道涵盖了 UDP 和 TCP 网络 IO 以及文件 IO。

【Selector】：

Netty 基于 Selector 对象实现 I/O 多路复用，经过 Selector 一个线程能够监听多个链接的 Channel 事件。

当向一个 Selector 中注册 Channel 后，Selector 内部的机制就能够自动不断地查询(Select) 这些注册的 Channel 是否有已就绪的 I/O 事件（例如可读，可写，网络链接完成等），这样程序就能够很简单地使用一个线程高效地管理多个 Channel 。

【NioEventLoop】：

NioEventLoop 中维护了一个线程和任务队列，支持异步提交执行任务，线程启动时会调用 NioEventLoop 的 run 方法，执行 I/O 任务和非 I/O 任务：

I/O 任务，即 selectionKey 中 ready 的事件，如 accept、connect、read、write 等，由 processSelectedKeys 方法触发。

非 IO 任务，添加到 taskQueue 中的任务，如 register0、bind0 等任务，由 runAllTasks 方法触发。

两种任务的执行时间比由变量 ioRatio 控制，默认为 50，则表示容许非 IO 任务执行的时间与 IO 任务的执行时间相等。

【NioEventLoopGroup】：

NioEventLoopGroup，主要管理 eventLoop 的生命周期，能够理解为一个线程池，内部维护了一组线程，每一个线程(NioEventLoop)负责处理多个 Channel 上的事件，而一个 Channel 只对应于一个线程。

【ChannelHandler】：

ChannelHandler 是一个接口，处理 I/O 事件或拦截 I/O 操做，并将其转发到其 ChannelPipeline(业务处理链)中的下一个处理程序。

ChannelHandler 自己并无提供不少方法，由于这个接口有许多的方法须要实现，方便使用期间，能够继承它的子类：

ChannelInboundHandler 用于处理入站 I/O 事件。

ChannelOutboundHandler 用于处理出站 I/O 操做。

或者使用如下适配器类：

ChannelInboundHandlerAdapter 用于处理入站 I/O 事件。

ChannelOutboundHandlerAdapter 用于处理出站 I/O 操做。

ChannelDuplexHandler 用于处理入站和出站事件。

【ChannelHandlerContext】：

保存 Channel 相关的全部上下文信息，同时关联一个 ChannelHandler 对象。

【ChannelPipline】：

保存 ChannelHandler 的 List，用于处理或拦截 Channel 的入站事件和出站操做。

ChannelPipeline 实现了一种高级形式的拦截过滤器模式，使用户能够彻底控制事件的处理方式，以及 Channel 中各个的 ChannelHandler 如何相互交互。

下图引用 Netty 的 Javadoc 4.1 中 ChannelPipeline 的说明，描述了 ChannelPipeline 中 ChannelHandler 一般如何处理 I/O 事件。

I/O 事件由 ChannelInboundHandler 或 ChannelOutboundHandler 处理，并经过调用 ChannelHandlerContext 中定义的事件传播方法。

例如：ChannelHandlerContext.fireChannelRead（Object）和 ChannelOutboundInvoker.write（Object）转发到其最近的处理程序。

 

入站事件由自下而上方向的入站处理程序处理，如图左侧所示。入站 Handler 处理程序一般处理由图底部的 I/O 线程生成的入站数据。

一般经过实际输入操做（例如 SocketChannel.read（ByteBuffer））从远程读取入站数据。

出站事件由上下方向处理，如图右侧所示。出站 Handler 处理程序一般会生成或转换出站传输，例如 write 请求。

I/O 线程一般执行实际的输出操做，例如 SocketChannel.write（ByteBuffer）。

在 Netty 中每一个 Channel 都有且仅有一个 ChannelPipeline 与之对应，它们的组成关系以下：

 

一个 Channel 包含了一个 ChannelPipeline，而 ChannelPipeline 中又维护了一个由 ChannelHandlerContext 组成的双向链表，而且每一个 ChannelHandlerContext 中又关联着一个 ChannelHandler。

入站事件和出站事件在一个双向链表中，入站事件会从链表 head 日后传递到最后一个入站的 handler，出站事件会从链表 tail 往前传递到最前一个出站的 handler，两种类型的 handler 互不干扰。

八、Netty框架的工做原理

典型的初始化并启动 Netty 服务端的过程代码以下：

publicstaticvoidmain(String[] args) {

       // 建立mainReactor

       NioEventLoopGroup boosGroup = newNioEventLoopGroup();

       // 建立工做线程组

       NioEventLoopGroup workerGroup = newNioEventLoopGroup();

 

       finalServerBootstrap serverBootstrap = newServerBootstrap();

       serverBootstrap

                // 组装NioEventLoopGroup

               .group(boosGroup, workerGroup)

                // 设置channel类型为NIO类型

               .channel(NioServerSocketChannel.class)

               // 设置链接配置参数

               .option(ChannelOption.SO_BACKLOG, 1024)

               .childOption(ChannelOption.SO_KEEPALIVE, true)

               .childOption(ChannelOption.TCP_NODELAY, true)

               // 配置入站、出站事件handler

               .childHandler(newChannelInitializer<NioSocketChannel>() {

                   @Override

                   protectedvoidinitChannel(NioSocketChannel ch) {

                       // 配置入站、出站事件channel

                       ch.pipeline().addLast(...);

                       ch.pipeline().addLast(...);

                   }

   });

 

       // 绑定端口

       intport = 8080;

       serverBootstrap.bind(port).addListener(future -> {

           if(future.isSuccess()) {

               System.out.println(newDate() + ": 端口["+ port + "]绑定成功!");

           } else{

               System.err.println("端口["+ port + "]绑定失败!");

           }

       });

}

基本过程描述以下：

1）初始化建立 2 个 NioEventLoopGroup：其中 boosGroup 用于 Accetpt 链接创建事件并分发请求，workerGroup 用于处理 I/O 读写事件和业务逻辑。

2）基于 ServerBootstrap(服务端启动引导类)：配置 EventLoopGroup、Channel 类型，链接参数、配置入站、出站事件 handler。

3）绑定端口：开始工做。

结合上面介绍的 Netty Reactor 模型，介绍服务端 Netty 的工做架构图：

 

Server 端包含 1 个 Boss NioEventLoopGroup 和 1 个 Worker NioEventLoopGroup。

NioEventLoopGroup 至关于 1 个事件循环组，这个组里包含多个事件循环 NioEventLoop，每一个 NioEventLoop 包含 1 个 Selector 和 1 个事件循环线程。

每一个 Boss NioEventLoop 循环执行的任务包含 3 步：

1）轮询 Accept 事件；

2）处理 Accept I/O 事件，与 Client 创建链接，生成 NioSocketChannel，并将 NioSocketChannel 注册到某个 Worker NioEventLoop 的 Selector 上；

3）处理任务队列中的任务，runAllTasks。任务队列中的任务包括用户调用 eventloop.execute 或 schedule 执行的任务，或者其余线程提交到该 eventloop 的任务。

每一个 Worker NioEventLoop 循环执行的任务包含 3 步：

1）轮询 Read、Write 事件；

2）处理 I/O 事件，即 Read、Write 事件，在 NioSocketChannel 可读、可写事件发生时进行处理；

3）处理任务队列中的任务，runAllTasks。

其中任务队列中的 Task 有 3 种典型使用场景：

① 用户程序自定义的普通任务：

ctx.channel().eventLoop().execute(newRunnable() {

   @Override

   publicvoidrun() {

       //...

   }

});

② 非当前 Reactor 线程调用 Channel 的各类方法：

例如在推送系统的业务线程里面，根据用户的标识，找到对应的 Channel 引用，而后调用 Write 类方法向该用户推送消息，就会进入到这种场景。最终的 Write 会提交到任务队列中后被异步消费。

③ 用户自定义定时任务：

ctx.channel().eventLoop().schedule(newRunnable() {

   @Override

   publicvoidrun() {

 

   }

}, 60, TimeUnit.SECONDS);

九、本文小结

如今推荐使用的主流稳定版本仍是 Netty4，Netty5 中使用了 ForkJoinPool，增长了代码的复杂度，可是对性能的改善却不明显，因此这个版本不推荐使用，官网也没有提供下载连接。

Netty 入门门槛相对较高，是由于这方面的资料较少，并非由于它有多难，你们其实均可以像搞透 Spring 同样搞透 Netty。

在学习以前，建议先理解透整个框架原理结构，运行过程，能够少走不少弯路。

 

 

 

 

 

 

 

Netty究竟是什么

从HTTP提及

有了Netty，你能够实现本身的HTTP服务器，FTP服务器，UDP服务器，RPC服务器，WebSocket服务器，Redis的Proxy服务器，MySQL的Proxy服务器等等。

咱们回顾一下传统的HTTP服务器的原理

一、建立一个ServerSocket，监听并绑定一个端口

二、一系列客户端来请求这个端口

三、服务器使用Accept，得到一个来自客户端的Socket链接对象

四、启动一个新线程处理链接

4.一、读Socket，获得字节流

4.二、解码协议，获得Http请求对象

4.三、处理Http请求，获得一个结果，封装成一个HttpResponse对象

4.四、编码协议，将结果序列化字节流 写Socket，将字节流发给客户端

五、继续循环步骤3

HTTP服务器之因此称为HTTP服务器，是由于编码解码协议是HTTP协议，若是协议是Redis协议，那它就成了Redis服务器，若是协议是WebSocket，那它就成了WebSocket服务器，等等。 使用Netty你就能够定制编解码协议，实现本身的特定协议的服务器。

NIO

上面是一个传统处理http的服务器，可是在高并发的环境下，线程数量会比较多，System load也会比较高，因而就有了NIO。

他并非Java独有的概念，NIO表明的一个词汇叫着IO多路复用。它是由操做系统提供的系统调用，早期这个操做系统调用的名字是select，可是性能低下，后来渐渐演化成了Linux下的epoll和Mac里的kqueue。咱们通常就说是epoll，由于没有人拿苹果电脑做为服务器使用对外提供服务。而Netty就是基于Java NIO技术封装的一套框架。为何要封装，由于原生的Java NIO使用起来没那么方便，并且还有臭名昭著的bug，Netty把它封装以后，提供了一个易于操做的使用模式和接口，用户使用起来也就便捷多了。

说NIO以前先说一下BIO（Blocking IO）,如何理解这个Blocking呢？

客户端监听（Listen）时，Accept是阻塞的，只有新链接来了，Accept才会返回，主线程才能继

读写socket时，Read是阻塞的，只有请求消息来了，Read才能返回，子线程才能继续处理

读写socket时，Write是阻塞的，只有客户端把消息收了，Write才能返回，子线程才能继续读取下一个请求

传统的BIO模式下，从头至尾的全部线程都是阻塞的，这些线程就干等着，占用系统的资源，什么事也不干。

那么NIO是怎么作到非阻塞的呢。它用的是事件机制。它能够用一个线程把Accept，读写操做，请求处理的逻辑全干了。若是什么事都没得作，它也不会死循环，它会将线程休眠起来，直到下一个事件来了再继续干活，这样的一个线程称之为NIO线程。用伪代码表示：

while true { events = takeEvents(fds) // 获取事件，若是没有事件，线程就休眠
 for event in events { if event.isAcceptable { doAccept() // 新连接来了
 } elif event.isReadable { request = doRead() // 读消息
 if request.isComplete() { doProcess() } } elif event.isWriteable { doWrite() // 写消息
 } } }

 

Reactor线程模型

Reactor单线程模型

一个NIO线程+一个accept线程：

Reactor多线程模型

Reactor主从模型

主从Reactor多线程：多个acceptor的NIO线程池用于接受客户端的链接

Netty能够基于如上三种模型进行灵活的配置。

总结

Netty是创建在NIO基础之上，Netty在NIO之上又提供了更高层次的抽象。

在Netty里面，Accept链接可使用单独的线程池去处理，读写操做又是另外的线程池来处理。

Accept链接和读写操做也可使用同一个线程池来进行处理。而请求处理逻辑既可使用单独的线程池进行处理，也能够跟放在读写线程一块处理。线程池中的每个线程都是NIO线程。用户能够根据实际状况进行组装，构造出知足系统需求的高性能并发模型。

为何选择Netty

若是不用netty，使用原生JDK的话，有以下问题：

一、API复杂

二、对多线程很熟悉：由于NIO涉及到Reactor模式

三、高可用的话：须要出路断连重连、半包读写、失败缓存等问题

四、JDK NIO的bug

而Netty来讲，他的api简单、性能高并且社区活跃（dubbo、rocketmq等都使用了它）

什么是TCP 粘包/拆包

现象

先看以下代码，这个代码是使用netty在client端重复写100次数据给server端，ByteBuf是netty的一个字节容器，里面存放是的须要发送的数据

public class FirstClientHandler extends ChannelInboundHandlerAdapter { @Override public void channelActive(ChannelHandlerContext ctx) { for (int i = 0; i < 1000; i++) { ByteBuf buffer = getByteBuf(ctx); ctx.channel().writeAndFlush(buffer); } } private ByteBuf getByteBuf(ChannelHandlerContext ctx) { byte[] bytes = "须要更多资料加群：586446657".getBytes(Charset.forName("utf-8")); ByteBuf buffer = ctx.alloc().buffer(); buffer.writeBytes(bytes); return buffer; } }

 

从client端读取到的数据为：

从服务端的控制台输出能够看出，存在三种类型的输出

一种是正常的字符串输出。

一种是多个字符串“粘”在了一块儿，咱们定义这种 ByteBuf 为粘包。

一种是一个字符串被“拆”开，造成一个破碎的包，咱们定义这种 ByteBuf 为半包。

透过现象分析缘由

应用层面使用了Netty，可是对于操做系统来讲，只认TCP协议，尽管咱们的应用层是按照 ByteBuf 为 单位来发送数据，server按照Bytebuf读取，可是到了底层操做系统仍然是按照字节流发送数据，所以，数据到了服务端，也是按照字节流的方式读入，而后到了 Netty 应用层面，从新拼装成 ByteBuf，而这里的 ByteBuf 与客户端按顺序发送的 ByteBuf 多是不对等的。所以，咱们须要在客户端根据自定义协议来组装咱们应用层的数据包，而后在服务端根据咱们的应用层的协议来组装数据包，这个过程一般在服务端称为拆包，而在客户端称为粘包。

拆包和粘包是相对的，一端粘了包，另一端就须要将粘过的包拆开，发送端将三个数据包粘成两个 TCP 数据包发送到接收端，接收端就须要根据应用协议将两个数据包从新组装成三个数据包。

如何解决

在没有 Netty 的状况下，用户若是本身须要拆包，基本原理就是不断从 TCP 缓冲区中读取数据，每次读取完都须要判断是不是一个完整的数据包 若是当前读取的数据不足以拼接成一个完整的业务数据包，那就保留该数据，继续从 TCP 缓冲区中读取，直到获得一个完整的数据包。 若是当前读到的数据加上已经读取的数据足够拼接成一个数据包，那就将已经读取的数据拼接上本次读取的数据，构成一个完整的业务数据包传递到业务逻辑，多余的数据仍然保留，以便和下次读到的数据尝试拼接。

而在Netty中，已经造好了许多类型的拆包器，咱们直接用就好：

选好拆包器后，在代码中client段和server端将拆包器加入到chanelPipeline之中就行了:

如上实例中：

客户端：

ch.pipeline().addLast(new FixedLengthFrameDecoder(31));

服务端：

ch.pipeline().addLast(new FixedLengthFrameDecoder(31));

Netty 的零拷贝

传统意义的拷贝

是在发送数据的时候，传统的实现方式是：

1. File.read(bytes)
2. Socket.send(bytes)

这种方式须要四次数据拷贝和四次上下文切换：

1. 数据从磁盘读取到内核的read buffer
2. 数据从内核缓冲区拷贝到用户缓冲区
3. 数据从用户缓冲区拷贝到内核的socket buffer
4. 数据从内核的socket buffer拷贝到网卡接口（硬件）的缓冲区

零拷贝的概念

明显上面的第二步和第三步是没有必要的，经过java的FileChannel.transferTo方法，能够避免上面两次多余的拷贝（固然这须要底层操做系统支持）

1. 调用transferTo,数据从文件由DMA引擎拷贝到内核read buffer
2. 接着DMA从内核read buffer将数据拷贝到网卡接口buffer

上面的两次操做都不须要CPU参与，因此就达到了零拷贝。

Netty中的零拷贝

主要体如今三个方面：

一、bytebuffer

Netty发送和接收消息主要使用bytebuffer，bytebuffer使用对外内存（DirectMemory）直接进行Socket读写。

缘由：若是使用传统的堆内存进行Socket读写，JVM会将堆内存buffer拷贝一份到直接内存中而后再写入socket，多了一次缓冲区的内存拷贝。DirectMemory中能够直接经过DMA发送到网卡接口

二、Composite Buffers

传统的ByteBuffer，若是须要将两个ByteBuffer中的数据组合到一块儿，咱们须要首先建立一个size=size1+size2大小的新的数组，而后将两个数组中的数据拷贝到新的数组中。可是使用Netty提供的组合ByteBuf，就能够避免这样的操做，由于CompositeByteBuf并无真正将多个Buffer组合起来，而是保存了它们的引用，从而避免了数据的拷贝，实现了零拷贝。

三、对于FileChannel.transferTo的使用

Netty中使用了FileChannel的transferTo方法，该方法依赖于操做系统实现零拷贝。

Netty 内部执行流程

服务端：

一、建立ServerBootStrap实例

二、设置并绑定Reactor线程池：EventLoopGroup，EventLoop就是处理全部注册到本线程的Selector上面的Channel

三、设置并绑定服务端的channel

四、五、建立处理网络事件的ChannelPipeline和handler，网络时间以流的形式在其中流转，handler完成多数的功能定制：好比编解码 SSl安全认证

六、绑定并启动监听端口

七、当轮训到准备就绪的channel后，由Reactor线程：NioEventLoop执行pipline中的方法，最终调度并执行channelHandler

客户端

总结

以上就是我对Netty相关知识整理，若是有不一样的看法，欢迎讨论！ 

参考：新手入门：目前为止最透彻的的Netty高性能原理和框架架构解析