【网络编程】netty

1.Netty 是什么？

Netty 是一个异步的、基于事件驱动的网络通信框架，可以快速开发 高性能的 服务器和客户端。

Netty是基于nio的，它封装了jdk的nio，用起来更加方便灵活。

2.Netty 的特点是什么？

• 高并发：NIO 并发性比 BIO 高。
• 传输快：零拷贝。
• 封装好：封装了 NIO 的很多细节，提供了易用的接口，使用更简单。

3.Netty 的优势有哪些？

• 易用：封装了 NIO 的很多细节，提供了易用的接口，使用更简单。
• 稳定：Netty 修复了 NIO 中所有已知 bug（包括臭名昭著的 Epoll Bug，它会导致 Selector 空轮询，最终导致 CPU 100%。直到 JDK 1.7 版本该问题仍旧存在，没有被根本解决），让开发人员可以专注于业务本身。
• 定制能力强：可以通过 ChannelHandler 灵活扩展框架。
• 功能强大：预置了多种编解码功能，支持多种主流协议。
• 社区活跃：Netty 是活跃的开源项目，版本迭代周期短，bug 修复速度快。
• 性能高：通过与其他业界主流的 NIO 框架对比，Netty 的综合性能最优。

4.Netty 的应用场景有哪些？

典型的应用有：

• Elasticsearch
• 阿里分布式服务框架 Dubbo
• RocketMQ
• 大数据的Avro

5.Netty 高性能表现在哪些方面？

• IO线程模型：使用NIO，同步（核实） 非阻塞，用最少的资源做更多的事。
• 内存零拷贝：尽量减少不必要的内存拷贝，实现了更高效率的传输。
• 内存池设计：申请的内存可以重用，主要指直接内存。内部实现是用一颗二叉查找树管理内存分配情况。（不熟）
• 串形化处理读写：在通道中使用一连串的Handler处理数据，避免使用锁带来的性能开销。
• 序列化协议：支持 protobuf 等高性能序列化协议。

6.BIO、NIO和AIO的区别？

三者都是java支持的IO模型，就是用什么样的通道进行数据的发送和接收，这很大程度上决定了程序通信的性能。

• BIO：同步阻塞，一个连接一个线程，客户端有连接请求时服务器端就需要启动一个线程进行处理。如果这个连接不做任何事情会造成不必要的线程开销。
  伪异步IO：将请求连接放入线程池，一对多，但线程还是很宝贵的资源。

• NIO：同步非阻塞，（不懂）一个请求一个线程 ，但客户端发送的连接请求都会注册到多路复用器上，多路复用器轮询到连接有I/O请求时，才启动一个线程进行处理。服务器实现模式为一个线程处理多个请求。

• AIO：异步非阻塞，一个有效请求一个线程，AIO 引入异步通道的概念，先由操作系统完成后才通知服务端程序启动线程去处理，一般适用于连接数较多且连接时间较长的应用。

BIO、NIO、AIO适用场景对比

• BIO方式适用于连接数目比较小且固定的架构，这种方式对服务器资源要求比较高，并发局限于应用中，JDK1.4以前的唯一选择，但程序简单易理解。

• NIO方式适用于连接数目多且连接比较短（轻操作）的架构，比如聊天服务器，弹幕系统，服务器间通讯等。编程比较复杂，JDK1.4开始支持。

• AIO方式使用于连接数目多且连接比较长（重操作）的架构，比如相册服务器，充分调用OS参与并发操作，编程比较复杂，JDK7开始支持。

（1）BIO和NIO区别

• BIO是面向流的，NIO是面向缓冲区的；
• BIO的各种流是阻塞的，而NIO是非阻塞的；
• BIO的Stream是单向的，而NIO的channel是双向的。
• BIO基于字节流和字符流进行操作，而 NIO 基于 Channel(通道)和 Buffer(缓冲区)进行操作。数据总是从通道读取到缓冲区中，或者从缓冲区写入到通道中。Selector(选择器)用于监听多个通道的事件（比如：连接请求，数据到达等），因此使用单个线程就可以监听多个客户端通道。

（2）NIO的特点

• 事件驱动模型
• 单线程处理多任务
• 非阻塞I/O，I/O读写不再阻塞，没有事件发生就返回0
• 基于缓冲区的传输比基于流的传输更高效
• 零拷贝，更高级的IO函数zero-copy
• IO多路复用，大大提高了网络应用的可伸缩性和实用性
• 基于Reactor线程模型

（3）Reactor模式工作流程

• 将事件类型和事件处理器Handler注册到事件分发器Selector上
• Selector等待某个事件发生
• 某个事件发生（读、写、连接）
• Selector就把这个事件传给Handler，Handler来做实际的读写操作。

如在Reactor中实现读：

• 将读事件和相应的事件处理器ReadHandler注册到时间分发器Selector上
• Selector等待读事件
• 读事件到来，激活Selector
• Selector调用ReadHandler，ReadHandler完成实际的读操作，并处理读到的数据

7.NIO的组成？

三大核心：Channel(通道)，Buffer(缓冲区), Selector(选择器)

• Buffer：与Channel进行交互，数据是从Channel读入缓冲区，从缓冲区写入Channel中的。
  flip方法 ： 反转此缓冲区，将position给limit，然后将position置为0，其实就是切换读写模式
  clear方法 ：清除此缓冲区，将position置为0，把capacity的值给limit。
  rewind方法 ： 重绕此缓冲区，将position置为0
  不懂 DirectByteBuffer可减少一次系统空间到用户空间的拷贝。但Buffer创建和销毁的成本更高，不可控，通常会用内存池来提高性能。直接缓冲区主要分配给那些易受基础系统的本机I/O 操作影响的大型、持久的缓冲区。如果数据量比较小的中小应用情况下，可以考虑使用heapBuffer，由JVM进行管理。

• Channel：是传输时 数据源与目标 之间打开的通道，是双向的，但不能直接访问数据，只能与Buffer 进行交互。常用的 Channel 类有：FileChannel、DatagramChannel、ServerSocketChannel 和 SocketChannel。【ServerSocketChanne 类似 ServerSocket , SocketChannel 类似 Socket】。FileChannel 用于文件的数据读写，DatagramChannel 用于 UDP 的数据读写，ServerSocketChannel 和 SocketChannel 用于 TCP 的数据读写。
  （不懂）通过源码可知，FileChannel的read方法和write方法都导致数据复制了两次！

• Selector可以用一个线程，处理多个的客户端连接。Selector 能够检测多个注册的通道上是否有事件发生(注意:多个Channel以事件的方式可以注册到同一个Selector)，如果有事件发生，便获取事件然后针对每个事件进行相应的处理。这样就可以只用一个单线程去管理多个通道，也就是管理多个连接和请求。只有在 连接/通道 真正有读写事件发生时，才会进行读写，就大大地减少了系统开销，并且不必为每个连接都创建一个线程，不用去维护多个线程。避免了多线程之间的上下文切换导致的开销。
  （1）open方法可创建Selector
  （2）register(Selector sel, int ops)方法向多路复用器注册通道，可以监听的事件类型：read，write，accept，connect事件。注册事件后会产生一个SelectionKey：它表示SelectableChannel 和Selector 之间的注册关系。
  （3）wakeup方法：使尚未返回的第一个select操作立即返回。唤醒的原因是：注册了新的channel或者事件；channel关闭，取消注册；优先级更高的事件触发（如定时器事件），希望及时处理。
  （4）selectedKeys方法：从内部集合中得到所有的selectedKey。SelectionKey，表示 Selector 和网络通道的注册关系, 共四种:
  int OP_ACCEPT：有新的网络连接可以 accept，值为 16
  int OP_CONNECT：代表连接已经建立，值为 8
  int OP_READ：代表读操作，值为 1
  int OP_WRITE：代表写操作，值为 4
  （不懂）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 = Selector.open()：打开一个Selector；
• serverSocketChannel = ServerSocketChannel.open()：打开一个服务端的Channel；
  serverSocketChannel.bind()：绑定到某个端口上；
  serverSocketChannel.configureBlocking(false)：配置非阻塞模式；
  serverSocketChannel.register(selector, SelectionKey.OP_ACCEPT);注册serverSocketChannel和关注的accept事件到当前线程中的selector；
• socketChannel = serverSocketChannel.accept()：接受连接，返回代表这个连接的通道对象；
  socketChannel.configureBlocking(false);配置非阻塞模式；
  socketChannel.register(selector, SelectionKey.OP_READ, ByteBuffer.allocate(1024))：注册socketChannel和关注的read事件到当前线程中的selector；
• selector.select(timeout)轮询等待事件发生。

8.Netty的线程模型？

目前存在的线程模型有：传统阻塞 I/O 服务模型、Reactor 模式。
铺垫1：传统阻塞：

Reactor：

Reactor 模式中 核心组成：

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

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

根据 Reactor 的数量和处理资源池线程的数量不同，有 3 种典型的实现：

• 单 Reactor 单线程；
• 单 Reactor 多线程；
• 主从 Reactor 多线程；

铺垫2：单 Reactor 单线程：

• Reactor 对象通过 Select 监控客户端请求事件，收到事件后通过 Dispatch 进行分发
• 如果是建立连接请求事件，则由Acceptor 通过 Accept 处理连接请求，然后创建一个 Handler 对象处理连接完成后的后续业务处理
• 如果不是建立连接事件，则 Reactor 会分发调用连接对应的 Handler 来响应
• Handler 会完成Read→业务处理→Send 的完整业务流程

结合实例：服务器端用一个线程通过多路复用搞定所有的 IO 操作（包括连接，读、写等），编码简单，清晰明了，但是如果客户端连接数量较多，将无法支撑，前面的 NIO 案例就属于这种模型。

优缺点如下：

• 优点：模型简单，没有多线程、进程通信、竞争的问题，全部都在一个线程中完成
• 缺点：性能问题，只有一个线程，无法完全发挥多核 CPU 的性能。Handler 在处理某个连接上的业务时，整个进程无法处理其他连接事件，很容易导致性能瓶颈
• 缺点：可靠性问题，线程意外终止，或者进入死循环，会导致整个系统通信模块不可用，不能接收和处理外部消息，造成节点故障

使用场景：客户端的数量有限，业务处理非常快速，比如 Redis在业务处理的时间复杂度 O(1) 的情况。

铺垫3：单 Reactor 多线程：

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

优缺点如下：

• 优点：可以充分的利用多核cpu 的处理能力
• 缺点：多线程数据共享和访问比较复杂， reactor 处理所有的事件的监听和响应，在单线程运行， 在高并发场景容易出现性能瓶颈.
  
  铺垫4：主从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 子线程, 即MainReactor 可以关联多个SubReactor

优缺点如下：

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

结合实例：这种模型在许多项目中广泛使用，包括 Nginx 主从 Reactor 多进程模型，Memcached 主从多线程，Netty 主从多线程模型的支持。

对铺垫的总结：

3 种模式用生活案例来理解：

• 单 Reactor 单线程，前台接待员和服务员是同一个人，全程为顾客服
• 单 Reactor 多线程，1 个前台接待员，多个服务员，接待员只负责接待
• 主从 Reactor 多线程，多个前台接待员，多个服务生

Reactor 模式具有如下的优点：

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

正餐：Netty 线程模式：
Netty 主要基于主从 Reactor 多线程模型做了一定的改进，其中主从 Reactor 多线程模型有多个 Reactor。

总体来说是：

• BossGroup 线程维护Selector , 只关注Accecpt
• 当接收到Accept事件，获取到对应的SocketChannel, 封装成 NIOScoketChannel并注册到Worker 线程(事件循环), 并进行维护
• 当Worker线程监听到selector 中通道发生自己感兴趣的事件后，就进行处理(就由handler)， 注意handler 已经加入到通道

具体来说：

1. Netty抽象出两组线程池 BossGroup 专门负责接收客户端的连接, WorkerGroup 专门负责网络的读写

2. BossGroup 和 WorkerGroup 类型都是 NioEventLoopGroup

3. NioEventLoopGroup相当于一个事件循环组, 这个组中含有多个事件循环 ，每一个事件循环是 NioEventLoop

4. NioEventLoop表示一个不断循环的执行处理任务的线程，每个NioEventLoop 都有一个selector，用于监听绑定在其上的socket的网络通讯

5. NioEventLoopGroup 可以有多个线程, 即可以含有多个NioEventLoop

6. 每个Boss NioEventLoop 循环执行的步骤有3步
   （1）轮询accept 事件
   （2）处理accept 事件，与client建立连接，生成NioScocketChannel , 并将其注册到某个worker NIOEventLoop 上的 selector
   （3）处理任务队列的任务 ， 即 runAllTasks

7. 每个 Worker NIOEventLoop 循环执行的步骤
   轮询read，write 事件
   处理i/o事件， 即read , write 事件，在对应NioScocketChannel 处理
   处理任务队列的任务，即 runAllTasks

8. 每个Worker NIOEventLoop 处理业务时，会使用pipeline(管道)，pipeline 中包含了 channel , 即通过pipeline 可以获取到对应通道, 管道中维护了很多的 处理器
   

Netty通过Reactor模型基于多路复用器接收并处理用户请求，内部实现了两个线程池，boss线程池和work线程池，其中boss线程池的线程负责处理请求的accept事件，当接收到accept事件的请求时，把对应的socket封装到一个NioSocketChannel中，并交给work线程池，其中work线程池负责请求的read和write事件，由对应的Handler处理。

9.TCP 粘包/拆包的原因及解决方法？

TCP是以流的方式来处理数据，一个完整的包可能会被TCP拆分成多个包进行发送，也可能把小的封装成一个大的数据包发送。

TCP粘包/分包的原因：

应用程序写入的字节大小大于套接字发送缓冲区的大小，会发生拆包现象；
而应用程序写入数据小于套接字缓冲区大小，网卡将应用多次写入的数据发送到网络上，这将会发生粘包现象；

进行MSS大小的TCP分段，当TCP报文长度-TCP头部长度>MSS的时候将发生拆包
以太网帧的payload（净荷）大于MTU（1500字节）进行ip分片。

解决方法：

• 消息定长：FixedLengthFrameDecoder类

• 包尾增加特殊字符分割：
  行分隔符类：LineBasedFrameDecoder
  自定义分隔符类 ：DelimiterBasedFrameDecoder

• 将消息分为消息头和消息体：LengthFieldBasedFrameDecoder类。（不懂）分为有头部的拆包与粘包、长度字段在前且有头部的拆包与粘包、多扩展头部的拆包与粘包。

10.什么是 Netty 的零拷贝？

10.1 传统的零拷贝

在 Java 程序中，常用的零拷贝有 mmap(内存映射) 和 sendFile。

（1）传统IO的劣势

Java 传统 IO 和 网络编程的一段代码

File file = new File("index.html");
RandomAccessFile raf = new RandomAccessFile(file, "rw");

byte[] arr = new byte[(int) file.length()];
raf.read(arr);

Socket socket = new ServerSocket(8080).accept();
socket.getOutputStream().write(arr);

我们会调用 read 方法读取 index.html 的内容 —— 变成字节数组，然后调用 write 方法，将 index.html 字节流写到 socket 中，那么，我们调用这两个方法，在 OS 底层发生了什么呢？我这里借鉴了一张其他文章的图片，尝试解释这个过程。

上图中，上半部分表示用户态和内核态的上下文切换。下半部分表示数据复制操作。下面说说他们的步骤：

• read 调用导致用户态到内核态的一次变化，同时，第一次复制开始：DMA（Direct Memory Access，直接内存存取，即不使用 CPU 拷贝数据到内存，而是 DMA 引擎传输数据到内存，用于解放 CPU） 引擎从磁盘读取 index.html 文件，并将数据放入到内核缓冲区。

• 发生第二次数据拷贝，即：将内核缓冲区的数据拷贝到用户缓冲区，同时，发生了一次用内核态到用户态的上下文切换。

• 发生第三次数据拷贝，我们调用 write 方法，系统将用户缓冲区的数据拷贝到 Socket 缓冲区。此时，又发生了一次用户态到内核态的上下文切换。

• 第四次拷贝，数据异步的从 Socket 缓冲区，使用 DMA 引擎拷贝到网络协议引擎。这一段，不需要进行上下文切换。

• write 方法返回，再次从内核态切换到用户态。

如你所见，复制拷贝操作太多了。如何优化这些流程？

（2）mmap 优化

mmap 通过内存映射，将文件映射到内核缓冲区，同时，用户空间可以共享内核空间的数据。这样，在进行网络传输时，就可以减少内核空间到用户空间的拷贝次数。如下图：

如上图，user buffer 和 kernel buffer 共享 index.html。如果你想把硬盘的 index.html 传输到网络中，再也不用拷贝到用户空间，再从用户空间拷贝到 Socket 缓冲区。

现在，你只需要从内核缓冲区拷贝到 Socket 缓冲区即可，这将减少一次内存拷贝（从 4 次变成了 3 次），但不减少上下文切换次数。

（3）sendFile

那么，我们还能继续优化吗？ Linux 2.1 版本 提供了 sendFile 函数，其基本原理如下：数据根本不经过用户态，直接从内核缓冲区进入到 Socket Buffer，同时，由于和用户态完全无关，就减少了一次上下文切换。

如上图，我们进行 sendFile 系统调用时，数据被 DMA 引擎从磁盘文件复制到内核缓冲区，然后调用 write 方法时，从内核缓冲区进入到 Socket，这时，是没有上下文切换的，因为都在内核空间。

最后，数据从 Socket 缓冲区进入到协议栈。此时，数据经过了 3 次拷贝，3 次上下文切换。那么，还能不能再继续优化呢？ 例如直接从内核缓冲区拷贝到网络协议栈？

实际上，Linux 在 2.4 版本中，做了一些修改，避免了从内核缓冲区拷贝到 Socket buffer 的操作，直接拷贝到协议栈，从而再一次减少了数据拷贝。具体如下图：

现在，index.html 要从文件进入到网络协议栈，只需 2 次拷贝：第一次使用 DMA 引擎从文件拷贝到内核缓冲区，第二次从内核缓冲区将数据拷贝到网络协议栈；内核缓存区只会拷贝一些 offset 和 length 等描述信息到 SocketBuffer，基本无消耗。

等一下，不是说零拷贝吗？为什么还是要 2 次拷贝？

首先我们说零拷贝，是从操作系统的角度来说的，没有CPU拷贝可以认为是零拷贝。另外，因为内核缓冲区之间，没有数据是重复的，可以认为是零拷贝（只在 kernel buffer 中有一份数据，sendFile 2.1 版本实际上有 2 份数据，算不上零拷贝）。

而零拷贝不仅仅带来更少的数据复制，还能带来其他的性能优势，例如更少的上下文切换，更少的 CPU 缓存伪共享以及无 CPU 校验和计算。

再稍微讲讲 mmap 和 sendFile 的区别。

• mmap 适合小数据量读写，sendFile 适合大文件传输。
• mmap 需要 4 次上下文切换，3 次数据拷贝；sendFile 需要 3 次上下文切换，最少 2 次数据拷贝。
• sendFile 可以利用 DMA 方式，减少 CPU 拷贝，mmap 则不能（必须从内核拷贝到 Socket 缓冲区）。

在这个选择上：rocketMQ 在消费消息时，使用了 mmap。kafka 使用了 sendFile。

（4）Java中的例子

kafka 在客户端和 broker 进行数据传输时，会使用 transferTo 和 transferFrom 方法，即对应 Linux 的 sendFile。

tomcat 内部在进行文件拷贝的时候，也会使用 transferto 方法。

tomcat 在处理一下心跳保活时，也会调用该 sendFile 方法。

所以，如果你需要优化网络传输的性能，或者文件读写的速度，请尽量使用零拷贝。它不仅能较少复制拷贝次数，还能较少上下文切换，缓存行污染。

10.2 Netty的零拷贝

Netty中的零拷贝与我们传统理解的零拷贝不太一样。

传统的零拷贝指的是数据传输过程中，不需要CPU进行数据的拷贝。主要是数据在用户空间与内核中间之间的拷贝。

Zero-Copy describes computer operations in which the CPU does not perform the task of copying data from one memory area to another.

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

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

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

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中的零拷贝又有所优化。

Netty中也用到了FileChannel.transferTo方法，所以Netty的零拷贝也包括上面讲的操作系统级别的零拷贝。除此之外，在ByteBuf的实现上，Netty也提供了零拷贝的一些实现。

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

1. ByteBuf
2. ByteBufHolder

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

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

Direct Buffers

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

Composite Buffers

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

对于FileChannel.transferTo的使用

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

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

1. Netty的接收和发送ByteBuffer采用DIRECT BUFFERS，使用堆外直接内存进行Socket读写，不需要进行字节缓冲区的二次拷贝。如果使用传统的堆内存（HEAP BUFFERS）进行Socket读写，JVM会将堆内存Buffer拷贝一份到直接内存中，然后才写入Socket中。相比于堆外直接内存，消息在发送过程中多了一次缓冲区的内存拷贝。

2. Netty提供了组合Buffer对象，可以聚合多个ByteBuffer对象，用户可以像操作一个Buffer那样方便的对组合Buffer进行操作，避免了传统通过内存拷贝的方式将几个小Buffer合并成一个大的Buffer。

3. Netty的文件传输采用了transferTo方法，它可以直接将文件缓冲区的数据发送到目标Channel，避免了传统通过循环write方式导致的内存拷贝问题。

11.Netty 中有哪种重要组件？

• Channel：Netty 网络操作抽象类，包括基本的 I/O 操作，如 bind、connect、read、write 等。
• EventLoop：主要是配合 Channel 处理 I/O 操作，用来处理连接时发生的事情。
• ChannelFuture：Netty 框架中所有的 I/O 操作都为异步的，因此我们需要 ChannelFuture 的 addListener()注册一个 ChannelFutureListener 监听事件，当操作执行成功或者失败时，监听就会自动触发返回结果。
• ChannelHandler：充当了所有处理入站和出站数据的逻辑容器。ChannelHandler 主要用来处理各种事件，这里的事件很广泛，比如可以是连接、数据接收、异常、数据转换等。
• ChannelPipeline：为 ChannelHandler 链提供了容器，当 channel 创建时，就会被自动分配到它专属的 ChannelPipeline，这个关联是永久性的。

12.Netty 发送消息有几种方式？

Netty 有两种发送消息的方式：

• 直接写入 Channel 中，消息从 ChannelPipeline 当中尾部开始移动；
• 写入和 ChannelHandler 绑定的 ChannelHandlerContext 中，消息从 ChannelPipeline 中的下一个 ChannelHandler 中移动。

13.默认情况 Netty 起多少线程？何时启动？

Netty 默认是 CPU 处理器数的两倍，bind 完之后启动。

private static final int DEFAULT_EVENT_LOOP_THREADS = 
Math.max(1, SystemPropertyUtil.getInt("io.netty.eventLoopThreads", 
								NettyRuntime.availableProcessors() * 2));

14.了解哪几种序列化协议？

序列化（编码）是将对象序列化为二进制形式（字节数组），主要用于网络传输、数据持久化等；而反序列化（解码）则是将从网络、磁盘等读取的字节数组还原成原始对象，主要用于网络传输对象的解码，以便完成远程调用。

影响序列化性能的关键因素：序列化后的码流大小（网络带宽的占用）、序列化的性能（CPU资源占用）；是否支持跨语言（异构系统的对接和开发语言切换）。

Java默认提供的序列化：无法跨语言、序列化后的码流太大、序列化的性能差

XML，优点：人机可读性好，可指定元素或特性的名称。缺点：序列化数据只包含数据本身以及类的结构，不包括类型标识和程序集信息；只能序列化公共属性和字段；不能序列化方法；文件庞大，文件格式复杂，传输占带宽。适用场景：当做配置文件存储数据，实时数据转换。

JSON，是一种轻量级的数据交换格式，优点：兼容性高、数据格式比较简单，易于读写、序列化后数据较小，可扩展性好，兼容性好、与XML相比，其协议比较简单，解析速度比较快。缺点：数据的描述性比XML差、不适合性能要求为ms级别的情况、额外空间开销比较大。适用场景（可替代ＸＭＬ）：跨防火墙访问、可调式性要求高、基于Web browser的Ajax请求、传输数据量相对小，实时性要求相对低（例如秒级别）的服务。

Fastjson，采用一种“假定有序快速匹配”的算法。优点：接口简单易用、目前java语言中最快的json库。缺点：过于注重快，而偏离了“标准”及功能性、代码质量不高，文档不全。适用场景：协议交互、Web输出、Android客户端

Thrift，不仅是序列化协议，还是一个RPC框架。优点：序列化后的体积小, 速度快、支持多种语言和丰富的数据类型、对于数据字段的增删具有较强的兼容性、支持二进制压缩编码。缺点：使用者较少、跨防火墙访问时，不安全、不具有可读性，调试代码时相对困难、不能与其他传输层协议共同使用（例如HTTP）、无法支持向持久层直接读写数据，即不适合做数据持久化序列化协议。适用场景：分布式系统的RPC解决方案

Avro，Hadoop的一个子项目，解决了JSON的冗长和没有IDL的问题。优点：支持丰富的数据类型、简单的动态语言结合功能、具有自我描述属性、提高了数据解析速度、快速可压缩的二进制数据形式、可以实现远程过程调用RPC、支持跨编程语言实现。缺点：对于习惯于静态类型语言的用户不直观。适用场景：在Hadoop中做Hive、Pig和MapReduce的持久化数据格式。

Protobuf，将数据结构以.proto文件进行描述，通过代码生成工具可以生成对应数据结构的POJO对象和Protobuf相关的方法和属性。优点：序列化后码流小，性能高、结构化数据存储格式（XML JSON等）、通过标识字段的顺序，可以实现协议的前向兼容、结构化的文档更容易管理和维护。缺点：需要依赖于工具生成代码、支持的语言相对较少，官方只支持Java 、C++ 、python。适用场景：对性能要求高的RPC调用、具有良好的跨防火墙的访问属性、适合应用层对象的持久化

其它

protostuff 基于protobuf协议，但不需要配置proto文件，直接导包即可
Jboss marshaling 可以直接序列化java类， 无须实java.io.Serializable接口
Message pack 一个高效的二进制序列化格式
Hessian 采用二进制协议的轻量级remoting onhttp工具
kryo 基于protobuf协议，只支持java语言,需要注册（Registration），然后序列化（Output），反序列化（Input）

15.如何选择序列化协议？

具体场景

对于公司间的系统调用，如果性能要求在100ms以上的服务，基于XML的SOAP协议是一个值得考虑的方案。
基于Web browser的Ajax，以及Mobile app与服务端之间的通讯，JSON协议是首选。对于性能要求不太高，或者以动态类型语言为主，或者传输数据载荷很小的的运用场景，JSON也是非常不错的选择。
对于调试环境比较恶劣的场景，采用JSON或XML能够极大的提高调试效率，降低系统开发成本。
当对性能和简洁性有极高要求的场景，Protobuf，Thrift，Avro之间具有一定的竞争关系。
对于T级别的数据的持久化应用场景，Protobuf和Avro是首要选择。如果持久化后的数据存储在hadoop子项目里，Avro会是更好的选择。

对于持久层非Hadoop项目，以静态类型语言为主的应用场景，Protobuf会更符合静态类型语言工程师的开发习惯。由于Avro的设计理念偏向于动态类型语言，对于动态语言为主的应用场景，Avro是更好的选择。
如果需要提供一个完整的RPC解决方案，Thrift是一个好的选择。
如果序列化之后需要支持不同的传输层协议，或者需要跨防火墙访问的高性能场景，Protobuf可以优先考虑。
protobuf的数据类型有多种：bool、double、float、int32、int64、string、bytes、enum、message。protobuf的限定符：required: 必须赋值，不能为空、optional:字段可以赋值，也可以不赋值、repeated: 该字段可以重复任意次数（包括0次）、枚举；只能用指定的常量集中的一个值作为其值；

protobuf的基本规则：每个消息中必须至少留有一个required类型的字段、包含0个或多个optional类型的字段；repeated表示的字段可以包含0个或多个数据；[1,15]之内的标识号在编码的时候会占用一个字节（常用），[16,2047]之内的标识号则占用2个字节，标识号一定不能重复、使用消息类型，也可以将消息嵌套任意多层，可用嵌套消息类型来代替组。

protobuf的消息升级原则：不要更改任何已有的字段的数值标识；不能移除已经存在的required字段，optional和repeated类型的字段可以被移除，但要保留标号不能被重用。新添加的字段必须是optional或repeated。因为旧版本程序无法读取或写入新增的required限定符的字段。

编译器为每一个消息类型生成了一个.java文件，以及一个特殊的Builder类（该类是用来创建消息类接口的）。如：UserProto.User.Builder builder = UserProto.User.newBuilder();builder.build()；

Netty中的使用：ProtobufVarint32FrameDecoder 是用于处理半包消息的解码类；ProtobufDecoder(UserProto.User.getDefaultInstance())这是创建的UserProto.java文件中的解码类；ProtobufVarint32LengthFieldPrepender 对protobuf协议的消息头上加上一个长度为32的整形字段，用于标志这个消息的长度的类；ProtobufEncoder 是编码类

将StringBuilder转换为ByteBuf类型：copiedBuffer()方法

16.Netty 支持哪些心跳类型设置？

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

17.Netty 和 Tomcat 的区别？

• 作用不同：Tomcat 是 Servlet 容器，可以视为 Web 服务器，而 Netty 是异步事件驱动的网络应用程序框架和工具用于简化网络编程，例如TCP和UDP套接字服务器。
• 协议不同：Tomcat 是基于 http 协议的 Web 服务器，而 Netty 能通过编程自定义各种协议，因为 Netty 本身自己能编码/解码字节流，所有 Netty 可以实现，HTTP 服务器、FTP 服务器、UDP 服务器、RPC 服务器、WebSocket 服务器、Redis 的 Proxy 服务器、MySQL 的 Proxy 服务器等等。

18.NIOEventLoopGroup源码？

NioEventLoopGroup(其实是MultithreadEventExecutorGroup) 内部维护一个类型为 EventExecutor children [], 默认大小是处理器核数 * 2, 这样就构成了一个线程池，初始化EventExecutor时NioEventLoopGroup重载newChild方法，所以children元素的实际类型为NioEventLoop。

线程启动时调用SingleThreadEventExecutor的构造方法，执行NioEventLoop类的run方法，首先会调用hasTasks()方法判断当前taskQueue是否有元素。如果taskQueue中有元素，执行 selectNow() 方法，最终执行selector.selectNow()，该方法会立即返回。如果taskQueue没有元素，执行 select(oldWakenUp) 方法

select ( oldWakenUp) 方法解决了 Nio 中的 bug，selectCnt 用来记录selector.select方法的执行次数和标识是否执行过selector.selectNow()，若触发了epoll的空轮询bug，则会反复执行selector.select(timeoutMillis)，变量selectCnt 会逐渐变大，当selectCnt 达到阈值（默认512），则执行rebuildSelector方法，进行selector重建，解决cpu占用100%的bug。

rebuildSelector方法先通过openSelector方法创建一个新的selector。然后将old selector的selectionKey执行cancel。最后将old selector的channel重新注册到新的selector中。rebuild后，需要重新执行方法selectNow，检查是否有已ready的selectionKey。

接下来调用processSelectedKeys 方法（处理I/O任务），当selectedKeys != null时，调用processSelectedKeysOptimized方法，迭代 selectedKeys 获取就绪的 IO 事件的selectkey存放在数组selectedKeys中, 然后为每个事件都调用 processSelectedKey 来处理它，processSelectedKey 中分别处理OP_READ；OP_WRITE；OP_CONNECT事件。

最后调用runAllTasks方法（非IO任务），该方法首先会调用fetchFromScheduledTaskQueue方法，把scheduledTaskQueue中已经超过延迟执行时间的任务移到taskQueue中等待被执行，然后依次从taskQueue中取任务执行，每执行64个任务，进行耗时检查，如果已执行时间超过预先设定的执行时间，则停止执行非IO任务，避免非IO任务太多，影响IO任务的执行。

每个NioEventLoop对应一个线程和一个Selector，NioServerSocketChannel会主动注册到某一个NioEventLoop的Selector上，NioEventLoop负责事件轮询。

Outbound 事件都是请求事件, 发起者是 Channel，处理者是 unsafe，通过 Outbound 事件进行通知，传播方向是 tail到head。Inbound 事件发起者是 unsafe，事件的处理者是 Channel, 是通知事件，传播方向是从头到尾。

内存管理机制，首先会预申请一大块内存Arena，Arena由许多Chunk组成，而每个Chunk默认由2048个page组成。Chunk通过AVL树的形式组织Page，每个叶子节点表示一个Page，而中间节点表示内存区域，节点自己记录它在整个Arena中的偏移地址。当区域被分配出去后，中间节点上的标记位会被标记，这样就表示这个中间节点以下的所有节点都已被分配了。大于8k的内存分配在poolChunkList中，而PoolSubpage用于分配小于8k的内存，它会把一个page分割成多段，进行内存分配。

ByteBuf的特点：支持自动扩容（4M），保证put方法不会抛出异常、通过内置的复合缓冲类型，实现零拷贝（zero-copy）；不需要调用flip()来切换读/写模式，读取和写入索引分开；方法链；引用计数基于AtomicIntegerFieldUpdater用于内存回收；PooledByteBuf采用二叉树来实现一个内存池，集中管理内存的分配和释放，不用每次使用都新建一个缓冲区对象。UnpooledHeapByteBuf每次都会新建一个缓冲区对象。

————————————————
版权声明：本文为CSDN博主「ThinkWon」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/ThinkWon/article/details/104391081

19. Netty中常说的NIO与Netty的异步事件有什么关系？

没有关系。

Netty是异步事件驱动的框架，网络IO模型采用的是NIO（同步非阻塞IO）。异步事件驱动框架体现在所有的I/O操作是异步的，所有的IO调用会立即返回，并不保证调用成功与否，但是调用会返回ChannelFuture，netty会通过ChannelFuture通知你调用是成功了还是失败了亦或是取消了。

所以所谓的异步是针对用户而言的，用户使用Channel进行IO操作，会立即返回。但是这个IO操作的任务是提交给了Netty的NIO底层去进行处理，所以我们说Netty的异步事件驱动与Netty底层基于NIO（同步非阻塞）是不矛盾的。

另一个大佬的回答：
NIO为底层：netty使用了IO多路复用，比如epoll。
事件驱动：一个NioEventLoop中有一个主循环和一个任务队列，所有事件只管往队列里塞，主循环则从队列里取出并处理。如果不依赖于多路复用，处理多个任务就会需要多线程（与连接数对等），但是依赖于多路复用，这个循环就可以在单线程的情况下处理多个连接。无论是哪个连接发生了什么事件，都会被主循环从队列中取出并处理（可用回调函数处理），也就是说程序的走向由事件驱动，有事件产生才会触发程序操作。
至于异步，只是说对用户来说看起来是异步，但是实际nio只是同步非阻塞。

————————————————
版权声明：本文为CSDN博主「Leahy000」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/weixin_41954254/article/details/106414746

20. 示例

NettyServer.java

public class NettyServer {
    public static void main(String[] args) throws Exception {

        //创建BossGroup 和 WorkerGroup
        //说明：
        //1. 创建两个线程组 bossGroup 和 workerGroup
        //2. bossGroup 只是处理连接请求 , 真正的和客户端业务处理，会交给 workerGroup完成
        //3. 两个都是无限循环
        //4. bossGroup 和 workerGroup 含有的子线程(NioEventLoop)的个数 ： 默认值： 实际cpu核数 * 2
        EventLoopGroup bossGroup = new NioEventLoopGroup(1);// 明确要求只创建1个，那 bossGroup 里就只创建1个 NioEventLoop 线程
        EventLoopGroup workerGroup = new NioEventLoopGroup(); //如果 cpu 是4核的，那就创建8个 NioEventLoop 线程

        try {
            //创建服务器端的启动对象，配置参数
            ServerBootstrap bootstrap = new ServerBootstrap();

            //使用链式编程来进行设置
            bootstrap.group(bossGroup, workerGroup) //设置两个线程组
                    .channel(NioServerSocketChannel.class) //使用 NioSocketChannel 作为服务器的通道实现（基于TCP连接）
                    .option(ChannelOption.SO_BACKLOG, 128) // 设置线程队列得到连接个数，大家都来连接的时候，处理第一个连接时，把其他连接先暂存到这个队列中，回头再处理，不至于丢失
                    .childOption(ChannelOption.SO_KEEPALIVE, true) // 保持活动连接，并不是完成1次收发就断开连接
                    .childHandler(new ChannelInitializer<SocketChannel>() {
                        @Override
                        protected void initChannel(SocketChannel ch) throws Exception {
                            ChannelPipeline pipeline = ch.pipeline();
                            pipeline.addLast(new NettyServerHandler()); //加入自己的处理器 NettyServerHandler
                        }
                    }); // 给我们的workerGroup 的 NioEventLoop 对应的管道设置处理器

            System.out.println(".....服务器 is ready...");

            //绑定一个端口并且同步, 生成了一个 ChannelFuture 对象
            //启动服务器(并绑定端口)
            ChannelFuture cf = bootstrap.bind(6668).sync();

            //给 cf 注册监听器，监控我们关心的事件（异步）
            cf.addListener(new ChannelFutureListener() {
                @Override
                public void operationComplete(ChannelFuture future) throws Exception {
                    if (future.isSuccess()) {
                        System.out.println("future成功");
                    } else {
                        System.out.println("future失败");
                    }

                    if (cf.isSuccess()) {
                        System.out.println("监听端口 6668 成功");
                    } else {
                        System.out.println("监听端口 6668 失败");
                    }
                }
            });

            //对关闭通道进行监听
            cf.channel().closeFuture().sync();
        } finally {
            bossGroup.shutdownGracefully();
            workerGroup.shutdownGracefully();
        }
    }
}

NettyServerHandler.java

/*
说明
1. 我们自定义一个Handler 需要继承 netty 规定好的某个HandlerAdapter(规范)
2. 这时我们自定义一个Handler , 才能称为一个handler
 */
public class NettyServerHandler extends ChannelInboundHandlerAdapter {

    /**
     * 读取客户端数据
     * <p>
     * 1. ChannelHandlerContext ctx:上下文对象, 含有 管道pipeline , 通道channel,  地址
     * 2. Object msg: 就是客户端发送的数据 默认Object
     */
    @Override
    public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception {
        // 从上下文中获取channel
        Channel channel = ctx.channel();
        System.out.println("服务器端负责读取消息的线程：" + Thread.currentThread().getName() + "  channle =" + channel);


        // 将 msg 转成一个 ByteBuf
        // ByteBuf 是 Netty 提供的，不是 NIO 的 ByteBuffer.
        ByteBuf buf = (ByteBuf) msg;
        String massage = buf.toString(CharsetUtil.UTF_8);
        System.out.println("客户端地址:" + channel.remoteAddress() + "  发送消息是:" + massage);
    }

    // 数据读取完毕
    @Override
    public void channelReadComplete(ChannelHandlerContext ctx) throws Exception {

        //writeAndFlush 是 write + flush, 将数据写入到缓存，并刷新
        //对这个发送的数据进行编码后发送
        ctx.writeAndFlush(Unpooled.copiedBuffer("hello, 客户端~(>^ω^<)喵", CharsetUtil.UTF_8));
    }

    // 处理异常, 一般是需要关闭通道
    @Override
    public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) throws Exception {
        ctx.close();
    }
}

NettyClient.java

public class NettyClient {
    public static void main(String[] args) throws Exception {

        //客户端只需要一个事件循环组
        EventLoopGroup group = new NioEventLoopGroup();

        try {
            //创建客户端启动对象
            //注意客户端使用的不是 ServerBootstrap 而是 Bootstrap
            Bootstrap bootstrap = new Bootstrap();

            //设置相关参数
            bootstrap.group(group) //设置线程组
                    .channel(NioSocketChannel.class) // 设置客户端通道的实现类(反射)
                    .handler(new ChannelInitializer<SocketChannel>() {
                        @Override
                        protected void initChannel(SocketChannel ch) throws Exception {
                            ChannelPipeline pipeline = ch.pipeline();
                            pipeline.addLast(new NettyClientHandler()); //加入自己的处理器 NettyClientHandler
                        }
                    });

            System.out.println("客户端 ok..");

            //启动客户端去连接服务器端
            //关于 ChannelFuture 要分析，涉及到netty的异步模型
            ChannelFuture channelFuture = bootstrap.connect("127.0.0.1", 6668).sync();
            //给关闭通道进行监听
            channelFuture.channel().closeFuture().sync();
        } finally {
            group.shutdownGracefully();
        }
    }
}

NettyClientHandler.java

public class NettyClientHandler extends ChannelInboundHandlerAdapter {

    //当通道就绪就会触发该方法
    @Override
    public void channelActive(ChannelHandlerContext ctx) throws Exception {
        ctx.writeAndFlush(Unpooled.copiedBuffer("hello, server: (>^ω^<)喵", CharsetUtil.UTF_8));
    }

    //当通道有读取事件时，会触发
    @Override
    public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception {

        ByteBuf buf = (ByteBuf) msg;
        System.out.println("服务器的地址：" + ctx.channel().remoteAddress() + "  回复的消息:" + buf.toString(CharsetUtil.UTF_8));
    }

    @Override
    public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) throws Exception {
        ctx.close();
    }
}

运行结果：
客户端1：
客户端2：

服务器端：