Netty

Bootstrap是Netty框架的启动类和主入口类，分为客户端类Bootstrap和服务器类ServerBootstrap两种。
网络编程里，"服务器"和"客户端"实际上表示了不同的网络行为:换句话说，是监听传入的连接还是建立到
一个或者多个进程的连接。
因此，有两种类型的引导：一种用于客户端(简单地称为Bootstrap)，而另一种(ServerBootstrap)用于服务器。
无论应用程序使用哪种协议或者处理哪种类型地数据，唯一决定它使用哪种引导类的是它是作为一个客户端还是
作为一个服务器

ServerBootstrap和Bootstrap
ServerBootstrap将绑定到一个端口，因为服务器必须要监听连接，而Bootstrap则是由
想要连接到远程节点的客户端应用程序所使用的.
第二个区别可能更加明显。引导一个客户端只需要一个EventLoopGroup，但是一个ServerBootstrap
则需要两个(也可以是同一个实例)，因为服务器需要两组不同的Channel，第一组将只包含一个ServerChannel,
代表服务器自身的已绑定到某个本地端口的正在监听的套接字。而第二组将包含所有已创建的用来传入客户端
连接(对于每个服务器已经接受的连接都有一个)的Channel.与ServerChannel相关联的EventLoopGroup将
分配一个负责为传入连接请求创建Channel的EventLoop。一旦连接被接受，第二个EventLoopGroup就会
给它的Channel分配一个EventLoop

NIO:io.netty.channel.socket.nio 使用java.nio.channels包作为基础--基于选择器的方式

Epoll:io.netty.channel.epoll由JNI驱动的epoll()和非阻塞IO.这个传输支持只有在Linux上可用的多种特性，
如果SO_REUSEPORT，比NIO传输更快，而且是完全非阻塞的。将NioEventLoopGroup替换为
EpollEventLoopGroup,并且将NioServerSocketChannel.class替换为EpoolServerSocketChannel.class即可

OIO:io.netty.channel.socket.oio使用java.net包作为基础--使用阻塞流

Local:io.netty.channel.local可以在VM内部通过管道进行通信的本地传输

Embedded:io.netty.channel.embedded Embedded传输，允许使用ChannelHandler而又
不需要一个真正的基于网络的传输，在测试ChannelHandler实现时非常有用

Channel是JavaNIO的一个基本构造，它代表一个到实体(如一个硬件设备、一个文件、一个网络套接字
或者一个能够执行一个或者多个不同的IO操作的程序组件)的开发连接，如读操作和写操作

目前，可以把Channel看作是传入(入站)或者传出(出站)数据的载体。因此，它可以被打开或者被关闭，
连接或者断开连接

Channel、EventLoopGroup和ChannelFuture

Channel接口。
基本的IO操作(bind()、connect()、read()和write())依赖于底层网络传输所提供的原语。
在基于Java的网络编程中，其基本的构造是类Socket.Netty的Channel接口所提供的API,
被用于所有的IO操作。大大地降低了直接使用Socket类地复杂性。此外，Channel也是
许多预定义、专门化实现地广泛类层次结构的根

由于Channel是独一无二的，所以为了保证顺序将Channel声明为java.lang.Comparable
的一个子接口。因此，如果两个不同的Channel示例都返回了相同的散列码，那么AbstractChannel
中的compareTo()方法的实现将会抛出一个Error

Channel的生命周期状态
ChannelUnregistered:Channel已经被创建，但是还未注册到EventLoop
ChannelRegistered:Channel已经被注册到了EventLoop
ChannelActiveLChannel处于活动状态(已经连接到它的远程节点)。它现在可以接收和发送数据了
ChannelInactive:Channel没有连接到远程节点
当这些状态发生改变时，将会生成对应的事件。这些事件将会被转发给ChannelPipeline中的
ChannelHandler，其可以随后对它们做出响应。在日常编程中，关注ChannelActive和ChannelInactive
会更多一些

重要的Channel的方法。
eventLoop:返回分配给Channel的EventLoop
pipeline:返回Channel的ChannelPipeline,也就是说每个Channel都有自己的ChannelPipeline.
isActive:如果Channel是活动的，则返回true。活动的意义可能依赖于底层的传输。
例如，一个Socket传输一旦连接到了远程节点便是活动的，而一个Datagram传输一旦被打开
便是活动的。
localAddress:返回本地的SocketAdress
remoteAddress:返回远程的SocketAddress
write:将数据写到远程节点，注意，这个写只是写往Netty内部的缓存，还没有真正写往Socket
flush:将之前写的数据冲刷到底层Socket进行传输
writeAndFlush:一个简便的方法，等同于调用write()并接着调用flush()

EventLoop可以看成一个线程,EventLoopGroup自然就可以看成线程组
在NIO中一个while循环select出事件，然后依次处理每种事件，我们可以把它称为事件循环，
这就是EventLoop，它定义了Netty的核心抽象，用于处理网络连接的声明周期中所发生的事件。
io.netty.util.concurrent包构建在JDK的java.util.concurrent包上。而io.netty.channel包中的类，
为了与Channel的事件进行交互，扩展了这些接口/类，一个EventLoop将由一个永远都不会改变的Thread驱动，
同时任务(Runnable/Callable)可以直接交给EventLoop实现，以立即执行或者调度执行

线程的分配.
服务于Channel的I/O和事件的EventLoop包含在EventLoopGroup中，异步传输实现只使用了少量的EventLoop
(以及和它们相关联的Thread)，而且在当前的线程模型中，它们可能会被多个Channel所共享，这使得可以通过
尽可能少的Thread来支撑大量的Channel，而不是每个Channel分配一个Thread.EventLoopGroup负责为每个
新创建的Channel分配一个EventLoop.在当前实现中，使用顺序循环(round-robin)的方式进行分配以获取一个
均衡的分布，并且相同的EventLoop可能会被分配给多个Channel.一旦一个Channel被分配给一个EventLoop，
它将在它的整个声明周期中都使用这个EventLoop(以及相关联的Thread)

需要注意:EventLoop的分配方式对ThreadLocal的使用的影响。因为一个EventLoop通常会被用于支撑多个Channel,
所以读与所有相关联的Channel来说，ThreadLocal都将是一样的。这使得它对于实现状态追踪等功能来说是个糟糕
的选择。然而，在一些无状态的上下文中，它仍然可以被用于在多个Channel之间共享一些重度的或者代价昂贵的对象，
甚至是事件

线程管理。
在内部，当提交任务到如果(当前)调用线程正是支撑EventLoop的线程，那么所提交的代码块将会被(直接)执行，
否则，EventLoop将调度该任务以便稍后执行，并将它放入到内部队列中。当EventLoop下次处理它的事件时，
它会执行队列中的那些任务/事件

为什么要设计成一个Channel中的事件处理只能交给一个EventLoop?
在以前的版本中所使用的线程模型只保证了入站(之前称为上游)事件会在所谓的IO线程(对应Netty4中的EventLoop)中执行。
所有的出站(下游)事件都由调用线程处理，其可能是I/O线程也可能是别的线程。开始看起来这似乎是个好主意，但是已经被
发现是有问题的，因为需要在ChannelHandler中对出站事件进行仔细的同步。简而言之，不可能保证多个线程在同一时刻
尝试访问出站事件。例如你通过在不同的线程中调用Channel.write()方法，针对同一个Channel同时触发出站的事件，就会
发生这种情况。当出站事件触发了入站事件时，将会导致另一个负面影响。当Channel.write()方法导致异常时，需要在调用
线程中执行代码，然后将事件移交给I/O线程去执行(在出站事件中，因为出站的数据是要发往对端的，所以当异常触发时要把
它当作入站，交由发送端来处理)然而这将带来额外的上下文切换。
Netty4中所采用的线程模型，通过在同一个线程中处理某个给定的EventLoop中所产生的所有事件，解决了这个问题，
这提供了一个更加简单的执行体系架构，并且消除了在多个ChannelHandler中进行同步的需要，也解决了线程安全和同步的问题

Netty使用不同的事件来通知我们状态的改变或者是操作的状态。这使得我们能够
基于已经发生的事件来触发适当的动作

Netty事件是按照它们与入站或出站数据流的相关性进行分类的。可能由入站数据
或者相关的状态更改而触发的事件包括:
连接已被激活或者连接失活；数据读取;用户事件；错误事件；

出站事件是未来将会触发的某个动作的操作结果，这些动作包括:打开或者关闭到
远程节点的连接；将数据写到或者冲刷到套接字

每个事件都可以被分发给ChannelHandler类中的某个用户实现的方法，
既然事件分为入站和出站，用来处理事件的ChannelHandler也被分为
可以处理入站事件的Handler和出站事件的Handler,当然有些Handler，
既可以处理入站也可以处理出站

提供提供了大量预定义的可以开箱即用的ChannelHandler实现，包括
用于各种协议(如HTTP和SSL/TLS)的ChannelHandler

ChannelHandler的生命周期。
在ChannelHandler被添加到ChannelPipeline中移除时会调用下面这些方法。
这些方法中的每一个都接受一个ChannelHandlerContext参数。
handlerAdded:当把ChannelHandler添加到ChannelPipeline中被调用
handlerRemoved:当从ChannelPipeline中移除ChannelHandler时被调用
exceptionCaught:当处理过程中在ChannelPipeline中有错误产生时被调用

ChannelPipeline中的ChannelHandler.
入站和出站ChannelHandler被安装到同一个ChannelPipeline中，ChannelPipeline以双向链表的形式进行维护管理。
如上图，在网络上传递的数据，要求加密，但是加密后密文比较大，需要压缩后再传输，而且按照业务要求，需要检查
报文中携带的用户信息是否合法，于是图中实现了，解压(入)Handler、压缩(出)Handler、解密(入)Handler、加密(出)Handler\
授权(入)Handler.
如果一个消息或者任何其他入站事件被读取，那么它会从ChannelPipeline的头部开始流动，但是只被处理入站事件的Handler处理，
也就是解压(入)Handler、解密(入)Handler、授权(入)Handler，最终，数据将会到达ChannelPipeline的尾端，届时，所有的处理就
都结束了
数据的出站运动(即正在被写的数据)在概念上也是一样的。在这种情况下，数据将从链的尾端开始流动，但是制备处理出站的Handler
处理，也就是加密(出)Handler、压缩(出)Handler，直到它到达链的头部为止。在这之后，出站数据将会到达网络传输层，也就是Socket
Netty能区分入站事件的Handler和出站的Handler，并确保数据只会在具有相同定向的两个ChannelHandler之间传递
在编写Netty应用程序时要注意，分属出站和入站不同的Handler，在业务没有特殊要求的情况下是无所谓顺序的，
比如压缩(出)Handler可以放在解压(入)Handler和解密(入)Handler中间，也可以放在解密(入)Handler和授权之间

而同属一个方向的Handler则是有顺序的，因为上一个Handler处理的结果往往是下一个Handler的要求的输入。比如入站处理，对于
收到的数据，只有先解压才能得到密文，才能解密，只有解密后才能拿到明文中的用户信息进行授权检查，所以解压-解密-授权这个
三个入站Handler的顺序就不能乱

从应用程序开发人员的角度来看，Netty的主要组件是ChannelHandler，它充当了所有处理入站和
出站数据的应用程序逻辑的容器。ChannelHandler的方法是由网络事件触发的。事实上，ChannelHandler
可专门用于几乎任何类型的动作，例如将数据从一种格式转换为另一种格式，例如各种编解码，或者处理
转换过程中所抛出的异常.

ChannelInboundHandler
该接口将会是经常实现的子接口。这种类型的ChannelHandler接收入站事件和数据，
这些数据随后将会被应用程序的业务逻辑所处理。当你要给连接的客户端发送响应时，
也可以从ChannelInboundHandler直接虫偶刚刷数据然后输出到对端。应用程序的业务
逻辑通常实现在一个或者多个ChannelInboundHandler中。这种类型的ChannelHandler
接收入站事件和数据，这些数据随后将会被应用程序的业务逻辑所处理

ChannelOutboundHandler
出站操作和数据将由ChannelOutboundHandler处理。它的方法将被Channel、ChannelPipeline以及
ChannelHandlerContext调用，所有由ChanneloutboundHandler本身所定义的方法如下
biind():当请求将Channel绑定到本地地址时调用
connect():当请求将Channel连接到远程节点时被调用
disconnect():当请求将Channel从远程节点断开时被调用
close():当请求关闭Channel时被调用
deregister():当请求将Channel从它的EventLoop注销时被调用
read()当请求从Channel读取更多的数据时被调用
flush():当请求通过Channel将入队数据冲刷到远程节点时被调用
write()当请求通过Channel将数据写到远程节点时被调用

ChannelHandler的适配器。
有一些适配器类可以将编写自定义的ChannelHandler所需要的工作降到最低限度，
因为它们提供了定义在对应接口中的所有方法的默认实现。因为有时会忽略那些不感兴趣的
事件，所以Netty提供了抽象积累ChannelInboundHandlerAdapter(处理入站)和
ChannelOutboundHandlerAdapter(处理出站)的基本实现，通过扩展抽象类ChannelHandlerAdapter，
它们获得了它们共同的超接口ChannelHandler的方法.不过ChannelOutboundHandler有个非常让人
迷惑的read()方法，ChannelOutboundHandler不是处理出站事件的吗?怎么会有read()方法呢?
其实这个read方法不是表示读数据，而是表示业务发出了读(read)数据的要求，这个要求也会封装为
一个事件进行传播，这个事件因为时业务发出到网络的，自然就是个出站事件，而且这个事件触发的就是
ChannelOutboundHandler中read()方法。
如果Handler纪要处理入站又要处理出站怎么办呢?这个时候就可以使用类ChannelDuplexHandler，
当然也可以同时实现ChannelOutboundHandler，ChannelInboundHandler这两个接口

Handler的共享和并发安全性。
ChannelHandlerAdapter还提供了实用方法isSharable().如果其对应的实现被标注为Sharable,那么这个方法
将返回true,表示它可以被添加到多个ChannelPipeline.这就牵涉到了我们实现的Handler的共享性和线程安全性。
在往pipeline安装Handler的时候，基本上都是new出Handler的实例，因为每个socketChannel有自己的pipeline,
而且每个socketChannel又是和线程绑定的，所以这些Handler的实例之间完全独立的，只要Handler的实例不是
共享了全局变量，Handler的实例是线程安全的
但是如果业务需要在多个SocketChannel之间共享一个Handler的实例怎么办呢?比如统计服务器接收到和发出的
业务报文总数，我们就需要用一个Handler的实例来横跨所有的socketChannel来统计socketChannel业务报文数。
为了实现这一点，我们可以实现一个MessageCountHandler,并且在MessageCountHandler上使用Netty的@Sharable,
然后在安装MessageCountHandler到MessageCountHandler的统计功能时，请务必注意线程安全，具体实现时就使用
Java并发编程里的Atomic类来保证这一点

资源管理和SimpleChannelInboundHandler.
回想一下我们在NIO中时如何接收和发送网络数据的?都是首先创建了一个Buffer,应用程序中的业务部分和Channel之间
通过Buffer进行数据的交换:ByteBuffer.allocate(1024),如图所示
Netty在处理网路数据时，同样也需要Buffer,在Read网络数据时由Netty创建Buffer,Write网络数据时Buffer往往由业务方
创建的。不管是读和写，Buffer用完后都必须进行释放，否则可能会造成内存泄漏，在Write网络数据时，可以确保数据被
写往网络了，Netty会自动进行Buffer的释放，但是如果Write网络数据时，我们有outBoundHandler处理了write()操作并
丢弃了数据，没有继续往下写，要由我们负责释放这个Buffer，就必须调用ReferenceCountUtil.release()方法，否则就可能
造成内存泄漏。在Read网络数据时，如果我们可以确保每个Inboundhandler都把数据往后传递了，也就是调用了相关的
fireChannelRead()方法，Netty也会帮我们释放，同样的，如果我们有InboundHandler处理了数据，又不继续往后传递，
又不调用负责释放的ReferenceCountUtil.release()方法，就可能会造成内存泄漏。
但是由于消费入站数据是一项常规任务，所以Netty提供了一个特殊的被称为SimpleChannelInboundHandler的
ChannelInboundHandler实现，这个实现会在数据被channelRead0()方法消费之后自动释放数据，同时系统为我们提供的
各种预定义的Handler实现，都实现了数据的正确处理，所以我们自行在编写业务Handler时，也需要注意:要么继续传递，
要那么自行释放

负责初始化Channel.Netty提供了一个特殊的ChannelInboundHandlerAdapater子类:它定义了
下面的方法:
protected abstract void initChannel(C ch) throws Exception;
这个方法提供了一种将多个ChannelHandler添加到一个ChannelPipeline中的简便方法，你只需要
简单地向Bootstrap或者ServerBootstrap的实例提供你的ChannelInitializer实现即可，并且一旦
Channel被注册到了它的EventLoop之后，就会调用你的initChannel()版本。在该方法返回之后，
ChannelInitializer的实例将会从ChannelPipeline中移除它自己，所以，在我们自己的应用程序中，
如果存在着某个Handler只使用一次的情况，也可以伪造Channelinitializer,用完以后将自己从ChannelPipeline
中移除自己，比如授权Handler,某客户端第一次连接登录以后，进行授权检查，检查通过后，就可以把这个

ChannelHandlerContext代表了ChannelHandler和ChannelPipeline之间的关联，每当有ChannelHandler
添加到ChannelPipeline中时都会创建ChannelHandlerContext，为什么需要这个ChannelHandlerContext?
ChannelPipeline以双向链表的形式进行维护管理Handler，毫无疑问，Handler在放入ChannelPipeine的时候必须要有两个
指针pre和next来说明它的前一个元素和后一个元素，但是Handler本身维护这两个指针合适吗?
想想我们在使用JDK的LinkedList的时候，我们放入LinkedList的数据是不会带这两个指针的，LinkedList内部会用  
类Node对我们的数据进行包装，而类Node则带有两个指针pre和next,所以ChannelHandlerConntext的主要作用就和
LinkedList内部的Node类似，不过ChannelHandlerContext不仅仅只是个包装类，它还提供了很多的方法，比如让
事件从当前ChannelHandler传递给链中的下一个ChannelHandler，还可以被用于获取底层的Channel，还可以用于写出站数据

Channel、ChannelPipeline和ChannelhandlerContext上的事件传播。
ChannelHandlerContext有很多的方法，其中一些方法也存在于Channel和ChannelPipeline本身上，
但是有一点重要的不同，如果调用Channel或者ChannelPipeline上的这些方法，它们将沿着整个
ChannelPipeline进行传播。而调用位于ChannelHandlerContext上的相同的方法，则将从当前所关联的
ChannelHandler开始，并且只会传播给位于该ChannelPipeline中的下一个(入站下一个，出站上一个)能
够处理该事件的ChannelHandler

eg:比如服务器收到对端发过来的报文，解压后需要进行机密，结果解密失败，要给对端一个应答。
如果发现解密失败 原因时服务器和对端的加密算法不一致，应答报文只能以明文的压缩格式发送，
就可以在解密Handler中直接使用ctx.write给对端应答，这样应答报文就只会经过压缩Handler就
发往了对端

ChannelHandlerContext的API
alloc返回和这个示例相关联的Channel所配置的ByteBufAllocator
bind绑定到给定的SocketAddress，并返回ChannelFuture
channel返回绑定到这个实例的Channel
close关闭Channel，并返回ChannelFuture
connect连接给定的SocketAddress，并返回ChannelFuture
deregister从之前分配的EventExecutor注销，并返回ChannelFuture
disconnect从远程节点断开，并返回ChannelFuture
executor返回调度时间的EventExecturo
fireChannelActive触发对下一个ChannelInboundHandler上的channelActive()方法(已连接)的调用
fireChannelInactive触发对下一个ChannelInboundHandler上的ChannelInactive()(已关闭)方法
fireChannelRead触发对下一个ChannelInboundHandler上的channelRead()方法(已接收的消息)调用
fireChannelReadComplete触发对下一个ChannelInboundHandler上的channelReadComplete()方法的调用
fireChannelRegistered触发对下一个ChannelinboundHandler上的fireChannelRegistered()方法的调用
fireChannelUnRegistered()触发对下一个ChannelInboundHandler上的fireChannelUnRegistered()方法的调用
fireChannelWritablityChanged触发对下一个ChannelInboundHandler上的fireChannelWritabilityChanged()方法的调用
fireChannelExceptionCaught()触发对下一个ChannelInboundHandler上的fireExceptionCaught()方法的调用
fireUserEventTriggered触发对下一个ChannelInboundHandler上的fireUserEventTriggered(Object evet)方法的调用
handler返回绑定到这个实例的ChannelHandler
isRemoved如果所关联的ChannelHandler已经被从ChannelPipeline中移除则返回true
name返回这个实例的唯一名称
pipeline返回这个实例所关联的ChannelPipeline
read将数据从Channel读取到第一个入站缓冲区，如果读取成功则触发一个channelRead事件，并(在最后一个消息被读取完成后)通知
ChannelInboundHandler的channelReadComplte(ctx)方法
write通过这个实例写入消息并经过ChannelPipeline
writeAndFlush通过这个实例写入并冲刷消息并经过ChannelPipeline
当使用ChannelHandlerContext的API的时候，有以下两点
1.ChannelHandlerContext和ChannelHandler之间的关联(绑定)是永远不会改变的，所以缓存对它的引用是安全的
2.相对于其他类的同名方法，ChannelHandlerContext的方法将产生更短的事件流，应该尽可能地利用这个特性来获得最大地性能

基于Netty的网路应用程序中根据业务需求会使用Netty已经提供的Channelhandler
或者自行开发ChannelHandler，这些ChannelHandler都放在ChannelPipeline中统一
管理，事件就会在ChannelPipeline中流动，并被其中一个或者多个ChannelHandler处理

当Channel被创建时，它将会被自动地分配一个新的ChannelPipeline,每个Channel都有自己
的ChnanelPipeline.这项关联是永久性的。在Netty组件的生命周期中，这是一项固定的操作，
不需要开发人员的任何干预

ChannelPipeline提供了ChannelHandler链的容器，并定义了在该链上传播入站(也就是从网络到业务处理)
和出站(也就是从业务处理到网络)，各种事件流的API，代码中的ChannelHandler都是放在ChannelPipeline中的。

使得事件流经ChannelPipeline是ChannelHandler的工作，它们是在应用程序的初始化或者引导阶段被安装的。
这些ChannelHandler对象接收事件、执行它们所实现的处理逻辑，并将数据传递给链中的下一个ChannelHandler,
而且Channelhandler对象也完全可以拦截事件不让事件继续传递。它们的执行顺序是由它们被添加的顺序所决定的。

ChannelPipeline上的方法。
既然ChannelPipeline以双向链表的形式进行维护管理Handler，自然也提供了对应的方法在ChannelPipeline中
增加或者删除、替换handler.addFist、addBefore、addAfter、addLast将一个ChannelHandler添加到ChannelPipeline中。
remove将一个ChannelHandler从ChannelPipeline中移除
replace将ChannelPipeline中的一个ChannelHandler替换为另一个ChannelHandler
get通过类型或者名称返回ChannelHandler
context返回和ChannelHandler绑定的ChannelHandlerContext
names返回ChannelPipeline中所有ChannelHandler的名称
ChannelPipeline的API公开了用于调用入站和出站操作的附加方法

Netty中所有的IO操作都是异步的，我们知道"异步的意思就是不需要主动等待结果的返回，
而是通过其他手段比如，状态通知，回调函数等"，也就是说至少我们需要一种获得异步执行
结果的手段

JDK预置了java.util.concurrent.Future,Future提供了一种在操作完成时通知应用程序的方式，
这个对象可以看作是一个异步操作的结果的占位符；它将在未来的某个时刻完成，并提供对其
结果的访问。但是其所提供的实现，只允许手动检查对应的操作是否已经完成，或者一直阻塞
直到它完成。这是非常繁琐的，所以Netty提供了它自己的实现ChannelFture,用于在执行异步
操作的时候使用，一般来说，每个Netty的出站I/O操作都将返回一个ChannelFuture。
我们还可以添加ChannelFutureListener,针对某个异步操作添加通知回调

JDK原生Future提供的方法

ChannelOption.SOBACKLOG

ChannelOption.SO_REUSEADDR

ChannelOption.SO_KEEPALIVE

ChannelOption.SO_SNDBUF/ChannelOption.SO_RCVBUF

ChannelOption.SO_LINGER

ChannelOption.TCP_NODELAY

PooledByteBuf是池化的ByteBuf，提高了内存分配与释放的速度，它本身是一个抽象泛型类，
有三个子类:PooledDirectByteBuf、PooledHeapByteBuf、PooledUnsafeDirectByteBuf.

Arena是什么
在Netty中,Arena是一种内存分配器(Memory Allocator)的概念。Arena的主要目的是提高内存分配
和释放的效率，减少碎片化，从而提高系统性能。

具体而言，Netyy中的Arena主要用于分配和管理ByteBuf对象的内存，ByteBuf是Netty中用于处理
字节数据的缓冲区类.Arena在这里的作用是为ByteBuf提供内存块，以避免频繁地进行直接内存分配和释放。

Arena的实现通常采用了一些内存池技术，例如Chunked Memory Pool。它将内存分割成固定大小的块(Chunk)
当需要分配内存时，会从这些块中选择合适大小的块进行分配，而不是每次都直接向操作系统申请新的内存.
这样做可以减少内存碎片化，提高内存的利用率，也能够更有效地进行内存回收

Netty的Arena实现是为了优化网络应用程序中频繁的数据传输操作，特别时在高并发的情况下。
通过使用Arena,Netty可以更高效地管理和利用内存，从而提高系统的性能

Jemalloc算法。
Netty的PooledByteBuf采用与jemalloc一致的内存分配算法。基本思路可用这样的情景类比，想象一下电商的
配送流程。当顾客采购小件商品(比如书籍)时，直接从同城仓库送出；当顾客采购大件商品(比如电视)时，从区域
仓库送出；当顾客采购超大件商品(比如汽车)时，则从全国仓库送出。Netty的分配算法与此相似。
Netty中，Tiny和Small类型的请求都首先从同城仓库(ThreadCache-tcache)送出;如果同城仓库没有，则会从区域
仓库(PoolArena)送出，Normal类型的请求则从区域仓库(PoolArena)送出，Huge类型的请求则从全国仓库(系统内存)送出。
Netty中规定:
1.内存分配的最小单位为16B
2.小于512B的请求为Tiny，512B<x<8KB(PageSize)的请求为Small,8KB<=X<=16MB(ChunkSize)的请求为Normal,
大于16MB(ChunkSize)的请求为Huge
3.Tiny、Small、Normal、Huge中还有细层级，小于Tiny的请求以16B为起点每次增加16B作为一个层级，也就是
Tiny中还有16B、32B、48B、.......480B、496B的层级
其他类型的则是翻倍:
Small中还有512B、1KB、2KB、4KB的层级
Normal中还有8KB、16KB、32KB......8MB、16MB的层级
Huge中还有32MB、64MB....的层级
4.不管请求的大小，都会将向上规范化，比如:请求分配511B、512B、513B，将依次规范化为512B、512B、1KB
为了提高内存分配效率并减少内部碎片，jemalloc算法将Arena切分为小块Chunk,根据每块的内存使用率又将小块组合为以下
集中状态QINIT,Q0,Q25,Q50,Q75,Q100。Chunk块可以在这几种状态间随着内存使用率的变化进行转移，内存使用率
和状态转移如图所示。
其中横轴表示内存使用率(百分比),纵轴表示状态，可以看到:
QINIT的内存使用率为[0,25),Q0为(0,50),Q100为[100,100]等等。
Chunk的初始状态为QINIT,当使用率达到25时转移到Q0状态，再次达到50时转移到Q25,依次类推直到Q100；当内存释放时
又从Q100转移到Q75,直到Q0状态且内存使用率为0时，该Chunk从Arena中删除。
像qinit、q000、q075因为本身要维护很多Chunk块，所以内部是以链表的形式来组织Chunk块，同时qinit、q000、q075
本身又组织为一个近似的双向链表，如图所示。

虽然已将Arena切分成小块的Chunk,但实际上Chunk是相当大的内存块，在Netty中默认使用16MB。为了进一步提高内存利用率，
并减少内部碎片，需要继续将Chunk切分为小的快Page.一个典型的切换将Chunk切分为2048块，可知Page的大小为:
16MB/2048=8KB.一个好的内存分配算法，应使得已分配内存块尽可能保持连续，这将大大减少内部碎片，由此jemalloc使用伙伴
分配算法尽可能提高连续性。伙伴分配算法的基本思想是:
我们直到一个Chunk切分为2048块Page,将这些Page作为叶子节点，然后组织起一个满二叉树
然后按层分配满足要求的内存块。
以待分配序列8KB、16KB、8KB为例分析分配过程(每个Page大小8KB)：
8KB--需要一个Page,第11层满足要求，故分配2048节点即Page0
16KB-需要两个Page，故需要在第10层进行分配，而1024节点的子节点2048已分配，从左到右找到满足要求的1025节点，故分配
节点1025即Page2和Page3
8KB--需要一个Page，第11层满足要求，2048已分配，从左到右找到2049节点即Page1进行分配。
分配结束后，已分配连续的Page0-Page3,这样的连续内存块，大大减少内部碎片并提高内存使用率
为了实现伙伴算法，Netty中使用了memoryMap和depthMap来表示两棵二叉树，其中MemoryMap存放分配信息，depthMap存放
节点的高度信息

在看完两张图之后，我们在前面说过，一个page是8KB，但是Netty又支持Tiny、Small这种小于8KB,最小可达16B的内存分配请求，
每次都分配一个page,很浪费。为了进一步切分Page成更小的SubPage，SubPage是jemalloc中内存分配的最小单位，不能
再进行切分.SubPage切分的单位并不固定，以第一次请求分配的大小为单位(最小切分单位为16B).
比如，第一次请求分配32B,则Page按照32B均等切分为256块；第一次请求请求16B，则Page按照16B均等切分512块。
为了便于内存分配和管理，根据SubPage的切分单位进行分组，对每个组而言，Arena会以双向链表的形式进行管理。
那么根据切分的单位的大小和Page的大小，SubPage分为两类:tinySubPagePools和smallSubPagePools，tinySubPage
中的subPage的大小，从16字节到496个字节，共有32个元素，smallSubPagePools则有512字节、1024、2048、4096共4个元素
如图所示。

在Arena数量上，为了减少各个线程进行内存分配时竞争，Netty中会有多个Arena，默认的数量与处理器的个数有关，
线程首次分配内存时，首先会为其分配一个固定的Arena

PoolThreadCache.
同时在Netty中为了提升性能，并不会一开始就从PoolArena中分配，因为Arena为几个线程共享，而是先从每个线程自己的
PoolThreadCache中去获取。当然开始的是偶，这些Cache里面都是没有值的，要先从PoolArena中获取，当释放Buf的时候,
才会把之前分配的内存大小放到该cache里面，当下次申请内存的时候，就会先从PoolThreadCache中找。
PoolThreadCache中则维护了6个这样的线程缓存区域，3个堆内存相关，3个直接内存相关，分别对应着三种
分配内存的大小
small类型的数组的大小为4，而tiny、normal数组的大小分别为32、3
smallSubPageHeapCache的数组长度为4，依次缓存[512K,1024K,2048K,4096K]大小的缓存，每个元素对应的缓存
queue中的元素个数不能超过256个，而tinySubPageHeapCaches数组缓存的是[16B,32B,...,496B]大小的内存块，每个元素
对应的缓存queue中元素个数不能超过512个，normalHeapCaches数组结构相同，但是只缓存[8K，16K,32K]大小的内存块,
每个元素对应的缓存queue中元素个数不超过64个。
每一个MemoryRegionCache中又包含一个队列。队列中的每个元素类型为Entry,Entry中又包含了一个PoolChunk，以方便
对内存的管理

为什么会有Netty?

为什么不用Netty5? Netty5已经停止开发了

为什么Netty使用NIIO而不是AIO？

为什么不用Mina?
简单来说，Mina机会不再更新了，Netty本来就是因为Mina不够好所以开发出来的

1.API使用简单，开发门槛低

2.功能强大，预置了多种编解码功能，支持多种主流协议

3.定制能力强，可以通过ChannelHandler对通信框架进行灵活地扩展

4.性能高，通过与其他业界主流地NIO框架对比，Netty的综合性能最优

5.成熟、稳定，Netty修复了已经发现的所有JDK NIO BUG，业务人员不需要再为NIO的bug而烦恼

6.社区活跃，版本迭代周期短，发现的bug可以被及时修复，同事，更多的新功能会加入

7.经历了大规模的商业应用考研，直到得到验证

功能描述

通信模型

消息定义

链路的建立

可靠性设计

实现设计

Netty是如何解决JDK中的Selector BUG的？

如何让单机下Netty支持百万长连接?
如果要支持百万长连接，需要有很多的工作要做

什么是水平触发(LT)和边缘触发(ET)?