Netty 笔记

1、Netty 是一款异步的事件驱动的网络应用程序框架，支持快速地开发可维护的高性能的面向协议的服务器和客户端。

2、早期Java API 使用的阻塞函数

// 创建一个新的ServerSocket，用以监听指定端口上的连接请求

ServerSocket serverSocket = new ServerSocket(portNumber);

// 对 accept的调用将被阻塞，直到一个连接建立

SufferedReader in = serverSocket.accept();

-- 这种方案，任何时候都有大量线程在休眠，资源浪费。每个线程的调用栈分配内存，默认64KB - 1MB。多线程上下文切换开销巨大。

3、Java NIO 非阻塞调用

一个单一的线程就可以处理多个并发连接。

4、Netty 的特性总结

【1】设计  统计API，支持多种传输类型（阻塞的和非阻塞的），简单强大的线程模型，真正无连接数据报套接字支持，连接逻辑组件支持复用。

【2】易于使用

【3】性能  比Java核心API更高的吞吐量和更低的延迟

【4】健壮性  不会因为慢速、快速、超载的连接导致OutOfMemoryError，消除高速网络中NIO常见的不公平读\写比率

【5】安全性  完整的SSL\TLS\StartTLS支持

【6】社区驱动  发布快速且频繁

5、Netty 核心组件

Channel  传入、传出数据的载体

回调   一个方法，一个指向已经被提供给另一个方法的方法的引用

Future  提供了另一种在操作完成时通知应用程序的方式。（将来提供对其结果的访问）

事件和ChannelHandler  事件是对我们的通知（改变状态、记录日志等）。 ChannelHandler 一种为了响应特定事件而执行的回调。

6、Echo服务器

所有Netty服务器都需要的两部分：

【1】至少一个ChannelHeadler 该组件实现了服务器对从客户端接收的数据的处理（业务逻辑）

【2】引导  配置服务器启动代码。 将服务器绑定到它要监听连接请求的端口上。

7、Echo服务器端 方法

channelRead()  对于每个传入的消息都要调用

channelReadComplete()  通知ChannelInboundHandler最后一次对channelRead()的调用是当前批量读取中的最后一条消息。

exceptionCaught()   读取期间，有异常抛出会调用。

（在方法内打印异常并关闭。如果不捕获异常，接收的异常会                           

      被传递到ChannelPipeline尾端并记录。 应用程序应该提供至少一个实现exceptionCaught()

方法的channelHandler。 ）

8、ChannelHandler

针对不同类型事件调用ChannelHandler

应用程序通过实现或者扩展ChannelHandler来挂钩到事件的生命周期，并且提供自定义的应用程序逻辑。

架构上，ChannelHandler用于保持业务逻辑与网络处理代码的分离。简化开发过程。

9、传输

因特网通信是建立在TCP传输之上的，NIO传输大多时候指的就是TCP传输（除了一些由Java NIO实现提供的服务器端性能）。

10、Echo客户端

（1）连接到服务器

（2）发送一个或多个消息

（3）对每个消息，等待并接收从服务器发回的相同的消息。

（4）关闭连接

主要代码：【业务逻辑】【引导】

11、Echo客户端 方法

channelActive()  与服务器建立连接后 调用

channelRead0()  接收到服务器消息后 调用

exceptionCaught()  处理过程中有异常时 调用

12、客户端 继承 SimpleChannelInboundHandler 与 服务端 继承ChannelInboundHandlerAdapter 原因

在客户端：当ChannelRead0完成时，已经传入消息并处理完。该方法返回后，SimpleChannelInboundHandler会释放指定的内存应用。

在客户端：仍然需要将消息返回给发送者，write()是异步操作，ChannelInboundHandlerAdapter 不会释放消息内存。内存在channelReadComplete()方法中，writeAndFlush()方法被调用时被释放。

13、Netty网络抽象代表，三大接口

Channel - Socket

EventLoop - 控制流、多线程处理、并发（Netty核心抽象，处理连接的生命周期中发生的事件）

ChannelFuture - 异步通知

14、ChannelHandler 和 ChannelPipeline

ChannelHandler 充当了所有处理入站和出站数据的应用程序逻辑的容器

ChannelPipeline 为ChannelHandler链提供了容器

（可以在ChannelPipeline 中将ChannelHandler 链接在一起以组织处理逻辑）

15、入站和出站

入站：事件运动方向是从 服务端 到 客户端

出站：事件运动方向是从 客户端 到 服务端                             （例：客户端是内，服务端是外   外->内 ：入； 内->外：出）

16、编码器和解码器

入站消息会被解码

出站消息会被编码

17、引导

Netty引导类为应用程序的网路层提供容器。

将一个进程绑定到某个指定的端口。

或者 将一个进程连接到另一个运行在某个指定主机的指定端口上的进程。

两种引导，一种用于客户端（Bootstrap），一种用于服务端（ServerBootStrap）

类别	Bootstrap	ServerBootStrap
网络编程中的作用	连接到远程主机和端口	绑定到一个本地端口
EventLoopGroup	1	2

18、ChannelHandler 典型用途

（1）将数据从一种格式转换为另一种格式

（2）提供异常的通知

（3）提供Channel变为活动的或者非活动的通知

（4）提供当Channel注册到EventLoop或者从EventLoop注销时的通知

（5）提供有关用户自定义事件的通知

19、Channel 方法

方法名	描述
eventLoop	返回分配给Channel 的EventLoop
pipeline	返回分配给Channel 的 ChannelPipeline
isActive	如果Channel是活动的，返回true，活动的意义可能依赖于底层的传输。 （例：一个Socket 传输一旦连接到远程节点便是活动的，一个Datagram传输一旦被打开便是活动的）
localAddress	返回本地的SocketAddress
remoteAddress	返回远程的SocketAddress
write	将数据写到远程节点。数据将被传递给ChannelPipeline，并排队知道数据被冲刷
flush	将之前已写的数据冲刷到底层传输，（如一个socket）
writeAndFlush	一个简便的方法，等同于调用write()并接着调用flush()

20、Netty 提供的内置传输

名称	包	描述
NIO	io.netty.channel.socket.nio	使用java.nio.channels 包作为基础  -- 基于选择器的方式
Epoll	io.netty.channel.epoll	由JNI驱动的epoll()和非租塞IO。这个传输支持只有在Linux上可用的多种特性， （如：so_reuseport, 比NIO传输更快，而且是完全非租塞的）
OIO	io.netty.channel.socket.oio	使用java.net 包作为基础 -- 使用阻塞流
Local	io.netty.channel.local	可以在VM内部通过管道进行通信的本地传输
Embedded	io.netty.channel.embedded	Embedded传输，允许使用ChannelHandler而又不需要一个真正的基于网络的传输。 这在测试你的ChannelHandler实现时非常有用

21、零拷贝

一种目前只有在使用NIO和Epoll传输时才可以使用的特性。

可以快速高效的将数据从文件系统移动到网络接口，且不需要将其从内核空间复制到用户空间。在FTP或HTTP协议中可以显著地提升性能

注：只能传输文件的原始内容。可以传输加密的文件，不可以传输加密的数据或压缩的文件。

22、应用程序最佳传输

应用程序的需求	推荐的传输
非阻塞代码库或者一个常规的起点	NIO（或者LInux上使用epoll）
阻塞代码库	OIO
在同一个JVM内部的通信	Local
测试 ChannelHandler 的实现	Embedded

23、ByteBuf API 的优点

l  可以被用户自定义的缓冲区类型扩展

l  通过内置的复合缓冲区类型实现了透明的零拷贝

l  容量可以按需增长（类似于JDK的StringBuffer）

l  在读写两种类型切换时不需要调用byteBuffer的flip()方法

l  读写使用了不同的索引

l  支持方法的链式调用

l  支持引用计数

l  支持池化

24、ByteBuffy类  -- Netty 的数据容器

ByteBuf 维护了两个不同的索引：一个用于读取，一个用于写入。

ByteBuf 使用模式：

堆缓冲区  ByteBuf.hasArray()   为 true

直接缓冲区 ByteBuf.hasArray()   为 false

复合缓冲区 ByteBuf 的聚合视图，通过子类 CompositeByteBuf 实现

25、字节操作

随机访问索引：

ByteBuf 索引从0开始，最后一个索引为 capacity() - 1 。

例： byte b = byteBuf.getByte(i);

顺序访问索引：

0 - (已被读过的：可被丢弃的字节) ->readerIndex - （尚未被读的：可读字节） ->writeIndex - （可添加更多字节：可写字节） -> capacity

可丢弃字节：

调用 discardReadBytes() ，将可丢弃字节丢弃并回收空间到可写字节。（建议在内存宝贵时候调用）

可读字节：

ByteBuf 的可读字节分段存储实际数据。

名称以 read 或者 skip 开头的操作将增加已读字节数

可写字节：

可写字节分段 指一个拥有未定义内容的、写入就绪的内存区域。

任何以write开头的操作都将从当前的writeIndex处开始写数据，并将增加已经写入的字节数

索引管理：

mark(int readlimit) 将流中的当前位置标记为指定的值

reset()   将流重置到该位置

markReaderIndex() / markWriteIndex()            标记 ByteBuf 的 readerIndex 和WriteIndex

resetWriterIndex() / resetReaderIndex()  重置 ByteBuf 的 readerIndex 和WriteIndex

readerIndex(int)  /  writerIndex(int)    将索引移动到指定位置

clear()         将readerIndex 和writerIndex 都设置为0 且不会清除内存中的内容

查找操作：

Netty 4.1 中 使用io.netty.util.ByteProcessor  接口下方法。 来确定指定值的索引

派生缓冲区：

为ByteBuf提供专门的方式呈现视图。例：duplicate() , slice() , slice(int, int) , Unpooled.unmodifiableBuffer(...) , order(ByteOrder) , readSlice(int). 方法返回新的ByteBuf实例，具有自己的读、写索引和标记索引。  派生换缓冲区修改内容，也会修改对应的源实例内容。

【ByteBuf复制：使用copy() 或者 copy(int, int) 方法，返回ByteBuf 拥有的独立数据副本。】

读、写操作：

get() 和 set() 操作，从给定的索引开始，保持索引不变。

read() 和 write() 操作，从给定的索引开始，会根据已经访问过的字节

get() 操作

名称	描述
getBoolean(int)	返回给定索引处的 Bollean值
getByte(int)	返回给定索引处的 字节
getUnsignedByte(int)	将给定索引处的 无符号字节值作为short返回
getMedium(int)	返回给定索引处的 24位的中等int值
getUnsignedMedium(int)	返回给定索引处的 无符号的24位的中等 int 值
getInt(int)	返回给定索引处的 int 值
getUnsignedInt(int)	将给定索引处的 无符号 int 值作为 long 返回
getLong(int)	返回给定索引处的 long 值
getShort(int)	返回给定索引处的 short 值
getUnsignedShrt(int)	将给定索引处的无符号 short 值作为 int 返回
getByte(int, ...)	将该缓冲区中从给定索引开始的数据传送到指定的目的地

set() 操作

名称	描述
setBoolean(int, boolean)	设定给定索引处的 Boolean 值
setByte(int index, int value)	设定给定索引处的 字节值
setMedium(int index, int value)	设定给定索引处的 24位的中等 int 值
setInt(int index, int value)	设定给定索引处的 int 值
setLong(int index, long value)	设定给定索引处的 long 值
setShort(int index, int value)	设定给定索引处的 short 值

read() 操作

名称	描述
readBoolean()	返回当前 readerIndex 处的 Boolean， 并将readerIndex 增加 1
readByte()	返回当前readerIndex 处的字节，并将readerIndex 增加 1
readUnsignedByte()	将当前 readerIndex 处的无符号字节值作为short 返回，并将readerIndex 增加 1
readMedium()	返回当前readerIndex 处的24位的中等int 值，并将readerIndex 增加 3
readUnsignedMedium()	返回当前 readerIndex 处的 24位的无符号的中等int 值， 并将readerIndex 增加 3
readInt()	返回当前 readerIndex 处的int 值，并将readerIndex增加 4
readUnsignedInt()	将当前readerIndex处的无符号的int值作为long值返回， 并将readerIndex 增加 4
readLong()	返回当前readerIndex 处的long值，并将readerIndex 增加 8
readShort()	返回当前readerIndex 处的short 值，并将readerIndex 增加 2
readUnsignedShort()	将当前 readerIndex 处无符号 short 值 作为 int 值返回，并将readerIndex 增加 2
readBytes( ByteBuf | byte [] destinatuion, int dstIndex [ , int length] )	将当前 ByteBuf 中 从当前 readerIndex 处 开始的数据传送到一个目标 ByteBuf 或者 byte[],从目标的dstIndex开始的位置。本地的readerIndex将被增加已经传输的字节数。

write() 操作

名称	描述
writeBoolean( boolean )	在当前 writeIndex 处写入一个Boolean ，并将 writeIndex 增加 1
writeByte( int )	在当前 writeIndex 处写入一个字节值，并将writeIndex 增加 1
writeMedium( int )	在当前 writeIndex 处写入一个中等的 int 值， 并将writeIndex 增加 3
writeInt ( int )	在当前 writeIndex 处写入一个 int 值，并将writeIndex 增加 4
writeLong ( long )	在当前 writeIndex 处写入一个 long 值，并将 writeIndex 增加 8
writeShort ( int )	在当前writeIndex 处写入一个 short 值， 并将 writeIndex 增加 2
writeBytes ( source ByteBuf | byte [] [ , int srcIndex , int length ] )	从 当前writeIndex 开始，传输来自于指定源的数据，如果提供了srcIndex 和 length， 则从 srcIndex 开始读取，并且处理长度为 length 的字节，当前 writeIndex 将会被增加所写入的字节数。

更多操作

名称	描述
isReadable()	如果至少有一个字节可读取，返回 true
isWritable()	如果至少有一个字节可写入，返回 true
readableByte()	返回可被读取的字节数
writableBytes()	返回可被写入的字节数
capacity()	返回ByteBuf 可容纳的字节数， 此后，会尝试再次扩展，直到达到maxCapacity()
maxCapacity()	返回ByteBuf 可以容纳的最大字节数
hasArray()	如果ByteBuf 由一个字节数组支撑，则返回 true
array()	如果ByteBuf 由一个字节数组支撑则返回该数组，否则，它将抛出一个 UnsupportedOperationException 异常

26、ByteBufAllocator 池化和引用计数

池化：为了降低分配和释放内存的开销，可以分配任意类型的ByteBuf类型。

引用计数：通过某个对象持有的资源不在被其他对象引用时，释放该对象持有资源来 优化内存使用和性能的技术。

27、ChannelHandler

Channel 的生命周期状态

状态	描述
ChannelUnregistered	Channel 已经被创建，但还未注册到EventLoop
ChannelRegistered	Channel 已经被注册到了EventLoop
ChannelActive	Channel 处于活动状态（已经连接到它的远程节点）。它现在可以接收和发送数据了
ChannelInactive	Channel 没有连接到远程节点

ChannelHandler 的生命周期

状态	描述
handlerAdded	当把 ChannelHandler 添加到 ChannelPipeline 中时被调用
handlerRemoved	当从 ChannelPipeline 中移除 ChannelHandler 时被调用
exceptionCaught	当处理过程中在 ChannelPipeline 中有错误时被调用

ChannelHandler 两个重要的子接口： ChannelInboundHandler 、 ChannelOutboundHandler

（1）ChannelInboundHandler 的实现重写 channelRead() 方法，负责显示地释放与池化 ByteBuf 内存。

Netty一个实用方法 -- ReferenceCountUtil.release(msg);

或者 另一种简单方式：实用 SimpleChannelInboundHandler

（2）ChannelOutBoundHandler 接口

ChannelOutBoundHandler  功能在于 按需推迟操作或者事件。

ChannelOutboundHandler 中大部分方法都需要一个ChannelPromise 参数，在操作完成时得到通知。

28、资源管理

诊断潜在的资源泄露。 有四种检测级别

级别	描述
DISABLED	禁用泄漏检测。只有在详尽的测试之后才应使用
SIMPLE	使用1%的默认采样率检测并报告任何发现的泄露。这是默认级别，适合绝大部分情况。
ADVANCED	使用默认的采样率，报告所发现的任何的泄露以及对应的消息被访问的位置
PARANOID	类似于ADVANCED，但是其将会对每次（对消息的）访问都进行采样。这对性能将会有很大影响，在调试阶段使用

总之：如果消息被消费或者丢弃了，并且没有传递给ChannelPipeline 中的下一个ChannelOutboundHandler ，那么用户就有责任调用 ReferenceCountUtil.release()。 如果消息到达了实际传输层，当它被写入时，或者Channel关闭时，会自动释放。

29、ChannelPipeline 接口

每个新创建的 Channel 都将会被分配一个新的 ChannelPipeline 。这是永久性关联。

Netty 总是将 ChannelPipeline 的入站口作为头部，出站口作为尾部。

ChannelHandler 可以添加、删除、替换 其他的ChannelHandler，从而实时修改ChannelPipeline 布局。

名称	描述
addFirst addBefore addAfter addLast	将一个ChannelHandler 添加到ChannelPipeline 中
remove	将一个ChannelHandler 从 ChannelPipeline 中移除
replace	将 ChannelPipeline 中的一个 ChannelHandler 替换为另一个ChannelHandler

ChannelPipeline 用于访问 ChannelHandler 的操作

名称	描述
get	通过类型或者名称返回 ChannelHandler
context	返回和ChannelHandler 绑定的 ChannelHandlerContext
names	返回ChannelPipeline 中所有 ChannelHandler 的名称

总结：

l  ChannelPipeline 保存了与Channel 相关联的ChannelHandler；

l  ChannelPipeline 可以根据需要，通过添加或者删除ChannelHandler 来动态地修改；

l  ChannelPipeline 有着丰富的 API 用以被调用，以响应入站和出站事件。

30、ChannelHandlerContext 接口

ChannelHandlerContext 主要功能是管理它所关联的ChannelHandler 和在同一个 ChannelPipeline 中的其他 ChannelHandler 之间的交互。

如果调用 Channel 或者ChannelPipeline 上的方法，流程将沿着ChannelPipeline 进行传播。调用ChannelHandlerContext 上的相同方法，流程从关联的ChannelHandler 开始，并且只会传播位于该 ChannelPipeline 中的下一个能够处理的该事件的 ChannelHandler。

注：重要   ChannelHandlerContext 和 ChannelHandler 之间关联（绑定）是永远不会改变的，所以缓存对它的引用是安全的。

相对于其他类的同名方法，ChannelHandlerContext 的方法将产生更短的事件流，可以用这个特定获得最大性能。

31、共享同一个 ChannelHandler

在多个 ChannelPipeline 中安装同一个ChannelHandler 的一个常见原因：用于收集跨域多个 Channel 的统计信息。

32、处理入站异常

l  ChannelHandler.exceptionCaught（）的默认将异常转发给 ChannelPipeline 中的下一个ChannelHandler；

l  如果异常到达ChannelPipeline 尾端，将会被记录为未被处理；

l  想要定义自定义的处理逻辑，需要重写 exceptionCaught（） 方法。然后决定是否把异常传播出去。

33、处理出站异常

l  出站操作都返回一个ChannelFuture。注册到ChannelFuture 的ChannelFutureListener 将在操作完成时被通知操作是成功还是出错了。

l  所有 ChannelOutboundHandler 上的方法都会传入 ChannelPromise 。ChannelPromise 可以被分配用于异步通知的监听器。ChannelPromise 还具有提供立即通知的可写方法。

34、ChannelPromise 的可写方法

通过调用 ChannelPromise 上的 setSuccess（） 和 setFailure（）方法，可使一个操作状态在 ChannelHandler 方法返回给调用者时即刻被感知到。

34、基本的线程池化

l  从池的空闲线程列表中选择一个 Thread，并且指派它去运行一个已提交的任务（一个Runnable的实现）

l  当任务完成时，将该Thread返回给该列表，使其可被重用。

35、引导

引导一个应用程序指 对它进行配置，并使它运行起来的过程。

36、IllegalStateException

在引导过程中，调用bind() 或者connect() 方法钱，必须调用 group()、channel()或channelFactory()、handler()   ； 如果没有调用，会导致 IllegalStateException 。对handler() 方法调用很重要，它需要配置好ChannelPipeline。

37、Netty应用程序一般准则

尽可能地重用EventLoop，以减少线程创建所带来的开销。

38、EventLoopGroup.shutdownGracefully()  关闭

处理任何挂起的事件和任务，并且随后释放所有活动的线程。

39、编码器、解码器

编码器：将消息转换为适合于传输的格式（例：字节流）。处理出站数据

解码器：将网络字节流转回应用程序的消息格式。处理入站数据

40、ByteToMessageDecoder API

方法	描述
decode( ChannelHandlerContext ctx, ByteBuf in, List<Object> out)	必须实现的唯一抽象方法。 方法被调用时传入一个包含传入数据的ByteBuf，和一个添加解码消息的List。 对方法的调用会重复进行，知道没有新元素被添加到List，或ByteBuf中没有更多可读取的字节。 如果List不为空，它的内容会被传递给ChannelPipeline中的下一个ChannelInboundHandler
decodeLast( ChannelHandlerContext ctx, ByteBuf in, List<Object> out)	简单调用decode()方法， 当Channel状态为非活动时，这个方法会被调用一次。 可以重写该方法已提供特殊处理

41、解码器中的引用计数

对于编码器和解码器。一旦消息被编码或解码，它就被ReferenceCountUtil.release(message) 调用自动释放。

如果需要保留，可以调用ReferenceCountUtil.retain(message)。将会增加该引用计数，防止消息被释放。

42、MessagetoMessageDecoder API

方法	描述
decode ( ChannelHandlerContext ctx, I msg, List<Object> out)	每个需要被解码为另一种格式的入站消息来说，该方法都将被调用。 解码消息随后会传递给 ChannelPipeline中的下一个ChannelInboundHandler

43、TooLongFrameException 类

由解码器在帧超出指定的大小限制时抛出。

44、MessageToByteEncoder API

方法	描述
encode( ChannelHandlerContext ctx, I msg, ByteBuf out)	唯一抽象方法，被调用时传入该类编码为ByteBuf的出站消息，该消息随后会被转发给ChannelPipeline中的下一个ChannelOutboundHandler

45、ByteToMessageCodec API

方法名称	描述
decode( ChannelHandlerContext ctx, ByteBuf in, List<Object>)	只要有字节可以被消费，这个方法就将被调用。它将入站ByteBuf 转换为指定的消息格式，并将其转发给ChannelPipeline 中的下一个ChannelInboundHandler
decodeLast( ChannelHandlerContext ctx, ByteBuf in, List<Object>  out)	这个方法默认实现委托给decode()方法。在Channel状态变为非活动时被调用一次。可以被重写以实现特殊处理。
encode( ChannelHandlerContext ctx, I msg, ByteBuf  out)	对每个将被编码并写入出站ByteBuf的消息来说，这个方法都会被调用。

46、MessageToMessageCodec 的方法

方法名称	描述
protected abstract decode( ChannelHandlerContext ctx, INBOUND_IN msg, List<Object> out)	传入INBOUND_IN 类型的消息。并把它解码为OUTBOUND_IN 类型的消息， 消息被转发给ChannelPipeline中的下一个ChannelInboundHandler
protected abstract encode( ChannelHandlerContext ctx, OUTBOUND_IN msg, List<Object> out)	对每个OUTBOUND_IN 类型的消息，该方法都被调用。消息会被编码为INBOUND_IN 类型的消息， 然后转发给ChannelPipeline中的下一个ChannelOutboundHandler

47、SshHandler 的方法

方法名称	描述
setHandshakeTimeout (long , TimeUnit) setHandshakeTimeoutMillis (long) getHandshakeTimeoutMillis ()	设置和获取超市事件，超时后，握手ChannelFuture 将会被通知失败
setCloseNotifyTimeout (long, TimeUnit) setCloseNotifyTimeoutMillis (long) getCloseNotifyTimeoutMillis ()	设置和获取超时时间，超时后，将会触发一个关闭通知并关闭连接。同时会导致通知该ChannelFuture 失败
handshakeFuture()	返回一个在握手完成后将会得到通知的ChannelFuture，如果握手前已经执行过，则返回包含了先前握手结果的ChannelFuture
close() close(ChannelPromise) close(ChannelHandlerContext, ChannelPromise)	发送 close_notify 以请求关闭并销毁底层的SslEngine

48、用于空闲链接以及超时的ChannelHandler

名称	描述
IdleStateHandler	当链接空闲时间太长，将触发一个IdleStateEvent 事件。然后，可以通过 ChannelInboundHandler中重写userEventTriggered（）方法来处理该 IdleStateEvent 事件
ReadTimeoutHandler	如果指定时间间隔内没收到任何入站数据，则抛出一个ReadTimeoutException 并关闭对应Channel。可以重写ChannelHandler中的exceptionCaught（）方法检测该事件
WriteTimeoutHandler	如果指定时间间隔内没有任何出站数据写入，则抛出WriteTimeoutExceptoin 并关闭对应Channel。可以重写ChannelHandler 的exceptionCaught（）方法检测该事件

49、处理基于分隔符的协议和基于长度的协议的解码器

名称	描述
DelimiterBasedFrameDecoder	使用任何由用户提供的分隔符来提取帧的通用解码器
LineasedFrameDecoder	提取由行尾符（\n 或者 \r\n）分割的帧的解码器。这个解码器比DelimiterBaseFrameDecoder 更快

名称	描述
FixedLengthFrameDecoder	提取在调用构造函数时指定的定长帧
LengthFieldBaseFrameDecoder	根据编码进帧头部中的长度值提取帧； 该字段的偏移量以及长度在构造函数中指定

50、ChunkedWriteHandler

需要将数据从文件系统复制到用户内存中时，使用 ChunkedWriteHandler ，它支持异步写大型数据流，且不会导致大量的内存消耗。

51、JDK序列化编解码器

名称	描述
CompatibleObjectDecoder	和使用JDK序列化的 非基于Netty的 远程节点 进行互操作的解码器
CompatibleObjectEncode	和使用JDK序列化的 非基于Netty的 远程节点 进行互操作的编码器
ObjectDecoder	构建于JDK 序列化之上的使用自定义的序列化来解码的解码器； 当没有其他的外部依赖时，它提供了速度上的改进。否则其他序列化更可取
ObjectEncoder	构建于JDK序列化之上的使用自定义的序列化来编码的编码器； 当没有其他的外部依赖时，它提供了速度上的改进。否则其他序列化更可取

52、JBoss Marshalling 编解码器

名称	描述
CompatibleMarchallingDecoder CompatibleMarshallingEncoder	与只使用JDK序列化的远程节点兼容
MarshallingDecoder MarshallingEncoder	适用于使用JBoss Marshalling 的节点。这些类必须一起使用

53、Protobuf 编解码器

名称	描述
ProtobufDecoder	使用 protobuf 对消息进行解码
ProtobufEncoder	使用 protobuf 对消息进行编码
ProtobufVarint32FrameDecoder	根据消息中的Google Protocol Buffer 的 “Base 128 Varints” 整型长度字段值动态地分割所接收到的ByteBuf
ProtobufVarint32LengthFieldPrepender	向ByteBuf 前追加一个Google Protocal Buffer 的“Base 128 Varints” 整型的长度字段值