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” 整型的长度字段值 |