netty的高性能体现在哪里（Netty实战六：Netty处理同一个端口上来的多条不同协议的数据—优化版）

本文目录

• Netty实战六：Netty处理同一个端口上来的多条不同协议的数据—优化版
• 为什么要用Netty开发
• Netty中的零拷贝是怎么实现的
• Netty中的字节操作
• websocket 高性能 实战
• 为什么选择Netty作为基础通信框架

Netty实战六：Netty处理同一个端口上来的多条不同协议的数据—优化版

在实战三中，我们处理了同一个端口上来的2种不同协议的数据，项目上线后，运行良好，之后项目又需要添加一种数据协议，按照同样的方法处理再上线后，发现在网络很差的情况下，会有数据丢包现象。
为了更加通用，针对项目进行了重构，对于netty处理也增加了不少优化。

优化点：

重构之后，过两天就会上线，现在我们总共支持4种不同的数据协议（四种不同厂家的设备），就算还要继续增加，项目结构上也可以很快处理完成。

1、NettyServer.class

2、NettyServerInitializer.class

3、NettyServerDecoder.class

4、NettyServerHandler.class

5、SpringbootApplication.class

基本思路就是不断从TCP缓冲区中读取数据，每次读取完都需要判断是否是一个完整的数据包；
若当前读取的数据不足以拼接成一个完整的业务数据包，那就保留该数据，继续从tcp缓冲区中读取，直到得到一个完整的数据包

若当前读到的数据加上已经读取的数据足够拼接成一个数据包，那就将已经读取的数据拼接上本次读取的数据，够成一个完整的业务数据包传递到业务逻辑， 多余的数据仍然保留，以便和下次读到的数据尝试拼接

这里最重要的是就是，使用markReaderIndex标记读索引，使的多余的数据保留，继续等待后面的数据

为什么要用Netty开发

Netty是由JBOSS提供的基于Java NIO的开源框架，Netty提供异步非阻塞、事件驱动、高性能、高可靠、高可定制性的网络应用程序和工具，可用于开发服务端和客户端。

JAVA原先是采用的是传统的BIO，为什么后来又研发出了NIO呢？

首先看看传统的基于同步阻塞IO（BIO）的线程模型图

BIO主要存在以下缺点：

1.从线程模型图中可以看到，一连接一线程，由于线程数是有限的，所以这样的模型是非常消耗资源的，

最终也导致它不能承受高并发连接的需求

2.性能低，因为频繁的进行上下文切换，导致CUP利用率低

3.可靠性差，由于所有的IO操作都是同步的，即使是业务线程也如此，所以业务线程的IO操作也有可能被阻塞，

这将导致系统过分依赖网络的实时情况和外部组件的处理能力，可靠性大大降低

上面的原因就是导致早期的高性能服务器为什么不选用JAVA开发，而是选用C/C++的重要原因。

为了解决上面的问题，NIO横空出世，下面是NIO的线程模型图

1.NIO采用了Reactor线程模型，一个Reactor聚合了一个多路复用器Selector，它可以同时注册、监听和轮询

成百上千个Channel，这样一个IO线程可以同时处理很多个客户端连接，线程模型优化为1：N(N《最大句柄、数)，

或M:N(M通常为CUP核数+1)

2.避免了IO线程频繁的上下文切换，提升了CUP的效率

3.所有的IO操作都是异步的，所以业务线程的IO操作就不用担心阻塞，系统降低了对网络的实时情况和外部组件

的处理能力的依赖

为什么不直接用JDK原生的NIO而选用Netty框架？

先看看JDK的NIO中服务端和客户端的时序图

服务端：

客户端：

从图中我们可以看到，使用JDK原生NIO的不足之处

1.NIO的类库和API相当复杂，使用它来开发，需要非常熟练地掌握Selector、ByteBuffer、ServerSocketChannel、SocketChannel等

2.需要很多额外的编程技能来辅助使用NIO,例如，因为NIO涉及了Reactor线程模型，所以必须必须对多线程和网络编程非常熟悉才能写出高质量的NIO程序

3.想要有高可靠性，工作量和难度都非常的大，因为服务端需要面临客户端频繁的接入和断开、网络闪断、半包读写、失败缓存、网络阻塞的问题，这些将严重影响我们的可靠性，而使用原生NIO解决它们的难度相当大。

4.JDK NIO中著名的BUG--epoll空轮询，当select返回0时，会导致Selector空轮询而导致CUP100%，官方表示JDK1.6之后修复了这个问题，其实只是发生的概率降低了，没有根本上解决。

那么为什么要用Netty呢？

1.API使用简单，更容易上手，开发门槛低

2.功能强大，预置了多种编解码功能，支持多种主流协议

3.定制能力高，可以通过ChannelHandler对通信框架进行灵活地拓展

4.高性能，与目前多种NIO主流框架相比，Netty综合性能最高

5.高稳定性，解决了JDK NIO的BUG

6.经历了大规模的商业应用考验，质量和可靠性都有很好的验证。

Netty能提供什么服务？

1.开发异步非阻塞的TCP网络应用程序

2.开发异步非阻塞的UDP网络应用程序

3.开发异步文件传输程序

4.开发异步HTTP程序的服务端和客户端

5.提供多种编解码的集成框架，包括谷歌Protobuf、JBossMarshalling、Java序列化、压缩编解码、XML解码、

字符串编解码等都可以由用户直接使用

6.提供形式多样的编解码基础类库，可以方便地进行私有协议栈编解码框架的二次开发

7.基于职责链的Pipeline-Handler机制，可以方便地对网络事件进行拦截和定制

8.所有的IO操作都是异步的，用户可以通过Future-Listeren机制主动get结果或者等IO线程完成操作之后主动Notify来通知，

用户业务线程不需要同步等待

9.基于链路空闲事件监测的心跳机制

10.流量控制和整形

......

Netty中的零拷贝是怎么实现的

Netty是Java语言中一个高性能的网络通信框架，零拷贝又是这个框架的特色之一，它是如何实现的呢？

在计算机中完成一次数据传输，一般需要经过两个阶段。第一步，操作系统把数据从本地硬盘或网卡拷贝到内核空间的内存；第二步，应用程序再把数据从系统内核空间的内存拷贝到用户空间的内存；接下来才是应用程序中的数据处理工作。

先来看几个名词。
DMA（Direct Memory Access）直接存储器访问，将数据从一个地址空间复制到另一个地址空间。当CPU初始化这个传输动作后，传输动作本身是由DMA控制器（DMAC）来完成的。也就是说在数据传输期间，系统可以并行执行其他任务。CPU拷贝，是由CPU直接处理的数据的传送，数据拷贝时一直占用CPU资源。

从上图中可以看出，传统的IO读写流程，包括4次用户态和内核态的切换，4次上下文切换，4次的数据拷贝，2次CPU拷贝，2次DMA拷贝。

一、什么是零拷贝？
拷贝，是指数据从一个存储区域复制到另一个存储区域。 零，表示次数为0，复制的次数为0，也就是数据不需要从一个存储区域复制到另一个存储区域。

二、为什么需要零拷贝？
零拷贝，就是指从系统内核空间的内存到用户空间的内存，不需要采用传统方式的数据复制。而是将系统内核空间的内存和用户空间的内存实现关联映射（mmap内存映射机制），从而省去了数据传输过程中的复制。

mmap（memory map）内存映射机制，简单来说就是将文件/设备映射到内存中，进程可以通过读写内存的方式，实现对mmap文件的操作。零拷贝并不是完全没有拷贝，而是减少了数据拷贝的次数。

三、零拷贝在Netty中的三种实现。
1.使用堆外内存，也叫直接内存（Direct Memory）。netty的接收和发生都是使用Direct buffer，对应系统底层的mmap机制，直接使用堆外内存进行Socket读写，不需要进行字节缓冲区的二次拷贝。
2.提供了组合buffer对象 （CompositeByteBuf），可以聚合多个ByteBuffer对象，用户只需要像操作一个ByteBuffer一样操作组合ByteBuffer，避免了传统通过内存拷贝的方式将几个buffer合并成一个大buffer，不需要内存拷贝。
3.文件传输采用TransferTo方法，它可以直接将文件缓冲区的数据发送到目标channel，避免了传统通过循环write方式导致的内存拷贝问题。

最后总结

通过整理可以发现，netty的零拷贝并不是完全不拷贝，而是减少了CPU拷贝，也就是数据从系统内核空间的内存到用户空间内存的拷贝。DMA拷贝还是存在的，毕竟它是操作系统所做的事情，不属于应用程序的操作范围。在netty中，目前有三种方式实现的零拷贝。第一种使用堆外内存。第二种，CompositeByteBuf组合buffer对象。第三种，文件传输采用TransferTo方法。

***隐藏网址***

Netty中的字节操作

Netty 作为一个优秀网络框架，其高效的 内存操作 也是使其变得 高性能 的很重要原因之一。

众所周知， Java 的 NIO 中提供了类 ByteBuffer 作为字节的容器，但是操作非常的复杂，Netty针对 ByteBuffer 设计了一个替代类 ByteBuf ，方便开发者操作字节。

对于任意一个 ByteBuf 对象，都拥有三个非常重要的属性：

ByteBuf 对象每读取一个byte的数据，readerIndex就会往前推进，直到readerIndex到达capacity的值，所有的数据的数据都被读取完， ByteBuf 不可再被读取。可以通过 readableBytes() 方法获取 readerIndex 的值。

相同地，writerIndex记录了 ByteBuf 对象使用了多少数据，可以通过 writableBytes() 方法获取writerIndex的值。每当 ByteBuf 被写入了多少数据，writerIndex就会往前推进，直到值到达capacity的值， ByteBuf 会自动对空间进行扩容。

对于任意一个 ByteBuf 对象，我们都可以根据它的索引通过 getByte() 方法随机访问中间的数据。随机访问不会改变 readerIndex 的值。

通过 array() 方法可以直接获取， ByteBuf 中的Byte数组信息。

Netty的“Zero-Copy”设计非常出名，这主要就是依赖了Netty中 ByteBuf 的设计。 ByteBuf 主要有以下几种模式：

顾名思义，这个模式下的字节是在Jvm的堆区操作的，也是最常见的内存操作了。

在JDK1.4中，Java引入了一种 直接内存 ，NIO可以通过 本地方法 分配一些堆外的直接内存，这块内存区不受Jvm的控制，理论上的无限的。

对于网络Socket通信来说，这种内存区域的好处是Java在通信中，数据不必从Jvm中拷贝一份到系统的直接内存区上，操作系统的Socket接口可以直接处理这份在直接内存的数据。同时由于数据在堆外，也避免了频繁GC对这块区域的影响。

ByteBuf 提供了 Direct Buffer 模式，我们可以直接通过 ByteBuf 操作 直接内存 。

Direct Buffer 模式下，由于数据不在堆上面， ByteBuf 是不可以直接使用 array() 方法获取数据的。

在TCP协议中，一份完整的数据总是被拆成好几个包被发送或者接收，一般情况下，程序会通过内存拷贝的方式将一组数据拷贝到一个大的数组中，形成一份完整的数据。

而Composite buffer模式可以聚合多个ByteBuffer对象，将这组数据的引用收集到一个 ByteBuf 对象中， 避免 了数据的拷贝。

当然为了避免Netty本身内存使用过度，Netty内部对所有的内存做了池化。通过 ByteBufAllocator 类，我们可以分配一块被池化的内存，从而减少分配和释放内存的开销。

如果我们希望使用一块新的内存，或者对一个已经存在的内存进行包装，那么我们可以使用 Unpooled 类来分配内存:

websocket 高性能 实战

疯狂创客圈 Java 高并发【 亿级流量聊天室实战】实战系列 【 博客园总入口 】

架构师成长+面试必备之 高并发基础书籍 【 Netty Zookeeper Redis 高并发实战 】

很多项目，都需要基于 Websocket 协议做在线客服、在线推送、在线聊天，虽然 Tomcat 内置支持 Websocket 协议，但是由于 Tomcat 的吞吐量、连接数都很低，作为测试是可以的。 在生产环境，一定需要使用高吞吐量、高连接数的 Netty 服务器进行替代 。

之所以 Netty 性能高，因为其使用的是 Reactor 反应器模式。关于反应器模式原理，请参见 《Netty Zookeeper Redis 高并发实战》 一书。

聊天过程gif 演示：

聊天示意图：

Netty搭建的服务器基本上都是差不多的写法：

绑定主线程组和工作线程组，这部分对应架构图中的事件循环组。其原理，，请参见 《Netty Zookeeper Redis 高并发实战》 一书。

重点就是ChannelInitializer的配置，以异步的方式启动，最后是结束的时候关闭线程组。

下面是用websocket做聊天室的逻辑：

源码网址： Java 高并发研习社群 【 博客园 总入口 】

疯狂创客圈 经典图书 ： 《Netty Zookeeper Redis 高并发实战》 面试必备 + 面试必备 + 面试必备

为什么选择Netty作为基础通信框架

一、什么是Netty
Netty是一个高性能 事件驱动、异步非堵塞的IO(NIO)Java开源框架，Jboss提供，用于建立TCP等底层的连接，基于Netty可以建立高性能的Http服务器，快速开发高性能、高可靠性的网络服务器和客户端程序。支持HTTP、 WebSocket 、Protobuf、 Binary TCP |和UDP，Netty已经被很多高性能项目作为其Socket底层基础，如HornetQ Infinispan Vert.x Play Framework Finangle和 Cassandra。其竞争对手是：Apache MINA和 Grizzly。
也就是说，Netty 是一个基于NIO的客户，服务器端编程框架，使用Netty 可以确保你快速和简单的开发出一个网络应用，例如实现了某种协议的客户，服务端应用。Netty相当简化和流线化了网络应用的编程开发过程，例如，TCP和UDP的socket服务开发。
“快速”和“简单”并不意味着会让你的最终应用产生维护性或性能上的问题。Netty 是一个吸收了多种协议的实现经验，这些协议包括FTP,SMTP,HTTP，各种二进制，文本协议，并经过相当精心设计的项目，最终，Netty 成功的找到了一种方式，在保证易于开发的同时还保证了其应用的性能，稳定性和伸缩性。
二、不选择Java原生NIO编程的原因
首先开发出高质量的NIO程序并不是一件简单的事情，除去NIO固有的复杂性和BUG不谈，作为一个NIO服务端，还需要能够处理网络的闪断、客户端的重复接入、客户端的安全认证、消息的编解码、半包读写等情况，如果你没有足够的NIO编程经验积累，一个NIO框架的稳定往往需要半年甚至更长的时间。更为糟糕的是，一旦在生产环境中发生问题，往往会导致跨节点的服务调用中断，严重的可能会导致整个集群环境都不可用，需要重启服务器，这种非正常停机会带来巨大的损失。
从可维护性角度看，由于NIO采用了异步非阻塞编程模型，而且是一个I/O线程处理多条链路，它的调试和跟踪非常麻烦，特别是生产环境中的问题，我们无法进行有效的调试和跟踪，往往只能靠一些日志来辅助分析，定位难度很大。
现在我们总结一下为什么不建议开发者直接使用JDK的NIO类库进行开发，具体原因如下。
1）跨平台与兼容性：NIO算是底层的APIs需依赖系统的IO APIs。但Java NIO发现在不同系统平台会出现问题。大量测试也耗不少时间；NIO2只支持JDK1.7+，而且没提供DatagramSocket，故NIO2不支持UDP协议。而Netty提供统一接口，同一语句无论在JDK6.X 还是JDK7.X 都可运行，无需关心底层架构功能！
2）JAVA NIO的ByteBuffer构造函数私有，无法扩展。Netty提供了自己的ByteBuffer实现，通过简单APIs对其进行构造、使用和操作，一此解决NIO的一些限制。
3）NIO对缓冲区的聚合与分散操作可能会导致内存泄漏。直到JDK1.7才解决此问题。
4）NIO的类库和API繁杂，使用麻烦，你需要熟练掌握Selector、ServerSocketChannel、SocketChannel、ByteBuffer等。
5）使用JAVA NIO需要具备其他的额外技能做铺垫，例如熟悉Java多线程编程。这是因为NIO编程涉及到Reactor模式，你必须对多线程和网路编程非常熟悉，才能编写出高质量的NIO程序。
6）可靠性能力补齐，工作量和难度都非常大。例如客户端面临断连重连、网络闪断、半包读写、失败缓存、网络拥塞和异常码流的处理等问题。
7）JDK NIO的BUG，例如臭名昭著的epoll bug，它会导致Selector空轮询，最终导致CPU 100%。官方声称在JDK 1.6版本的update18修复了该问题，但是直到JDK 1.7版本该问题仍旧存在，只不过该BUG发生概率降低了一些而已，它并没有得到根本性解决。该BUG以及与该BUG相关的问题单可以参见以下链接内容。
异常堆栈如下。
java.lang.Thread.State: RUNNABLE
at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:210)
at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:65)
at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69)
- locked 《0x0000000750928190》 (a sun.nio.ch.Util$2)
- locked 《0x00000007509281a8》 (a java.util.Collections$ UnmodifiableSet)
- locked 《0x0000000750946098》 (a sun.nio.ch.EPollSelectorImpl)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:80)
at net.spy.memcached.MemcachedConnection.handleIO(Memcached Connection.java:217)
at net.spy.memcached.MemcachedConnection.run(MemcachedConnection. java:836)
由于上述原因，在大多数场景下，不建议大家直接使用JDK的NIO类库，除非你精通NIO编程或者有特殊的需求。在绝大多数的业务场景中，我们可以使用NIO框架Netty来进行NIO编程，它既可以作为客户端也可以作为服务端，同时支持UDP和异步文件传输，功能非常强大。