Netty核心组件
1.Channel
Channel可以理解为是socket连接，在客户端与服务端连接的时候就会建立一个Channel，它负责基本的IO操作（binf()、connect()、rad()、write()等）；
1.1 Channel的作用
- 通过Channel可获得当前网络连接的通道状态；
- 通过Channel可获得网络连接的配置参数（缓冲区大小等）；
- Channel提供异步的网络IO操作，如连接的建立、数据的读写、端口的绑定等；
1.2 Channel的类型
- NioSocketChannel：NIO的客户端TCP socket连接；
- NioServerSocketChannel：NIO的服务器端TCP socket连接；
- NioDatagramChannel：UDP连接；
- NioSctpChannel：客户端Sctp（一种传输层协议）连接；
- NioSctpServerChannel：Sctp服务器端连接；
2.Event Loop、Event Loop Group
有了Channel连接服务，消息就可以流动，针对消息在服务器上的出站入站产生事件，而EventLoop就是一个监控和协调事件的机制；
Netty中每个Channel都会分配一个EventLoop，一个EventLoop可以服务于多个Channel，每个EventLoop会占用一个线程，同时这个线程会处理Event Loop上面发生的所有IO操作和事件；
而EventLoopGroup是用来生成EventLoop的，默认线程数为CPU核数*2；
3.ChannelHandler
数据的入站和出站的业务逻辑都是在ChannelHandler中，针对出入站分为ChannelInboundHandler（入站事件处理器）和ChannelOutBoundHandler（出站事件处理器），两个接口都继承ChannelHandler接口；
ChannelHandlerAdapter抽象类实现了ChannelHandler接口，提供了一些方法的默认实现，根据在服务端编写还是在客户端编写提供了ChannelInboundHandlerAdapter与SimpleChannelInboundHandler两个子类，前者不会释放消息数据的引用，后者会；
4.ChannelPipeline
在Channel的数据传递过程中，不同的业务逻辑实现都需要有ChannelHandler完成，一个Channel对应着多个ChannelHandler，ChannelPipeline就是用来管理多个ChannelHandler的；
一个Channel包含了一个ChannelPipeline，ChannelPipeline中维护了一个ChannelHandler的列表，ChannelHandler与Channel和ChannelPipeline之间的映射关系又由ChannelHandlerContext来维护；
- Channel Handler按照加入的顺序会组成一个双向链表，入站事件从链表的头往后传递到最后一个ChannelHandler，出站事件从链表的尾向前传递，直到最后一个ChannelHandler，两种类型的ChannelHandler相互不影响；
5.Bootstrap
Bootstrap（引导类）负责配置整个Netty程序，将各个组件都串起来，绑定端口启动Netty服务，针对客户端（Bootstrap）与服务端（ServerBootstrap）分为两种引导类；
- ServerBootstrap将绑定到一个端口，而Bootstrap不需要绑定本地端口只需连接到远程端口；
- Bootstrap只需要一个EventLoopGroup，而Server Bootstrap则需要两个，因为服务端需要两组不同的Channel，一组用来接收新的客户端连接请求，一组用来处理已连接的客户端Channel的读写事件；
6.Future
Future提供了一种在异步操作完成时通知应用程序的方式，Future对象可以看作一个异步操作结果的占位符，他将在未来的某个时刻完成，并提供对其结果的访问；
JDK内置的 java.util.concurrent.Future只允许手动检查对应的操作是否已完成，或阻塞到他完成，较为繁琐，Netty提供了他自己的Future实现--ChannelFuture；
- ChannelFuture提供了几种额外的方法，使得我们能够注册一个或多个ChannelFutureListener实例；
- 监听器的回调方法operationComplete()，将会在对应的操作完成时被调用，监听器就能知道操作是成功了还是出错了；
- 每个Netty的出站IO操作都将返回一个ChannelFuture，也就是说他们都不会阻塞；
7.ByteBuf缓冲区
ByteBuf是Netty用于处理字节数据的核心类，是一个灵活高效的字节容器，提供了丰富的API来操作字节数据，是Netty对JDK自带的ByteBuffer的替代品；
ByteBuf内部结构如下：
- discardable bytes：可丢弃的字节空间；
- readable bytes：可读的字节空间；
- writable bytes：可写的字节空间；
- capacity bytes：最大的可容量空间；
7.1 ByteBuf的工作原理
ByteBuf由一串字节数组构成，数组中每个字节用来存放信息，ByteBuf有两个索引，分别用来读写数据，通过两个索引在数组中移动，来定位需要读或写的位置；
当从ByteBuf中读取时，readerIndex（读索引）将会根据读取的字节数递增，当写ByteBuf时，writerIndex（写索引）也会根据写入的字节数进行递增；当readerIndex超过writerIndex的时候，Netty会抛出IndexOutOf-BoundsException；
7.2 索引指针
ByteBuf有三个指针：
- readerIndex（读指针）：标记读取的起始位置，每读取一个字节加一，当readerIndex与writerIndex相等时不可读；
- writerIndex（写指针）：标记写入的起始位置，每写入一个字节加一，当writerIndex与maxCapacity容量相等时不可写；
- maxCapacity（最大容量）：指示ByteBuf可以扩容的最大容量，如果向ByteBuf写入数据时容量不足，可以扩容；
7.3 缓冲区的使用模式
根据存放缓冲区的不同分为三类：
- 堆缓冲区（HeapByteBuf）：内存的分配和回收速度比较快，可以被JVM自动回收，但如果进行socket的IO读写，需要额外做一次内存复制，将堆内存对应的缓冲区复制到内核Channel中，这回对性能有所影响；
- 直接缓冲区（DirectByteBuf）：非堆内存，相较比堆内存分配和回收速度慢一些，但是将他写入或从socket Channel中读取时少一次内存拷贝，这时比堆内存快；
- 复合缓冲区：Netty提供的CompsiteByteBuf就是将堆缓冲区与直接缓冲区的数据放在一起；
Nettty默认使用直接缓冲区模式；
7.4 ByteBuf的分配
Netty提供了接口ByteBufAllocator来分配ByteBuf实例，其有两个实现类
- PooledByteBufAllocator：实现了ByteBuf对象的池化，可复用ByteBuf实例，提高性能并最大限度的减少内存碎片；
- UnpooledByteBufAllocator：没有实现对象的池化，每次会生成新的ByteBuf对象实例；
7.5 ByteBuf的释放
ByteBuf如果采用堆缓冲区模式，可以由GC回收，如果采用直接缓冲区模式就得手动释放；
7.5.1 手动释放
使用完后，调用 ReferenceCountUtil.release(byteBuf) 来释放；
7.5.2 自动释放
- TailHandler：Netty的ChannelPiplelline的流水线的末端是TailHandler，默认情况下如果每个入站处理器都把消息往下传，TailHandler会释放掉ReferenceCounted类型的消息；
- SImpleChannelInboundHandler：当ChannelHandler继承了SimpleChannelInboundHandler后，在其中的channelRead()方法中，将会进行资源的释放，业务代码需要写入到channelRead0()中；
- HeadHandler：在每一个出站Handler中的处理完成后，最后消息会来到HeadHandler，经过一轮复杂调用在flush完成后释放掉；
7.5.3 释放总结
- 入站处理流程中，如果对原消息不做处理，调用 ctx.fireChannelRead(msg) 把原消息往下传，由流水线最后的 TailHandler 完成自动释放。
- 如果截断了入站处理流水线，则可以继承 SimpleChannelInboundHandler ，完成入站ByteBuf自动释放。
- 出站处理过程中，申请分配到的 ByteBuf，通过 HeadHandler 完成自动释放。
- 入站处理中，如果将原消息转化为新的消息并调用 ctx.fireChannelRead(newMsg)往下传，那必须把原消息release掉;
- 入站处理中，如果已经不再调用 ctx.fireChannelRead(msg) 传递任何消息，也没有继承SimpleChannelInboundHandler 完成自动释放，那更要把原消息release掉;