Netty

最新推荐文章于 2025-06-09 16:48:08 发布

CaptainHzc

最新推荐文章于 2025-06-09 16:48:08 发布

阅读量705

点赞数

CC 4.0 BY-SA版权

分类专栏： Java面试

原文链接：https://legends.blog.youkuaiyun.com/article/details/109444894

Java面试专栏收录该内容

26 篇文章

订阅专栏

Netty是什么

Netty是一个异步事件驱动的网络应用程序框架，用于快速开发可维护的高性能协议服务器和客户端。Netty是基于nio的，它封装了jdk的nio，使用起来更加方法灵活。

Netty 的特点是什么

一个高性能、异步事件驱动的NIO框架，它提供了对TCP、UDP和文件传输的支持
使用更高效的socket底层，对epoll空轮询引起的cpu占用飙升在内部进行了处理，避免了直接使用NIO的陷阱，简化了NIO的处理方式。
采用多种decoder/encoder 支持，对TCP粘包/分包进行自动化处理
可使用接受/处理线程池，提高连接效率，对重连、心跳检测的简单支持
可配置IO线程数、TCP参数， TCP接收和发送缓冲区使用直接内存代替堆内存，通过内存池的方式循环利用ByteBuf
通过引用计数器及时申请释放不再引用的对象，降低了GC频率
使用单线程串行化的方式，高效的Reactor线程模型
大量使用了volitale、使用了CAS和原子类、线程安全类的使用、读写锁的使用

Netty 的优势有哪些？

使用简单：封装了 NIO 的很多细节，使用更简单。
功能强大：预置了多种编解码功能，支持多种主流协议。
定制能力强：可以通过 ChannelHandler 对通信框架进行灵活地扩展。
性能高：通过与其他业界主流的 NIO 框架对比，Netty 的综合性能最优。
稳定：Netty 修复了已经发现的所有 NIO 的 bug，让开发人员可以专注于业务本身。
社区活跃：Netty 是活跃的开源项目，版本迭代周期短，bug 修复速度快。

Netty 的应用场景有哪些

Netty常见的使用场景如下：

互联网行业在分布式系统中，各个节点之间需要远程服务调用，高性能的RPC框架必不可少，Netty作为异步高新能的通信框架,往往作为基础通信组件被这些RPC框架使用。典型的应用有：阿里分布式服务框架Dubbo的RPC框架使用Dubbo协议进行节点间通信，Dubbo协议默认使用Netty作为基础通信组件，用于实现各进程节点之间的内部通信。
游戏行业无论是手游服务端还是大型的网络游戏，Java语言得到了越来越广泛的应用。Netty作为高性能的基础通信组件，它本身提供了TCP/UDP和HTTP协议栈。非常方便定制和开发私有协议栈，账号登录服务器，地图服务器之间可以方便的通过Netty进行高性能的通信
大数据领域经典的Hadoop的高性能通信和序列化组件Avro的RPC框架，默认采用Netty进行跨界点通信，它的Netty Service基于Netty框架二次封装实现

Netty 高性能表现在哪些方面

心跳，对服务端：会定时清除闲置会话inactive(netty5)，对客户端:用来检测会话是否断开，是否重来，检测网络延迟，其中idleStateHandler类用来检测会话状态。
IO 线程模型：同步非阻塞，用最少的资源做更多的事。
内存零拷贝：尽量减少不必要的内存拷贝，实现了更高效率的传输。
内存池设计：申请的内存可以重用，主要指直接内存。内部实现是用一颗二叉查找树管理内存分配情况。
串形化处理读写：避免使用锁带来的性能开销。
高性能序列化协议：支持 protobuf 等高性能序列化协议。

BIO模型

同步并阻塞(传统阻塞型)，每个请求都需要创建独立的线程，与对应的客户端进行数据Read，业务处理，数据Write 。当并发数较大时，需要创建大量线程来处理连接，系统资源占用较大。连接建立后，如果当前线程暂时没有数据可读，则线程就阻塞在Read 操作上，造成线程资源浪费。
流程：

服务器端启动一个ServerSocket，对端口进行监听
客户端启动Socket 对此端口请求，服务器端接收到请求，需要对每个客户建立一个线程与之通讯
客户端发出请求后, 先咨询服务器是否有线程响应，如果没有则会等待，或者被拒绝
如果有响应，客户端线程会等待请求结束后，再继续执行

NIO模型

同步非阻塞，服务器实现模式为一个线程处理多个请求(连接)，即客户端发送的连接请求都会注册到多路复用器上，多路复用器轮询到连接有I/O 请求就进行处理。

NIO 有三大核心部分：Channel(通道)，Buffer(缓冲区), Selector(选择器)
NIO 是面向缓冲区，或者面向块编程的。数据读取到一个它稍后处理的缓冲区，需要时可在缓冲区中前后移动，这就增加了处理过程中的灵活性，使用它可以提供非阻塞式的高伸缩性网络。
Java NIO 的非阻塞模式，使一个线程从某通道发送请求或者读取数据，但是它仅能得到目前可用的数据，如果目前没有数据可用时，就什么都不会获取，而不是保持线程阻塞，所以直至数据变的可以读取之前，该线程可以继续做其他的事情。非阻塞写也是如此，一个线程请求写入一些数据到某通道，但不需要等待它完全写入，这个线程同时可以去做别的事情。
通俗理解：NIO 是可以做到用一个线程来处理多个操作的。假设有10000 个请求过来,根据实际情况，可以分配50 或者100 个线程来处理。不像之前的阻塞IO 那样，非得分配10000 个。
流程&架构

每个channel 都会对应一个Buffer
Selector 对应一个线程，一个线程对应多个channel(连接)
该图反应了有三个channel 注册到该selector 程序
程序切换到哪个channel 是由事件决定的, Event 就是一个重要的概念
Selector 会根据不同的事件，在各个通道上切换
Buffer 就是一个内存块，底层是有一个数组
数据的读取写入是通过Buffer, 这个和BIO , BIO 中要么是输入流，或者是
输出流, 不能双向，但是NIO 的Buffer 是可以读也可以写, 需要flip 方法切换
channel 是双向的, 可以返回底层操作系统的情况.

NIO的组成

Buffer：与Channel进行交互，数据是从Channel读入缓冲区，从缓冲区写入Channel中的

flip方法：反转此缓冲区，将position给limit，然后将position置为0，其实就是切换读写模式

clear方法：清除此缓冲区，将position置为0，把capacity的值给limit。

rewind方法：重绕此缓冲区，将position置为0

DirectByteBuffer可减少一次系统空间到用户空间的拷贝。但Buffer创建和销毁的成本更高，不可控，通常会用内存池来提高性能。直接缓冲区主要分配给那些易受基础系统的本机I/O 操作影响的大型、持久的缓冲区。如果数据量比较小的中小应用情况下，可以考虑使用heapBuffer，由JVM进行管理。

Channel：表示 IO 源与目标打开的连接，是双向的，但不能直接访问数据，只能与Buffer 进行交互。通过源码可知，FileChannel的read方法和write方法都导致数据复制了两次！

Selector可使一个单独的线程管理多个Channel，open方法可创建Selector，register方法向多路复用器器注册通道，可以监听的事件类型：读、写、连接、accept。注册事件后会产生一个SelectionKey：它表示SelectableChannel 和Selector 之间的注册关系，wakeup方法：使尚未返回的第一个选择操作立即返回，唤醒的

原因是：注册了新的channel或者事件；channel关闭，取消注册；优先级更高的事件触发（如定时器事件），希望及时处理。

Selector在Linux的实现类是EPollSelectorImpl，委托给EPollArrayWrapper实现，其中三个native方法是对epoll的封装，而EPollSelectorImpl. implRegister方法，通过调用epoll_ctl向epoll实例中注册事件，还将注册的文件描述符(fd)与SelectionKey的对应关系添加到fdToKey中，这个map维护了文件描述符与SelectionKey的映射。

fdToKey有时会变得非常大，因为注册到Selector上的Channel非常多（百万连接）；过期或失效的Channel没有及时关闭。fdToKey总是串行读取的，而读取是在select方法中进行的，该方法是非线程安全的。

Pipe：两个线程之间的单向数据连接，数据会被写到sink通道，从source通道读取

NIO的服务端建立过程：Selector.open()：打开一个Selector；ServerSocketChannel.open()：创建服务端的Channel；bind()：绑定到某个端口上。并配置非阻塞模式；register()：注册Channel和关注的事件到Selector上；select()轮询拿到已经就绪的事件

不选择原生NIO编程的原因

JDK NIO的BUG,例如epoll bug，它会导致Selector空轮询，最终导致CPU 100%。在大多数场景下，不建议直接使用JDK的NIO类库。在绝大多数的业务场景中，我们可以使用NIO框架Netty来进行NIO编程，它既可以作为客户端也可以作为服务端，同时支持UDP和异步文件传输，功能非常强大。

NIO 、BIO、Aio 的比较

BIO 以流的方式处理数据,而NIO 以块的方式处理数据,块I/O 的效率比流I/O 高很多
BIO 是阻塞的，NIO 则是非阻塞的
BIO 基于字节流和字符流进行操作，而NIO 基于Channel(通道)和Buffer(缓冲区)进行操作，数据总是从通道
读取到缓冲区中，或者从缓冲区写入到通道中。Selector(选择器)用于监听多个通道的事件（比如：连接请求，
数据到达等），因此使用单个线程就可以监听多个客户端通道
4）AIO ：异步非阻塞，AIO 引入异步通道的概念，采用了Proactor 模式，简化了程序编写，有效
的请求才启动线程，它的特点是先由操作系统完成后才通知服务端程序启动线程去处理，一般适用于连接数较
多且连接时间较长的应用

Reactor模型以及3种版本

2.3.1 单 Reactor 单线程

在这里插入图片描述
方案说明：

Select 是 I/O 复用模型的标准网络编程 API，可以实现应用程序通过一个阻塞对象监听多路连接请求
Reactor 对象通过 Select 监控客户端请求事件，收到事件后通过 Dispatch 进行分发
如果是建立连接请求事件，则由 Acceptor 通过 Accept 处理连接请求，然后创建一个 Handler 对象处理连接完成后的后续业务处理
如果不是建立连接事件，则 Reactor 会分发调用连接对应的 Handler 来响应
Handler 会完成 Read→业务处理→Send 的完整业务流程

方案优缺点分析：

优点：模型简单，没有多线程、进程通信、竞争的问题，全部都在一个线程中完成
缺点：性能问题，只有一个线程，无法完全发挥多核 CPU 的性能。Handler 在处理某个连接上的业务时，整个进程无法处理其他连接事件，很容易导致性能瓶颈
缺点：可靠性问题，线程意外终止，或者进入死循环，会导致整个系统通信模块不可用，不能接收和处理外部消息，造成节点故障
使用场景：客户端的数量有限，业务处理非常快速，比如 Redis 在业务处理的时间复杂度 O(1) 的情况

2.3.2 单 Reactor 多线程

在这里插入图片描述
方案说明：

Reactor 对象通过 select 监控客户端请求事件, 收到事件后，通过 dispatch 进行分发
如果建立连接请求, 则右 Acceptor 通过 accept 处理连接请求, 然后创建一个 Handler 对象处理完成连接后的各种事件
如果不是连接请求，则由 reactor 分发调用连接对应的 handler 来处理
handler 只负责响应事件，不做具体的业务处理, 通过 read 读取数据后，会分发给后面的 worker 线程池的某个线程处理业务
worker 线程池会分配独立线程完成真正的业务，并将结果返回给 handler
handler 收到响应后，通过 send 将结果返回给 client

方案优缺点分析：

优点：可以充分的利用多核 cpu 的处理能力
缺点：多线程数据共享和访问比较复杂， reactor 处理所有的事件的监听和响应，在单线程运行，在高并发场景容易出现性能瓶颈

2.3.3 主从 Reactor 多线程

针对单 Reactor 多线程模型中，Reactor 在单线程中运行，高并发场景下容易成为性能瓶颈，可以让 Reactor 在多线程中运行
在这里插入图片描述
方案说明：

Reactor 主线程 MainReactor 对象通过 select 监听连接事件, 收到事件后，通过 Acceptor 处理连接事件
当 Acceptor 处理连接事件后，MainReactor 将连接分配给 SubReactor
subreactor 将连接加入到连接队列进行监听,并创建 handler 进行各种事件处理
当有新事件发生时， subreactor 就会调用对应的 handler 处理
handler 通过 read 读取数据，分发给后面的 worker 线程处理
worker 线程池分配独立的 worker 线程进行业务处理，并返回结果
handler 收到响应的结果后，再通过 send 将结果返回给 client
Reactor 主线程可以对应多个 Reactor 子线程, 即 MainRecator 可以关联多个 SubReactor

方案优缺点说明：

优点：父线程与子线程的数据交互简单职责明确，父线程只需要接收新连接，子线程完成后续的业务处理。
优点：父线程与子线程的数据交互简单，Reactor 主线程只需要把新连接传给子线程，子线程无需返回数据。
缺点：编程复杂度较高

2.4 Reactor 模式的优点

响应快，不必为单个同步时间所阻塞，虽然 Reactor 本身依然是同步的
可以最大程度的避免复杂的多线程及同步问题，并且避免了多线程/进程的切换开销
扩展性好，可以方便的通过增加 Reactor 实例个数来充分利用 CPU 资源
复用性好，Reactor 模型本身与具体事件处理逻辑无关，具有很高的复用性

NIO 的通道与BIO流的区别

 通道可以同时进行读写，而流只能读或者只能写
 通道可以实现异步读写数据
 通道可以从缓冲读数据，也可以写数据到缓冲:
2) BIO 中的stream 是单向的，例如FileInputStream 对象只能进行读取数据的操作，而NIO 中的通道(Channel)
是双向的，可以读操作，也可以写操作。
3) Channel 在NIO 中是一个接口, 常用的Channel 类有： FileChannel 、DatagramChannel 、ServerSocketChannel 和SocketChannel
FileChannel 用于文件的数据读写， DatagramChannel 用于UDP 的数据读写， ServerSocketChannel 和SocketChannel 用于TCP 的数据读写

Netty 中有哪些重要组件

Bootstrap、ServerBootstrap
Bootstrap意思是引导，一个Netty应用通常由一个Bootstrap开始，主要作用是配置整个Netty程序，串联各个组件，Netty中Bootstrap类是客户端程序的启动引导类，ServerBootstrap是服务端启动引导类。
Future、ChannelFuture
在Netty中所有的IO操作都是异步的，不能立刻得知消息是否被正确处理，但是可以过一会等它执行完成或者直接注册一个监听，具体的实现就是通过Future和ChannelFutures，他们可以注册一个监听，当操作执行成功或失败时监听会自动触发注册的监听事件。
Channel
Netty网络通信的组件，能够用于执行网络I/O操作。 Channel为用户提供：

当前网络连接的通道的状态（例如是否打开？是否已连接？）
网络连接的配置参数（例如接收缓冲区大小）
提供异步的网络I/O操作(如建立连接，读写，绑定端口)，异步调用意味着任何I / O调用都将立即返回，并且不保证在调用结束时所请求的I / O操作已完成。调用立即返回一个ChannelFuture实例，通过注册监听器到ChannelFuture上，可以I / O操作成功、失败或取消时回调通知调用方。
支持关联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 中每个 Channel 都有且仅有一个 ChannelPipeline 与之对应,
一个 Channel 包含了一个 ChannelPipeline, 而 ChannelPipeline 中又维护了一个由 ChannelHandlerContext 组成的双向链表, 并且每个ChannelHandlerContext 中又关联着一个 ChannelHandler。入站事件和出站事件在一个双向链表中，入站事件会从链表head往后传递到最后一个入站的handler，出站事件会从链表tail往前传递到最前一个出站的handler，两种类型的handler互不干扰。
参考

netty 架构

Netty 主要基于主从 Reactors 多线程模型做了一定的改进，其中主从 Reactor 多线程模型有多个 Reactor
在这里插入图片描述

Netty 抽象出两组线程池 BossGroup 专门负责接收客户端的连接, WorkerGroup 专门负责网络的读写
BossGroup 和 WorkerGroup 类型都是 NioEventLoopGroup
NioEventLoopGroup 相当于一个事件循环组, 这个组中含有多个事件循环，每一个事件循环是 NioEventLoop
NioEventLoop 表示一个不断循环的执行处理任务的线程，每个 NioEventLoop 都有一个 selector , 用于监听绑定在其上的 socket 的网络通讯
NioEventLoopGroup 可以有多个线程, 即可以含有多个 NioEventLoop
每个 Boss NioEventLoop 循环执行的步骤有 3 步

轮询 accept 事件
处理 accept 事件 , 与 client 建立连接 , 生成 NioScocketChannel , 并将其注册到某个 worker NIOEventLoop 上的 selector
处理任务队列的任务，即 runAllTasks
7) 每个 Worker NIOEventLoop 循环执行的步骤
轮询 read, write 事件
处理 i/o 事件，即 read , write 事件，在对应 NioScocketChannel 处理
处理任务队列的任务，即 runAllTasks
8) 每个Worker NIOEventLoop 处理业务时，会使用pipeline(管道), pipeline 中包含了 channel , 即通过pipeline 可以获取到对应通道, 管道中维护了很多的处理器

Netty 长连接、心跳机制

TCP 长连接和短连接了解么？

TCP 在进行读写之前，server 与 client 之间必须提前建立一个连接。建立连接的过程，需要三次握手，释放/关闭连接的话需要四次挥手。这个过程是比较消耗网络资源并且有时间延迟的。

所谓，短连接说的就是 server 端与 client 端建立连接之后，读写完成之后就关闭掉连接，如果下一次再要互相发送消息，就要重新连接。短连接的优点很明显，就是管理和实现都比较简单，缺点也很明显，每一次的读写都要建立连接必然会带来大量网络资源的消耗，并且连接的建立也需要耗费时间。

长连接说的就是 client 向 server 双方建立连接之后，即使 client 与 server 完成一次读写，它们之间的连接并不会主动关闭，后续的读写操作会继续使用这个连接。长连接的可以省去较多的 TCP 建立和关闭的操作，降低对网络资源的依赖，节约时间。对于频繁请求资源的客户来说，非常适用长连接。

Netty 中心跳机制

在 TCP 保持长连接的过程中，可能会出现断网等网络异常出现，异常发生的时候， client 与 server 之间如果没有交互的话，他们是无法发现对方已经掉线的。为了解决这个问题, 就需要引入心跳机制。

心跳机制的工作原理是: 在 client 与 server 之间在一定时间内没有数据交互时, 即处于 idle（闲置）状态时, 客户端或服务器就会发送一个特殊的数据包给对方, 当接收方收到这个数据报文后, 也立即发送一个特殊的数据报文, 回应发送方, 此即一个 PING-PONG 交互。所以, 当某一端收到心跳消息后, 就知道了对方仍然在线, 这就确保 TCP 连接的有效性.

TCP 实际上自带的就有长连接选项，本身是也有心跳包机制，也就是 TCP 的选项：SO_KEEPALIVE。但是，TCP 协议层面的长连接灵活性不够。所以，一般情况下我们都是在应用层协议上实现自定义信跳机制的，也就是在 Netty 层面通过编码实现。通过 Netty 实现心跳机制的话，核心类是 IdleStateHandler 。

Netty 支持哪些心跳类型设置

readerIdleTime：为读超时时间（即测试端一定时间内未接受到被测试端消息）。
writerIdleTime：为写超时时间（即测试端一定时间内向被测试端发送消息）。
allIdleTime：所有类型的超时时间。

零拷贝

传统的 IO 将一个文件通过 socket 写出

传统的 IO 将一个文件通过 socket 写出

File f = new File("helloword/data.txt");
RandomAccessFile file = new RandomAccessFile(file, "r");

byte[] buf = new byte[(int)f.length()];
file.read(buf);

Socket socket = ...;
socket.getOutputStream().write(buf);

内部工作流程是这样的：

在这里插入图片描述

java 本身并不具备 IO 读写能力，因此 read 方法调用后，要从 java 程序的用户态切换至内核态，去调用操作系统（Kernel）的读能力，将数据读入内核缓冲区。这期间用户线程阻塞，操作系统使用 DMA（Direct Memory Access）来实现文件读，其间也不会使用 cpu

DMA 也可以理解为硬件单元，用来解放 cpu 完成文件 IO
从内核态切换回用户态，将数据从内核缓冲区读入用户缓冲区（即 byte[] buf），这期间 cpu 会参与拷贝，无法利用 DMA
调用 write 方法，这时将数据从用户缓冲区（byte[] buf）写入 socket 缓冲区，cpu 会参与拷贝
接下来要向网卡写数据，这项能力 java 又不具备，因此又得从用户态切换至内核态，调用操作系统的写能力，使用 DMA 将 socket 缓冲区的数据写入网卡，不会使用 cpu

可以看到中间环节较多，java 的 IO 实际不是物理设备级别的读写，而是缓存的复制，底层的真正读写是操作系统来完成的

用户态与内核态的切换发生了 3 次，这个操作比较重量级
数据拷贝了共 4 次

NIO 优化

可以使用 DirectByteBuf 将堆外内存映射到 jvm 内存中来直接访问使用，这减少了一次数据拷贝，即内核缓冲区到用户缓冲区的数据拷贝，但是用户态与内核态的切换次数没有减少

这块内存不受 jvm 垃圾回收的影响，因此内存地址固定，有助于 IO 读写
java 中的 DirectByteBuf 对象仅维护了此内存的虚引用，内存回收分成两步
DirectByteBuf 对象被垃圾回收，将虚引用加入引用队列
通过专门线程访问引用队列，根据虚引用释放堆外内存
ByteBuffer.allocate(10) HeapByteBuffer 使用的还是 java 内存
ByteBuffer.allocateDirect(10) DirectByteBuffer 使用的是操作系统内存

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-BiMJwiCc-1624243615411)(img/0026.png)]

进一步优化，java对 channel 调用 transferTo/transferFrom 方法拷贝数据

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-lJSEhnm7-1624243615413)(img/0027.png)]

java 调用 transferTo 方法后，要从 java 程序的用户态切换至内核态，使用 DMA将数据读入内核缓冲区，不会使用 cpu
只会将一些 offset 和 length 信息拷入 socket 缓冲区，几乎无消耗
使用 DMA 将 内核缓冲区的数据写入网卡，不会使用 cpu

整个过程仅只发生了一次用户态与内核态的切换，数据拷贝了 2 次。所谓的【零拷贝】，并不是真正无拷贝，而是在不会拷贝重复数据到 jvm 内存中，零拷贝的优点有

更少的用户态与内核态的切换
不利用 cpu 计算，减少 cpu 缓存伪共享
零拷贝适合小文件传输

Netty中的零拷贝

Netty是基于NIO的，所以Netty的零拷贝也包NIO的优化（虚引用directbytebuf ,transferto方法使用dma避免使用cpu拷贝数据）。除此之外，在ByteBuf的实现上，Netty也提供了零拷贝的一些实现。

关于ByteBuffer，Netty提供了两个接口:

ByteBuf
ByteBufHolder

对于ByteBuf，Netty提供了多种实现：

Heap ByteBuf:直接在堆内存分配
Direct ByteBuf：直接在内存区域分配而不是堆内存
CompositeByteBuf：组合Buffer

Direct Buffers
直接在内存区域分配空间，而不是在堆内存中分配。如果使用传统的堆内存分配，当我们需要将数据通过socket发送的时候，就需要从堆内存拷贝到直接内存，然后再由直接内存拷贝到网卡接口层。
Netty提供的直接Buffer，直接将数据分配到内存空间，从而避免了数据的拷贝，实现了零拷贝。

Composite Buffers
传统的ByteBuffer，如果需要将两个ByteBuffer中的数据组合到一起，我们需要首先创建一个size=size1+size2大小的新的数组，然后将两个数组中的数据拷贝到新的数组中。但是使用Netty提供的组合ByteBuf，就可以避免这样的操作，因为CompositeByteBuf并没有真正将多个Buffer组合起来，而是保存了它们的引用，从而避免了数据的拷贝，实现了零拷贝。

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

总结
Netty的零拷贝体现在三个方面：

Netty的接收和发送ByteBuffer采用DIRECT BUFFERS，使用堆外直接内存进行Socket读写，不需要进行字节缓冲区的二次拷贝。如果使用传统的堆内存（HEAP BUFFERS）进行Socket读写，JVM会将堆内存Buffer拷贝一份到直接内存中，然后才写入Socket中。相比于堆外直接内存，消息在发送过程中多了一次缓冲区的内存拷贝。
Netty提供了组合Buffer对象，可以聚合多个ByteBuffer对象，用户可以像操作一个Buffer那样方便的对组合Buffer进行操作，避免了传统通过内存拷贝的方式将几个小Buffer合并成一个大的Buffer。
Netty的文件传输采用了transferTo方法，它可以直接将文件缓冲区的数据发送到目标Channel，避免了传统通过循环write方式导致的内存拷贝问题。

直接内存和堆内存（什么时候用）

jvm中使用的内存可分为两种，一个是堆内存，一个是直接内存。

堆内存（HeapByteBuf）字节缓冲区：特点是内存的分配和回收速度快，可以被JVM自动回收；缺点就是如果进行Socket的IO读写，需要额外做一次内存复制，将堆内存对应的缓冲区复制到内核Channel中，性能会有一定程度的下降
直接内存（DirectByteBuf）字节缓冲区：非堆内存，它在对外进行内存分配，相比于堆内存，它的分配和回收速度会慢一些，但是将它写入或者从Socket Channel中读取时，由于少一次内存复制，速度比堆内存快

直接内存和堆内存适用于不同的场景：

在I/O通信线程的读写缓冲区使用DIrectByteBuf，可以减少一次jvm内存缓冲区到直接内存缓冲区的一次拷贝，可以从直接内存直接写入到Socket的缓冲区进行消息的发送。
后端业务消息的编解码模块使用HeapByteBuf。

池化（netty内存管理）

直接内存空间的申请比堆内存要消耗更高的性能。因此Netty结合引用计数实现了PolledBuffer，即池化的用法，当引用计数等于0的时候，Netty将Buffer回收至池中，在下一次申请Buffer的时刻会被复用。堆内存和直接内存的池化实现分别是PooledHeapByteBuf和PooledDirectByteBuf，在各自的实现中都维护着一个Recycler 。Recycler是一个抽象类，向外部提供了两个公共方法get和recycle分别用于从对象池中获取对象和回收对象。

粘包拆包

什么是粘包和拆包？

现在假设客户端向服务端连续发送了两个数据包，packet1和packet2，那么服务端收到的数据可以分为三种，
1.接收端正常收到两个数据包，即没有发生拆包和粘包的现象。
2.接收端只收到一个数据包，由于TCP是不会出现丢包的，所以这一个数据包中包含了发送端发送的两个数据包的信息，这种现象即为粘包。这种情况由于接收端不知道这两个数据包的界限，所以对于接收端来说很难处理。
3.这种情况有两种表现形式，如下图。接收端收到了两个数据包，但是这两个数据包要么是不完整的，要么就是多出来一块，这种情况即发生了拆包和粘包。这两种情况如果不加特殊处理，对于接收端同样是不好处理的。

TCP是个“流”协议，没有界限的一串数据。TCP底层并不了解上层业务数据的具体含义，它会根据TCP缓冲区的实际情况进行包的划分，所以在业务上认为，一个完整的包可能会被TCP拆分成多个包进行发送，也有可能把多个小的包封装成一个大的数据包发送，这就是所

的TCP粘包和拆包问题

要发送的数据大于TCP发送缓冲区剩余空间大小，将会发生拆包待发送数据大于MSS（最大报文长度），TCP在传输前将进行拆包要发送的数据小于TCP发送缓冲区的大小，TCP将多次写入缓冲区的数据一次发送出去，将会发生粘包接收数据端的应用层没有及时读取接收缓冲区中的数据，将发生粘包

粘包、拆包解决办法

由于底层的TCP无法理解上层的业务数据，所以在底层是无法保证数据包不被拆分和重组的，这个问题只能通过上层的应用协议栈设计来解决，根据业界的主流协议的解决方案，归纳如下：
消息定长。发送端将每个数据包封装为固定长度（不够的可以通过补0填充），这样接收端每次接收缓冲区中读取固定长度的数据就自然而然的把每个数据包拆分开来
设置消息边界。服务端从网络流中按消息边界分离出消息内容。在包尾增加回车换行符进行分割，例如FTP协议
将消息分为消息头和消息体，消息头中包含表示消息总长度（或者消息体长度）的字段
更复杂的应用层协议，比如Netty中实现的一些协议都对粘包、拆包做了很好的处理

Netty的拆包解决方案

Netty服务端在发送数据之前先对数据按一定的规则进行编码，客户端在接收到数据后按照相同的规则进行解码，这就是Netty解决粘包拆包问题的思路。
Netty 中的拆包器4个：

1.固定长度的拆包器 FixedLengthFrameDecoder
每个应用层数据包的都拆分成都是固定长度的大小，比如 1024字节对于使用固定长度的粘包和拆包场景，可以使用FixedLengthFrameDecoder，该解码一器会每次读取固定长度的消息，如果当前读取到的消息不足指定长度，那么就会等待下一个消息到达后进行补足。其使用也比较简单，只需要在构造函数中指定每个消息的长度即可。这里需要注意的是，FixedLengthFrameDecoder只是一个解码器，Netty也只提供了一个解码器，这是因为对于解码是需要等待下一个包的进行补全的，代码相对复杂，而对于编码器，用户可以自行编写，因为编码时只需要将不足指定长度的部分进行补全即可。数据在编码发送的时候，也会以固定长度作为一调完整的消息
2.行拆包器 LineBasedFrameDecoder
每个应用层数据包，都以换行符作为分隔符，进行分割拆分数据在编码发送的时候，会以换行符作为一条完整的消息
3.分隔符拆包器 DelimiterBasedFrameDecoder
每个应用层数据包，都通过自定义的分隔符，进行分割拆分。这个版本，是LineBasedFrameDecoder 的通用版本，本质上是一样的。数据在编码发送的时候，会以一个自定义的分隔符作为一条完整的消息
4.基于数据包长度的拆包器 LengthFieldBasedFrameDecoder
将应用层数据包的长度，作为接收端应用层数据包的拆分依据。按照应用层数据包的大小，拆包。这个拆包器，有一个要求，就是应用层协议中包含数据包的长度。 LengthFieldBasedFrameDecoder与LengthFieldPrepender需要配合起来使用，其实本质上来讲，这两者一个是解码，一个是编码的关系。它们处理粘拆包的主要思想是在生成的数据包中添加一个长度字段，用于记录当前数据包的长度。LengthFieldBasedFrameDecoder会按照参数指定的包长度偏移量数据对接收到的数据进行解码，从而得到目标消息体数据；而LengthFieldPrepender则会在响应的数据前面添加指定的字节数据，这个字节数据中保存了当前消息体的整体字节数据长度。数据在编码发送的时候，会指定当前这条消息的长度。

bytebuffer

在这里插入图片描述

Netty 服务端和客户端的创建过程

服务端
// 1.bossGroup 用于接收连接，workerGroup 用于具体的处理
EventLoopGroup bossGroup = new NioEventLoopGroup(1);
EventLoopGroup workerGroup = new NioEventLoopGroup();
try {
//2.创建服务端启动引导/辅助类：ServerBootstrap
ServerBootstrap b = new ServerBootstrap();
//3.给引导类配置两大线程组,确定了线程模型
b.group(bossGroup, workerGroup)
// (非必备)打印日志
.handler(new LoggingHandler(LogLevel.INFO))
// 4.指定 IO 模型
.channel(NioServerSocketChannel.class)
.childHandler(new ChannelInitializer() {
@Override
public void initChannel(SocketChannel ch) {
ChannelPipeline p = ch.pipeline();
//5.可以自定义客户端消息的业务处理逻辑
p.addLast(new HelloServerHandler());
}
});
// 6.绑定端口,调用 sync 方法阻塞知道绑定完成
ChannelFuture f = b.bind(port).sync();
// 7.阻塞等待直到服务器Channel关闭(closeFuture()方法获取Channel 的CloseFuture对象,然后调用sync()方法)
f.channel().closeFuture().sync();
} finally {
//8.优雅关闭相关线程组资源
bossGroup.shutdownGracefully();
workerGroup.shutdownGracefully();
}
简单解细一下服务端的创建过程具体是怎样的：

1.首先你创建了两个 NioEventLoopGroup 对象实例：bossGroup 和 workerGroup。

bossGroup : 用于处理客户端的 TCP 连接请求。
workerGroup ：负责每一条连接的具体读写数据的处理逻辑，真正负责 I/O 读写操作，交由对应的 Handler 处理。
举个例子：我们把公司的老板当做 bossGroup，员工当做 workerGroup，bossGroup 在外面接完活之后，扔给 workerGroup 去处理。一般情况下我们会指定 bossGroup 的线程数为 1（并发连接量不大的时候），workGroup 的线程数量为 CPU 核心数 *2 。另外，根据源码来看，使用 NioEventLoopGroup 类的无参构造函数设置线程数量的默认值就是 CPU 核心数 *2 。

2.接下来我们创建了一个服务端启动引导/辅助类：ServerBootstrap，这个类将引导我们进行服务端的启动工作。

3.通过 .group() 方法给引导类 ServerBootstrap 配置两大线程组，确定了线程模型。

通过下面的代码，我们实际配置的是多线程模型，这个在上面提到过。

EventLoopGroup bossGroup = new NioEventLoopGroup(1);
EventLoopGroup workerGroup = new NioEventLoopGroup();

4.通过channel()方法给引导类 ServerBootstrap指定了 IO 模型为NIO

NioServerSocketChannel ：指定服务端的 IO 模型为 NIO，与 BIO 编程模型中的ServerSocket对应
NioSocketChannel : 指定客户端的 IO 模型为 NIO，与 BIO 编程模型中的Socket对应5.通过 .childHandler()给引导类创建一个ChannelInitializer ，然后制定了服务端消息的业务处理逻辑 HelloServerHandler 对象6.调用 ServerBootstrap 类的 bind()方法绑定端口
客户端
//1.创建一个 NioEventLoopGroup 对象实例
EventLoopGroup group = new NioEventLoopGroup();
try {
//2.创建客户端启动引导/辅助类：Bootstrap
Bootstrap b = new Bootstrap();
//3.指定线程组
b.group(group)
//4.指定 IO 模型
.channel(NioSocketChannel.class)
.handler(new ChannelInitializer() {
@Override
public void initChannel(SocketChannel ch) throws Exception {
ChannelPipeline p = ch.pipeline();
// 5.这里可以自定义消息的业务处理逻辑
p.addLast(new HelloClientHandler(message));
}
});
// 6.尝试建立连接
ChannelFuture f = b.connect(host, port).sync();
// 7.等待连接关闭（阻塞，直到Channel关闭）
f.channel().closeFuture().sync();
} finally {
group.shutdownGracefully();
}
继续分析一下客户端的创建流程：

1.创建一个 NioEventLoopGroup 对象实例

2.创建客户端启动的引导类是 Bootstrap

3.通过 .group() 方法给引导类 Bootstrap 配置一个线程组

4.通过channel()方法给引导类 Bootstrap指定了 IO 模型为NIO

5.通过 .childHandler()给引导类创建一个ChannelInitializer ，然后制定了客户端消息的业务处理逻辑 HelloClientHandler 对象

6.调用 Bootstrap 类的 connect()方法进行连接，这个方法需要指定两个参数：

inetHost : ip 地址
inetPort : 端口号
public ChannelFuture connect(String inetHost, int inetPort) {
return this.connect(InetSocketAddress.createUnresolved(inetHost, inetPort));
}
public ChannelFuture connect(SocketAddress remoteAddress) {
ObjectUtil.checkNotNull(remoteAddress, “remoteAddress”);
this.validate();
return this.doResolveAndConnect(remoteAddress, this.config.localAddress());
}
connect 方法返回的是一个 Future 类型的对象

public interface ChannelFuture extends Future {
…
}
也就是说这个方是异步的，我们通过 addListener 方法可以监听到连接是否成功，进而打印出连接信息。具体做法很简单，只需要对代码进行以下改动：

ChannelFuture f = b.connect(host, port).addListener(future -> {
if (future.isSuccess()) {
System.out.println(“连接成功!”);
} else {
System.err.println(“连接失败!”);
}
}).sync();

参考
 参考