ByteBufJDK原生的ByteBuffer字节缓冲区的核心功能，一个主要对字节进行操作的类，可以在堆内外构建缓冲区。普通的newbyte[]只是在堆中建的。Netty之所以封了一套ByteBuf，主要是因为原生ByteBuffer的容量是固定的，一旦分配，就不能动态扩缩容了。原生的ByteBufferAPI不够优雅。一不小心，使用起来就会出错。它有三个核心指针，分别是position、limit和capacity。position:位置，表示操作数据在缓冲区中的位置。limit：limit，表示buffer中可操作数据的大小，（limit后数据不能读写）capacity：容量。读写需要调用flip()、rewind()、clear()等方法移动相关指针。ByteBufs呢？它使用两个核心位置指针来辅助读写操作，分别是readerIndex和writerIndex。读取数据时readerIndex会增加，写入数据时writerIndex会增加。无需添加额外的操作来移动相关指针。readerIndex也不能超过writerIndex。0到readerIndex已经读过的空间被认为是废弃的，可以自动扩容。ChannelChannel是网络操作的抽象类。它聚合了一组功能，提供了比原生JavaSocketChannel和ServerSocketChannel更大更全面的功能接口供业务开发者使用，包括但不限于网络读取、写入、发起连接、关闭连接、获取通信双方的地址.UnSafeChannel的辅助操作类，操作底层网络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，我们大致梳理一下关于channel的几个核心类关系。每个Channel都会绑定到一个ChannelPipeline，ChannelPipeline也会持有一个Channel的引用。ChannelPipeline持有ChannelHandlerContext链接，并保留了ChannelHandlerContext的头节点指针和尾节点指针。每个ChannelHandlerContext都会对应一个ChannelHandler，相当于持有ChannelHandler链接的ChannelPipeline。ChannelHandlerContext也会持有ChannelPipeline引用，相当于持有Channel引用。NioEventLoopGroupNetty遵循Reactor基本线程模型的具体实现。下面介绍Reactor的几种基本线程模型。Reactor单线程模型，所有I/O操作都在同一个线程上完成。Reactor多线程模型有一个用于接收客户端TCP连接的NIO线程，以及一个用于网络I/O读写操作的专用NIO线程池。Master-slaveReactor多线程模型，它不是一个专用于接收客户端TCP连接的线程，而是一个独立的线程池（master），网络I/O读写操作仍然专用于一个NIO线程池处理（slave）
