Netty 源码：从“点”（领域知识）的角度剖析

目录

Netty 源码：从“点”（领域知识）的角度剖析

一、Netty 怎么切换三种I/O 模式

• 什么是经典的三种I/O 模式

• Netty 对三种I/O 模式的支持

• 为什么Netty 仅支持NIO 了？

• 为什么Netty 有多种NIO 实现？

• NIO 一定优于BIO 么？

• 源码解读Netty 怎么切换I/O 模式？

二、Netty 如何支持三种Reactor

• 什么是Reactor 及三种版本

​• 如何在Netty 中使用Reactor 模式

• 解析Netty 对Reactor 模式支持的常见疑问

三、TCP 粘包/半包解决方法

• 什么是粘包和半包？

​• 为什么TCP 应用中会出现粘包和半包现象？

• 解决粘包和半包问题的几种常用方法

• Netty 对三种常用封帧方式的支持

• 解读Netty 处理粘包、半包的源码

四、常用的“二次”编解码方式

• 为什么需要“二次”解码？

• 常用的“二次”编解码方式

• 选择编解码方式的要点

• Protobuf 简介与使用

• 源码解读：Netty 对二次编解码的支持

一、Netty 怎么切换三种I/O 模式

• 什么是经典的三种I/O 模式

阻塞与非阻塞：

阻塞：没有数据传过来时，读会阻塞直到有数据；缓冲区满时，写操作也会阻塞。
非阻塞遇到这些情况，都是直接返回。

同步与异步：

数据就绪后需要自己去读是同步，数据就绪直接读好再回调给程序是异步。

BIO （阻塞I/O）

NIO （非阻塞I/O）

AIO（异步I/O）

• Netty 对三种I/O 模式的支持

• 为什么Netty 仅支持NIO 了？

1.为什么不建议（deprecate）阻塞I/O（BIO/OIO）?
连接数高的情况下：阻塞-> 耗资源、效率低
2.为什么删掉已经做好的AIO 支持？
Windows 实现成熟，但是很少用来做服务器。
3.Linux 常用来做服务器，但是AIO 实现不够成熟。
Linux 下AIO 相比较NIO 的性能提升不明显。

• 为什么Netty 有多种NIO 实现？

通用的NIO 实现（Common）在Linux 下也是使用epoll，为什么自己单独实现？
实现得更好！
• Netty 暴露了更多的可控参数，例如：
• JDK 的NIO 默认实现是水平触发
• Netty 是边缘触发（默认）和水平触发可切换
• Netty 实现的垃圾回收更少、性能更好

• NIO 一定优于BIO 么？

• BIO 代码简单。
• 特定场景：连接数少，并发度低，BIO 性能不输NIO。

• 源码解读Netty 怎么切换I/O 模式？

以Netty源码中的echoservice为例

Nio切换至Oio仅仅需要两三行代码

1.切换开发模式

源码例子：NioEventLoop.run() 是一个Reactor模式的实现，就是一种开发模式

2.切换channel

源码例子：源码中比如ServerSocketChannel就是使用：工厂模式+泛型+反射实现

获得泛型的构造器，在创建连接的时候会反射出对象 

二、Netty 如何支持三种Reactor

• 什么是Reactor 及三种版本

ThreadThread-Per-Connection 模式：

Reactor 模式V1：单线程

Reactor 模式V2：多线程

Reactor 模式V3：主从多线程

• 如何在Netty 中使用Reactor 模式

Reactor单线程多线程模式区别主要是构造方法中传入的线程数，如果不传默认根据当前机器cpu核数计算

• 解析Netty 对Reactor 模式支持的常见疑问

1.Netty 如何支持主从Reactor 模式的？

主要看这个group中set的两个主从EventLoopGroup，其中主group主要是维护在AbstractBootstrap的成员变量中

使用，这个父Socket可以用于创建子channel

2.Netty 给Channel 分配NIO event loop 的规则是什么

主要看EventLoopGroup.register()

这个是NioEventLoop的实现

接下来看next()，主要是个策略模式（多种算法）

第一种，取模

第二种在2的幂次方时候，才能用，位运算

3.通用模式的NIO 实现多路复用器是怎么跨平台的

主要看NioEventLoopGroup

第一个走环境变量，第二个走SPI机制，查jar包的META-INF/services目录

可以看到跨平台的逻辑了

三、TCP 粘包/半包解决方法

• 什么是粘包和半包？

• 为什么TCP 应用中会出现粘包和半包现象？

粘包的主要原因：
• 发送方每次写入数据< 套接字缓冲区大小
• 接收方读取套接字缓冲区数据不够及时

半包的主要原因：
• 发送方写入数据> 套接字缓冲区大小
• 发送的数据大于协议的MTU（Maximum Transmission Unit，最大传输单元），必须拆包

根本原因：
TCP 是流式协议，消息无边界。
提醒：UDP 像邮寄的包裹，虽然一次运输多个，但每个包裹都有“界限”，一个一个签收，
所以无粘包、半包问题。

• 解决粘包和半包问题的几种常用方法

解决问题的根本手段：找出消息的边界：

• Netty 对三种常用封帧方式的支持

• 解读Netty 处理粘包、半包的源码

主要看ByteToMessageDecoder.channelRead()

先判断msg是不是ByteBuf，即netty处理过的数据，如果不是说明是第一笔，就直接传给数据积累器

否则走追加

解码核心逻辑就是这个抽象方法

FixedLengthFrameDecoder就是刚才介绍的固定边缘长度的逻辑，看代码很容易理解，半包不处理，粘包只处理固定长度的

四、常用的“二次”编解码方式

• 为什么需要“二次”解码？

那么我们在项目中，除了可选的的压缩解压缩之外，还需要一层解码，因为一次解码的结
果是字节，需要和项目中所使用的对象做转化，方便使用，这层解码器可以称为“二次解
码器”，相应的，对应的编码器是为了将Java 对象转化成字节流方便存储或传输。

当然也不推荐合并一次、二次解码，因为没有分层、且耦合度太高

• 常用的“二次”编解码方式

• Java 序列化
• Marshaling
• XML
• JSON
• MessagePack
• Protobuf
• 其他

• 选择编解码方式的要点

空间：编码后占用空间

时间：编解码速度

可读性

多语言（Java、C、Python 等）的支持

• Protobuf 简介与使用

• Protobuf 是一个灵活的、高效的用于序列化数据的协议。
• 相比较XML 和JSON 格式，Protobuf 更小、更快、更便捷。
• Protobuf 是跨语言的，并且自带了一个编译器（protoc），只需要用它进行编译，可
以自动生成Java、python、C++ 等代码，不需要再写其他代码。

备注：本文皆转自极客时间-netty源码剖析与实战，本人仅作整理和部分解读，用于记录和记忆留存！