java开发技术之Netty几个核心类介绍

ByteBuf
JDK原生ByteBuffer的核心功能

1. 字节缓冲区，主要对字节进行操作的一个类
2. 能够将缓冲区建立在堆内和堆外。普通的new byte[] ,都只是建立在堆内

Netty之所以要自己封一套ByteBuf的主要原因是：

1. 原生ByteBuffer 容量固定，一旦分配不能动态扩容和收缩。
2. 原生ByteBuffer 的API使用不够优雅。稍有不慎，使用将会出错。它有3个核心指针，分别为position、 limit、capacity 。position : 位置，表示缓冲区中正在操作数据的位置。limit : 界限，表示缓冲区中可以操作数据的大小，（limit 后数据不能进行读写） capacity : 容量。读写需要调用flip()、rewind()、clear()等方法来移动相关指针 。

ByteBuf 呢？它使用了核心的两个位置指针来协助读写操作java培训，分别为readerIndex和writerIndex,数据读取readerIndex会增加，数据写入writerIndex会增加，不需要增加额外的操作来移动相关指针。此外 readerIndex 是不可能超过 writerIndex。读取过 的 0 ～ readerIndex 这部分空间是被视为弃用的，同时它可以进行自动扩容。
Channel
Channel 是网络操作抽象类，聚合了一组功能，提供了比原生Java SocketChannel、ServerSocketChannel大而全的功能接口，供业务开发者使用，包括但不限于网络的读、写、发起连接、关闭连接、获取通信双方的地址。
UnSafe
Channel 的辅助操作类，操作底层网络I/O，都是由它负责实现。
ChannelPipeLine
是Channel数据管道的一个抽象，消息在ChannelPipeLine中流动和传递。它根据I/O事件的类型，将消息传递给ChannelHandler进行处理。同时对ChannelHandler链表进行管理和调度。在读取数据时，ChannelHandler链表的调度顺序是ch1,ch2,ch3，写数据时调度顺序为ch3,ch2,ch1。可以说它是ChannelHandler的一个管理容器。
ChannelHandler
处理相应I/O事件的通道消息处理器，比如，读事件、写事件、读完成事件、写完成事件等，Netty中众多的编解码器等都是实现自 ChannelHandler。
ChannelHandlerContext
通道处理器上下文，通过它来完成Channel 、ChannelPipeline、ChannelHandler这几个组件之间的交互，采用知识最小化原则让每个组件只关心ChannelHandlerContext相关API，。
ok,我们来大致梳理一下关于通道的几个核心类关系。

1. 每个Channel会绑定一个ChannelPipeline，ChannelPipeline中也会持有Channel的引用
2. ChannelPipeline持有ChannelHandlerContext链路，保留ChannelHandlerContext的头尾节点指针
3. 每个ChannelHandlerContext会对应一个ChannelHandler，也就相当于ChannelPipeline持有ChannelHandler链路
4. ChannelHandlerContext同时也会持有ChannelPipeline引用，也就相当于持有Channel引用

NioEventLoopGroup
Netty遵循Reactor基础线程模型的一个具体实现。以下是Reactor几种基础线程模型介绍。
Reactor 单线程模型，所有的I/O操作都在同一个线程上完成。
Reactor多线程模型，有一个用于专门接收客户端TCP连接的NIO线程，网络I/O 读、写操作有专门一个NIO线程池处理。
主从Reactor多线程模型，专门接收客户端TCP连接的不在是一个线程，而是一个独立的线程池（主），网络I/O 读、写操作仍然是专门一个NIO线程池处理（从）