基于netty 4.x
相关页面地址:
4.x用户指南:https://netty.io/wiki/user-guide-for-4.x.html
Netty Example:https://github.com/netty/netty/tree/4.1/example/src/main/java/io/netty/example
API:https://netty.io/4.1/xref/index.html
Netty框架
Netty是一个基于NIO的异步事件驱动的网络应用程序框架和工具,使用他可以快速轻松的开发
出高性能和高扩展性的网络应用程序,例如自定义协议的服务器和客户端。它极大地简化和简化了网络编程,如TCP和UDP套接字服务器的开发。
线程模型与异步处理
线程模型
Reactor(反应堆模型)
Reactor模式也叫Dispatcher模式,即I/O多路复用统一监听事件,收到事件后分发(Dispatch给某进程)
Reactor就是一个执行while (true) { selector.select(); ...}循环的线程,会源源不断的产生新的事件
Reactor模型中有2个关键组成:
- Reactor Reactor在一个单独的线程中运行,负责监听和分发事件,分发给适当的处理程序来对IO事件做出反应。
- Handlers 处理程序执行I/O事件要完成的实际事件
取决于Reactor的数量和Hanndler线程数量的不同,Reactor模型有3个变种
- 单Reactor单线程
- 单Reactor多线程
- 主从Reactor多线程
Netty线程模型
Netty主要基于主从Reactors多线程模型,其中Reactor分为:MainReactor和SubReactor:
- MainReactor负责客户端的连接请求,并将请求转交给SubReactor
- SubReactor负责相应通道的IO读写请求
- 非IO请求(具体逻辑处理)的任务则会直接写入队列,等待worker threads进行处理
虽然Netty的线程模型基于主从Reactor多线程,但是实际实现上SubReactor和Worker线程在同一个线程池中
- bossGroup线程池则只是在bind某个端口后,获得其中一个线程作为MainReactor,专门处理端口的accept事件,每个端口对应一个boss线程
- workerGroup线程池会被各个SubReactor和worker线程充分利用
异步处理
Netty中的I/O操作是异步的,包括bind、write、connect等操作会简单的返回一个ChannelFuture,调用者并不能立刻获得结果,通过Future-Listener机制,用户可以方便的主动获取或者通过通知机制获得IO操作结果。
- 通过isDone方法来判断当前操作是否完成
- 通过isSuccess方法来判断已完成的当前操作是否成功
- 通过getCause方法来获取已完成的当前操作失败的原因
- 通过isCancelled方法来判断已完成的当前操作是否被取消
- 通过addListener方法来注册监听器,当操作已完成(isDone方法返回完成),将会通知指定的监听器;如果future对象已完成,则立即通知指定的监听器
内存
Netty中使用了自己实现的ByteBuffer,直接内存,内存池化,引用计数器等技术,重点要看一下 io.netty.buffer.ByteBuf
ByteBuffer
零个或多个字节(八位字节)的随机且顺序可访问的序列。此接口提供一个或多个原始字节数组(byte [])和NIO buffers 的抽象视图。
创建缓冲区
建议在Unpooled中使用辅助方法创建一个新的缓冲区,而不是调用单个实现的构造函数。
随机存取索引
就像普通的原始字节数组一样,ByteBuf使用从零开始的索引。这意味着第一个字节的索引始终为0,而最后一个字节的索引始终为-1。例如,要迭代缓冲区的所有字节,您可以不管其内部实现如何,请执行以下操作:
ByteBuf buffer = ...;
for (int i = 0; i < buffer.capacity(); i ++) {
byte b = buffer.getByte(i);
System.out.println((char) b);
}
顺序访问索引
ByteBuf提供了两个指针变量来支持顺序读取和写入操作;分别是针对读操作的readerIndex和针对写操作的writerIndex。
无需像使用JDK中的Buffer那样手动flip()
读操作:
名称以read或skip开头的任何操作都将获取或跳过当前readerIndex处的数据,并将其增加读取字节数。如果读取操作的参数是ByteBuf,并且未指定目标索引,则指定缓冲区的writerIndex会一起增加。
如果没有足够的内容,则会引发IndexOutOfBoundsException。
新分配,包装或复制的缓冲区的readerIndex的默认值为0。
// 迭代缓冲区的可读字节
ByteBuf buffer = ...;
while (buffer.isReadable()) {
System.out.println(buffer.readByte());
}
写操作:
名称以write开头的任何操作都将在当前writerIndex处写入数据,并将增加其writerIndex的计数。如果写操作的参数是ByteBuf,并且未指定源索引,则指定缓冲区的readerIndex会一起增加。
如果没有足够的可写字节,则引发IndexOutOfBoundsException。新分配的缓冲区的writerIndex的默认值为0。包装或复制的缓冲区的writerIndex的默认值为缓冲区的容量。
// 用随机整数填充缓冲区的可写字节
ByteBuf buffer = ...;
while (buffer.maxWritableBytes() >= 4) {
buffer.writeInt(random.nextInt());
}
丢弃已经读取的字节:
通过调用discardReadBytes()来丢弃已经读取的字节,以回收使用的字节区域。
示例:
调用 discardReadBytes() 之前 (已经读取了一定的字节)
+-------------------+------------------+------------------+
| discardable bytes | readable bytes | writable bytes |
+-------------------+------------------+------------------+
| | | |
0 <= readerIndex <= writerIndex <= capacity
调用 discardReadBytes()之后 (相关指针前移,已经读取过的内容被丢弃)
+------------------+--------------------------------------+
| readable bytes | writable bytes (got more space) |
+------------------+--------------------------------------+
| | |
readerIndex (0) <= writerIndex (decreased) <= capacity
清除缓冲区索引:
可以通过调用clear()将readerIndex和writerIndex都设置为0,它不会清除缓冲区内容(例如填充0),而只是清除两个指针。
请注意,此操作的语义与java.nio.ByteBuffer.clear()不同。
搜索操作
对于简单的单字节搜索,请使用indexOf(int,int,byte) 和 bytesBefore(int,int,byte) 。当处理以NUL结尾的字符串时,bytesBefore(byte) 特别有用。对于复杂的搜索,请使用带有ByteProcessorimplementation的forEachByte(int,int,ByteProcessor)。
标记和重置
每个缓冲区中都有两个标记索引。一种用于存储readerIndex,另一种用于存储writerIndex。您始终可以通过调用reset方法来重新定位两个索引之一。除了没有readlimit以外,它的工作方式与InputStream中的mark和reset方法类似。
派生缓冲区
您可以通过调用以下方法之一来创建现有缓冲区的视图:
- duplicate()
- slice()
- slice(int, int)
- readSlice(int)
- retainedDuplicate()
- retainedSlice()
- retainedSlice(int, int)
- readRetainedSlice(int)
派生的缓冲区将具有独立的readerIndex,writerIndex和标记索引,而它共享其他内部数据表示形式,就像NIO缓冲区一样。
如果需要现有缓冲区的全新副本,请调用 copy( ) 方法。
非保留和保留派生缓冲区
请注意,plicate(),slice(),slice(int,int)和readSlice(int) 不会在返回的派生缓冲区上调用retain(),因此不会增加其引用计数。如果需要创建具有增加的引用计数的派生缓冲区,请考虑使用retainedDuplicate(),retainedSlice(),retainedSlice(int,int) 和 readRetainedSlice(int),这可能会返回产生较少垃圾的缓冲区实现。
转换为现有的JDK类型
字节数组
如果ByteBuf由字节数组(即byte [])支持,则可以直接通过array()方法访问它。要确定缓冲区是否由字节数组支持,应使用hasArray()。
NIO缓冲区
如果ByteBuf可以转换为共享其内容的NIO ByteBuffer(即视图缓冲区),则可以通过nioBuffer()方法获取它。要确定是否可以将缓冲区转换为NIO缓冲区,请使用nioBufferCount()。
String
各种toString(Charset)方法将ByteBufin转换为String。请注意,toString()不是转换方法。
I/O流
请参考ByteBufInputStream和ByteBufOutputStream。
计数引用
ByteBuf 实现了 ReferenceCounted 接口
在Netty handler的设计规范中,所有输入的数据在处理结束时都会调用ReferenceCountUtil.release()释放,只是具体释放方法根据池化、非池化、直接内存、堆内存的不同实现不同。
ReferenceCounted
一个引用计数的对象,需要显式取消分配。
实例化一个新的ReferenceCounted时,它以引用计数为1开头。keep() 增加引用计数,release() 减少引用计数。
如果引用计数减小为0,则将显式释放该对象,并且 访问已释放对象通常会导致访问冲突。
如果实现ReferenceCounted的对象是其他实现ReferenceCounted的对象的容器,则当容器的引用计数变为0时,包含的对象也将通过release() 释放。
ReferenceCountUtil
一个工具方法集合,处理的对象需要实现 ReferenceCounted
直接内存(堆外内存)
实现零拷贝,既使用时无需将内存从系统空间复制到用户空间
主要是指接收和发送 ByteBuffer 使用虚拟机的堆外内存,不用将内存内容拷贝到jvm的堆中
内存块池化
对于堆外内存的申请分配以及释放是一个比较耗时的操作,不能像jvm中一样快(jvm已经提前像系统申请了一块内存空间)
Netty为了重用这些内存,将内存分成一块一块的小内存,然后将内存块像线程池中的线程一样重复使用,来避免重复的分配和回收操作。(据说性能超高,没有测试过)
ByteBufAllocator
实现负责分配缓冲区。这个接口的实现应该是线程安全的。
UnpooledByteBufAllocator
非池化内存分配器
PooledByteBufAllocator
池化内存分配器
io.netty.buffer.Unpooled
通过分配新空间或包装或复制现有字节数组、字节缓冲区和字符串来创建新的ByteBuf。
静态方法
import static io.netty.buffer.Unpooled.*;
ByteBuf heapBuffer = buffer(128);
ByteBuf directBuffer = directBuffer(256);
ByteBuf wrappedBuffer = wrappedBuffer(new byte[128], new byte[256]);
ByteBuf copiedBuffer = copiedBuffer(ByteBuffer.allocate(128));
分配新缓冲区
buffer(int) 分配一个新的固定容量堆缓冲区。
directBuffer(int) 分配一个新的固定容量直接缓冲区。
创建包装的缓冲区
包装缓冲区是一种缓冲区,它是一个或多个现有字节数组和字节缓冲区的视图。原始数组或缓冲区内容的任何更改都将在包装的缓冲区中可见。提供了各种包装方法,它们的名称全为wrappedBuffer()。如果要创建一个由多个数组组成的缓冲区以减少内存副本的数量,则可能需要仔细研究一下接受varargs的方法。
创建复制的缓冲区
复制缓冲区是一个或多个现有字节数组,字节缓冲区或字符串的深层副本。与包装的缓冲区不同,原始数据和复制的缓冲区之间没有共享数据。提供了各种复制方法,它们的名称全为copyedBuffer()。使用此操作将多个缓冲区合并为一个缓冲区也很方便。
重点类介绍
启动辅助类
ServerBootstrap
服务端用
ServerBootstrapAcceptor的channelRead方法,
会将进入的连接注册到workerGroup (NioEventLoopGroup)中,之后的读写以及业务操作就是NioEventLoopGroup中的EventLoop来处理了
注册时会有一定的机制(DefaultEventExecutorChooserFactory,就是轮询)来决定用哪一个EventLoop来处理本次连接
Bootstrap
客户端用
bind()方法与无连接传输如数据报(UDP)结合使用非常有用。对于常规TCP连接,请使用提供的connect()方法。
Channel (通道)
网络套接字或能够进行I/O操作(如读、写、连接和绑定)的组件的连接。
通道为用户提供:
- 通道的当前状态(例如:是否打开,是否是连接状态)
- 通道的配置参数(例如接收缓冲区大小)
- 通道支持的I/O操作(例如,读、写、连接和绑定)
- ChannelPipeline处理与通道相关的所有I/O事件和请求。
所有I/O操作都是异步的
Netty中的所有I/O操作都是异步的。这意味着任何I/O调用将立即返回,而不能保证所请求的I/O操作在调用结束时已经完成。返回一个ChannelFuture实例,该实例将在请求的I/O操作成功、失败或取消时通知你。
释放资源
一旦Channel使用完毕,调用ChannelOutboundInvoker.close()或ChannelOutboundInvoker.close(ChannelPromise)释放所有资源非常重要。这样可确保以适当的方式释放所有资源,如文件描述符。
SocketChannel
TCP/IP套接字通道
两个常用子类
NioServerSocketChannel 用于服务端,它使用基于NIO选择器的实现来接受新连接。
NioSocketChannel 用于客户端,它使用基于NIO选择器的实现
DatagramChannel
UDP/IP 通道
常用子类
NioDatagramChannel NIO的UDP数据包通道
NioEventLoop (事件循环)
SingleThreadEventLoop的实现,它将Channel注册到选择器中,并且在事件循环中对它们进行多路复用。
该类在单个线程中以有序/串行的方式执行提交的所有任务。
本质上是一个单线程的线程池,通过execute方法提交的任务都将被这个Thread线程来执行
在注册时会执行execute方法,调用doStartThread,启动事件循环
调用doStartThread 只会执行一次
代码在:
SingleThreadEventExecutor.doStartThread()
SingleThreadEventExecutor.this.run();
里面有个固定无限循环,来判断selector中是否有事件
就像我们写NOI的那个循环一样
NioEventLoop.run()
还实现了:ScheduledExecutorService 调度线程池
channel 会绑定到一个eventLoop中,这个channel对应的所有操作都会由这个eventLoop来执行,
包括所有的IO操作和handler中业务逻辑
但是多个channel 可能会被分配到同一个eventLoop中
因为是单线程的,它将以有序/串行方式处理所有提交的任务,这样不必要考虑并发同步的问题。
NioEventLoopGroup (事件循环组)
MultithreadEventLoopGroup的实现,用于基于NIO 选择器的Channel。
它同时使用多个线程处理它的任务,通过它的next()方法提供要使用的EventExecutor。除此之外,它还负责处理它们的生命周期,并允许以全局方式关闭它们。
new NioEventLoopGroup() 没有参数时:
- 默认的NioEventLoop的数量是机器CPU数量的两倍
- 默认的拒绝策略是:拒绝(抛异常)
- eventLoop做事件循环时的Selector如果没有指定将使用系统默认的,如windows的WindowsSelectorProvider
NioEventLoopGroup是用来管理NioEventLoop的,里面有一个 EventExecutor[] children;
管理着这个组下的全部事件循环EventLoop对象
初始化时会实例化全部的NioEventLoop对象,通过 EventLoop newChild(Executor executor, Object... args)
方法
channel初始化时会进行注册,注册通道时调用 next().register(channel)
服务端程序在 ServerBootstrapAcceptor 的channelRead 方法中将新的channel注册到workerGroup中
next方法会通过EventExecutorChooser(默认轮询)来获取EventExecutor(NioEventLoop)
bossGroup 只需要一个 NioEventLoop 就可以了,只负责将channel注册到 workerGroup 中
workerGroup 默认CPU核心数*2 个NioEventLoop
ChannelPipeline (管道)
ChannelHandler的列表,用于处理或拦截Channel的入站事件和出站操作。
ChannelPipeline实现了一种高级的拦截、过滤模式,以使用户可以完全控制事件的处理方式以及管道中的ChannelHandler如何相互交互。
每个Channel都有其自己的ChannelPipeline,并且在创建新Channel时会自动创建它。
下图描述了ChannelPipeline典型地ChannelHandler如何处理I/O事件。 I/O事件由ChannelInboundHandler或ChannelOutboundHandler处理,并通过调用ChannelHandlerContext中定义的事件传播方法(例如ChannelHandlerContext.fireChannelRead(Object)和ChannelHandlerContext.write(Object))转发到其最近的处理程序。
I/O Request
via {@link Channel} or
{@link ChannelHandlerContext}
|
+---------------------------------------------------+---------------+
| ChannelPipeline | |
| \|/ |
| +---------------------+ +-----------+----------+ |
| | Inbound Handler N | | Outbound Handler 1 | |
| +----------+----------+ +-----------+----------+ |
| /|\ | |
| | \|/ |
| +----------+----------+ +-----------+----------+ |
| | Inbound Handler N-1 | | Outbound Handler 2 | |
| +----------+----------+ +-----------+----------+ |
| /|\ . |
| . . |
| ChannelHandlerContext.fireIN_EVT() ChannelHandlerContext.OUT_EVT()|
| [ method call] [method call] |
| . . |
| . \|/ |
| +----------+----------+ +-----------+----------+ |
| | Inbound Handler 2 | | Outbound Handler M-1 | |
| +----------+----------+ +-----------+----------+ |
| /|\ | |
| | \|/ |
| +----------+----------+ +-----------+----------+ |
| | Inbound Handler 1 | | Outbound Handler M | |
| +----------+----------+ +-----------+----------+ |
| /|\ | |
+---------------+-----------------------------------+---------------+
| \|/
+---------------+-----------------------------------+---------------+
| | | |
| [ Socket.read() ] [ Socket.write() ] |
| |
| Netty Internal I/O Threads (Transport Implementation) |
+-------------------------------------------------------------------+
入站事件由入站处理程序在自下而上的方向上进行处理,如该图的左侧所示。入站处理程序通常处理由图底部的I/O线程生成的入站数据。通常通过实际的输入操作(例如SocketChannel.read(ByteBuffer))从远程对等方读取入站数据。如果入站事件超出了顶部入站处理程序的范围,则将其静默丢弃,或者在需要引起注意时将其记录下来。
出站事件由出站处理程序按自上而下的方向进行处理,如该图的右侧所示。出站处理程序通常会生成或转换出站流量(例如写请求)。如果出站事件超出了底部出站处理程序,则由与通道关联的I/O线程处理。 I/O线程通常执行实际的输出操作,例如SocketChannel.write(ByteBuffer)。
假设我们创建了如下的管道
ChannelPipeline p = ...;
p.addLast("1", new InboundHandlerA());
p.addLast("2", new InboundHandlerB());
p.addLast("3", new OutboundHandlerA());
p.addLast("4", new OutboundHandlerB());
p.addLast("5", new InboundOutboundHandlerX());
在上面的示例中,名称以Inbound开头的类表示它是一个入站处理程序。名称以Outbound开头的类表示它是一个出站处理程序。
在给定的示例配置中,事件进入时处理程序的评估顺序为1、2、3、4、5。事件离开时,处理程序的评估顺序为5、4、3、2、1。
ChannelPipeline跳过某些处理程序的评估,以缩短堆栈深度:
- 3和4没有实现ChannelInboundHandler,因此入站事件的实际评估顺序为:1、2和5。
- 1和2没有实现ChannelOutboundHandler,因此出站事件的实际评估顺序为:5、4和3。
- 如5同时实现ChannelInboundHandler和ChannelOutboundHandler,则入站和出站事件的评估顺序可能分别为1 2 5和5 4 3。
ChannelPipeline是线程安全的,也就是说,我们可以动态的添加、删除其中的ChannelHandler。考虑这样的场景:服务器需要对用户登录信息进行加密,而其他信息不加密,则可以首先将加密Handler添加到ChannelPipeline,验证完用户信息后,主动从ChnanelPipeline中删除,从而实现该需求
ChannelHandlerContext (处理器的上下文)
channelHandler 的上下文对象,使ChannelHandler可以与ChannelPipeline中的其他Handler进行交互。
使用上下文对象,ChannelHandler可以在上下游传递事件,动态修改管道(在管道中动态的插入或删除ChannelHandler)或存储特定于处理程序的信息(使用AttributeKeys)。
结合ChannelPipeline
处理程序必须调用ChannelHandlerContext中的事件传播方法,以将事件转发到其下一个处理程序。这些方法包括:
入站事件传播方法:
ChannelHandlerContext.fireChannelRegistered()
ChannelHandlerContext.fireChannelActive()
ChannelHandlerContext.fireChannelRead(Object)
ChannelHandlerContext.fireChannelReadComplete()
ChannelHandlerContext.fireExceptionCaught(Throwable)
ChannelHandlerContext.fireUserEventTriggered(Object)
ChannelHandlerContext.fireChannelWritabilityChanged()
ChannelHandlerContext.fireChannelInactive()
ChannelHandlerContext.fireChannelUnregistered()
出站事件传播方法:
ChannelHandlerContext.bind(SocketAddress,ChannelPromise)
ChannelHandlerContext.connect(SocketAddress,SocketAddress,ChannelPromise)
ChannelHandlerContext.write(Object,ChannelPromise)
ChannelHandlerContext.flush()
ChannelHandlerContext.read()
ChannelHandlerContext.disconnect(ChannelPromise)
ChannelHandlerContext.close(ChannelPromise)
ChannelHandlerContext.deregister(ChannelPromise)
如何进行事件传播:
public class MyInboundHandler extends ChannelInboundHandlerAdapter {
@Override
public void channelActive(ChannelHandlerContext ctx) {
System.out.println("Connected!");
ctx.fireChannelActive();
}
}
public class MyOutboundHandler extends ChannelOutboundHandlerAdapter {
@Override
public void close(ChannelHandlerContext ctx, ChannelPromise promise) {
System.out.println("Closing ..");
ctx.close(promise);
}
}
ChannelInitializer(通道初始化器)
一个特殊的ChannelHandler,用于给ChannelPipeline绑定handler
在连接建立时会调用handlerAdded方法然后调用initChannel方法,然后执行我们编写的
channelPipeline.addLast(new StringDecoder())
等代码,这里使用的是new 一个新对象,这样就能给每一个连接创建独立的handler实例了,这些实例就可以保存各种状态
ChannelHandler(处理器)
处理网络IO事件,对消息进行编码解码,和一定的业务逻辑处理。我们主要就实现各种Handler。
过长时间的业务逻辑代码如果编写在ChannelHandler中,不能直接在workerGroup线程池中处理,可能阻塞其他的IO操作
通过外部线程池,或指定Handler的执行线程池来处理
通常必须实现下面的两个子类之一:
- ChannelInboundHandler 处理入站I/O事件
- ChannelOutboundHandler 处理出站I/O事件
另外还提供了以下适配器类:
- ChannelInboundHandlerAdapter 处理入站I/O事件
- ChannelOutboundHandlerAdapter 处理出站I/事件
- ChannelDuplexHandler 可以处理入站和出站事件
Handler中的状态管理
1. 在Handler实现类中使用成员变量控制状态
public class DataServerHandler extends SimpleChannelInboundHandler {
private boolean loggedIn;
@Override
public void channelRead0(ChannelHandlerContext ctx, Message message) {
if (message instanceof LoginMessage) {
authenticate((LoginMessage) message);
loggedIn = true;
} else (message instanceof GetDataMessage) {
if (loggedIn) {
ctx.writeAndFlush(fetchSecret((GetDataMessage) message));
} else {
fail();
}
}
}
...
}
因为处理程序实例具有专用于一个连接的状态变量,所以您必须为每个新通道创建一个新的处理程序实例
public class DataServerInitializer extends ChannelInitializer {
@Override
public void initChannel(Channel channel) {
channel.pipeline().addLast("handler", new DataServerHandler());
}
}
2. 使用ChannelHandlerContext提供的AttributeKey
当不想创建许多处理器的实例时,用可以使用ChannelHandlerContext提供的AttributeKey来存储程序的状态信息
@Sharable
public class DataServerHandler extends SimpleChannelInboundHandler {
private final AttributeKey auth =
AttributeKey.valueOf("auth");
@Override
public void channelRead(ChannelHandlerContext ctx, Message message) {
Attribute attr = ctx.attr(auth);
if (message instanceof LoginMessage) {
authenticate((LoginMessage) o);
attr.set(true);
} else (message instanceof GetDataMessage) {
if (Boolean.TRUE.equals(attr.get())) {
ctx.writeAndFlush(fetchSecret((GetDataMessage) o));
} else {
fail();
}
}
}
...
}
只需要一个处理器的实例即可
public class DataServerInitializer extends ChannelInitializer {
private static final DataServerHandler SHARED = new DataServerHandler();
@Override
public void initChannel(Channel channel) {
channel.pipeline().addLast("handler", SHARED);
}
}
要注意这些ChannelHandler的线程安全性
@Sharable注解
提供此注释是为了文档目的,就像JCIP注释一样。实际上是否创建多个实例取决于上面的两种写法
如果ChannelHandler使用@Sharable注解进行标注,则表示可以只创建一次该处理程器的实例,然后将其多次添加到一个或多个ChannelPipelines中
如果未指定此注释,则每次将其添加到管道时都必须创建一个新的处理程序实例,因为它具有未共享的状态,例如成员变量。
其他
ChannelOption
ChannelOption允许以类型安全的方式配置ChannelConfig。 支持哪个ChannelOption取决于ChannelConfig的实际实现,并且可能取决于其所属传输的性质。
ChannelConfig
通道的一组配置属性
请向下转换为更特定的配置类型,例如SocketChannelConfig或使用setOptions(Map)设置特定于传输的属性:
Channel ch = ...;
SocketChannelConfig cfg = (SocketChannelConfig) ch.getConfig();
cfg.setTcpNoDelay(false);
Option map
选项map 属性是动态只写属性,它允许配置Channel而不向下转换其关联的ChannelConfig。要更新选项map,请调用setOptions(Map)。
所有ChannelConfig都具有以下选项:
名称 | 关联的setter方法 |
---|---|
ChannelOption.CONNECT_TIMEOUT_MILLIS | setConnectTimeoutMillis(int) |
ChannelOption.WRITE_SPIN_COUNT | setWriteSpinCount(int) |
ChannelOption.WRITE_BUFFER_WATER_MARK | setWriteBufferWaterMark(WriteBufferWaterMark) |
ChannelOption.ALLOCATOR | setAllocator(ByteBufAllocator) |
ChannelOption.AUTO_READ | setAutoRead(boolean) |
SocketChannelConfig
可用选项
除了ChannelConfig提供的选项外,SocketChannelConfig允许在选项映射中使用以下选项:
名称 | 关联的setter方法 |
---|---|
ChannelOption.SO_KEEPALIVE | setKeepAlive(boolean) |
ChannelOption.SO_REUSEADDR | setReuseAddress(boolean) |
ChannelOption.SO_LINGER | setSoLinger(int) |
ChannelOption.TCP_NODELAY | setTcpNoDelay(boolean) |
ChannelOption.SO_RCVBUF | setReceiveBufferSize(int) |
ChannelOption.SO_SNDBUF | setSendBufferSize(int) |
ChannelOption.IP_TOS | setTrafficClass(int) |
ChannelOption.ALLOW_HALF_CLOSURE | setAllowHalfClosure(boolean) |
主动释放对象
这里主要指的是ByteBuf
ByteBuf是一个引用计数对象(ReferenceCounted),必须通过该release()方法显式释放它。请记住,释放任何传递给处理程序的引用计数对象是处理程序的责任。通常,channelRead()处理程序方法的实现如下:
@Override
public void channelRead(ChannelHandlerContext ctx, Object msg) {
try {
// Do something with msg
} finally {
ReferenceCountUtil.release(msg);
}
}
读数据
从字节流到数据包(碎片化问题)
在基于流的传输(例如TCP / IP)中,将接收到的数据存储到套接字接收缓冲区中。基于流的传输的缓冲区不是数据包队列而是字节队列。这意味着,即使您将两个消息作为两个独立的数据包发送,操作系统也不会将它们视为两个消息,而只是一堆字节。因此,不能保证你读到的内容与远程对等方写的完全一样。
例如,让我们假设操作系统的TCP/IP堆栈已收到三个数据包:
【ABC】【DEF】【GHI】
由于是基于流的传输协议,因此很有可能在你的应用程序中以以下分段形式读取它们:
【AB】【CDEFG】【H】【I】
因此,无论是服务器端还是客户端,接收方都应将接收到的数据整理到一个或多个有意义的帧中,以使应用程序逻辑易于理解。在上面的示例中,接收到的数据应采用以下格式:
【ABC】【DEF】【GHI】
处理方案一
创建一个内部累积缓冲区,然后等待直到所有的字节都被接收到内部缓冲区中为止
package io.netty.example.time;
import java.util.Date;
public class TimeClientHandler extends ChannelInboundHandlerAdapter {
private ByteBuf buf;
@Override
public void handlerAdded(ChannelHandlerContext ctx) {
buf = ctx.alloc().buffer(4); // (1)
}
@Override
public void handlerRemoved(ChannelHandlerContext ctx) {
buf.release(); // (1)
buf = null;
}
@Override
public void channelRead(ChannelHandlerContext ctx, Object msg) {
ByteBuf m = (ByteBuf) msg;
buf.writeBytes(m); // (2)
m.release();
if (buf.readableBytes() >= 4) { // (3)
long currentTimeMillis = (buf.readUnsignedInt() - 2208988800L) * 1000L;
System.out.println(new Date(currentTimeMillis));
ctx.close();
}
}
@Override
public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) {
cause.printStackTrace();
ctx.close();
}
}
- 一个ChannelHandler有两个生命周期侦听器方法:handlerAdded()和handlerRemoved()。可以执行任意(取消)初始化任务,只要它不会长时间阻塞即可。
- 应将所有接收到的数据累加到中buf
- 然后,处理程序必须检查是否buf有足够的数据(在此示例中为4个字节),然后继续进行实际的业务逻辑。否则,Netty将channelRead()在有更多数据到达时再次调用该方法,最终将累加所有4个字节。
处理方案二
添加多个ChannelHandler到ChannelPipeline,拆分一个ChannelHandler成多个,使其模块化减少应用程序的复杂性。
使用编码解码器
package io.netty.example.time;
public class TimeDecoder extends ByteToMessageDecoder { // (1)
@Override
protected void decode(ChannelHandlerContext ctx, ByteBuf in, List
- ByteToMessageDecoder是一个实现ChannelInboundHandler,可以轻松处理碎片问题。
- ByteToMessageDecoderdecode()每当接收到新数据时,都使用内部维护的累积缓冲区调用该方法。
- decode()可以决定out不向累积缓冲区中没有足够数据的位置添加任何内容。收到更多数据时ByteToMessageDecoder将decode()再次调用。
- 如果decode()将对象添加到out,则表示解码器成功解码了一条消息。ByteToMessageDecoder将丢弃累积缓冲区的读取部分。请记住,您不需要解码多条消息。ByteToMessageDecoder会一直调用该decode()方法,直到该方法不添加任何内容out。
累积缓冲区有两种实现
- MERGE_CUMULATOR
通过使用内存副本,将它们合并到一个ByteBuf中来累积ByteBufs。 - COMPOSITE_CUMULATOR
通过将bytebuf添加到CompositeByteBuf中来累积bytebuf,因此尽可能不进行内存复制。注意CompositeByteBuf使用了一个更复杂的索引实现,所以取决于你的用例和解码器实现,这可能比仅仅使用merge_accumulator要慢。
或者使用重复解码器 ReplayingDecoder
ByteToMessageDecoder的变体,使得能够在阻塞I/O范例中实现非阻塞解码器。
ReplayingDecoder您可以像已收到所有必需字节一样实现decode()和decodeLast()方法,而不用检查所需字节的可用性。
public class TimeDecoder extends ReplayingDecoder {
@Override
protected void decode(
ChannelHandlerContext ctx, ByteBuf in, List
ReplayingDecoder通过一个特殊的ByteBuf 实现,Error当缓冲区中没有足够的数据时,该实现将抛出某种类型的实现。在上面的例子中只是假设调用时缓冲区中将有4个或更多字节。如果缓冲区中确实有4个字节,它将按预期返回整数标头。否则将引发Error。如果ReplayingDecoder捕获到 Error,则它将readerIndex把缓冲区的内容倒回到“初始”位置(即缓冲区的开头),并decode(..)在缓冲区中接收到更多数据时再次调用该方法。
详见:https://netty.io/4.1/api/io/netty/handler/codec/ReplayingDecoder.html
此外,Netty提供了开箱即用的解码器,使您能够非常轻松地实现大多数协议
- io.netty.example.factorial 对于二进制协议
- io.netty.example.telnet 用于基于文本行的协议
用POJO代替ByteBuf
在handler中将字节流转成对象,然后在调用链中传递,会使我们开发程序变得更方便
经过解码器,将字节流转成对象之后再out出去,在调用链后面的Handler中就可以直接取到对象了
如:
解码器
@Override
protected void decode(ChannelHandlerContext ctx, ByteBuf in, List
handler
@Override
public void channelRead(ChannelHandlerContext ctx, Object msg) {
UnixTime m = (UnixTime) msg;
System.out.println(m);
ctx.close();
}
写数据
通过ChannelHandlerContext的write方法异步发送应答消息个客户端
数据不直接写入SocketChannel,而是写入待发送数据的缓存区中
ChannelHandlerContext的flush方法将队列中的消息写入到SockChannel中
优雅关闭
原理同线程池的关闭
channel.closeFuture().sync();
关闭所有事件循环以终止所有线程
bossGroup.shutdownGracefully();
workerGroup.shutdownGracefully();
耗时任务处理
bossGroup用于来接受连接,workGroup用于处理业务逻辑和IO操作,如果在handler中执行的业务逻辑特别慢会阻塞IO操作
处理方法
一、在hander中启动新的线程来执行耗时操作
二、告诉netty不要用之前定义的workGroup 来执行某些hander
// 事件处理线程
EventExecutorGroup eventExecutorGroup = new DefaultEventExecutorGroup(16);
ServerBootstrap b = new ServerBootstrap();
b.group(bossGroup, workerGroup)
.channel(NioServerSocketChannel.class)
.childHandler(new ChannelInitializer() {
@Override
public void initChannel(SocketChannel ch) throws Exception {
ChannelPipeline p = ch.pipeline();
p.addLast(new StringDecoder());
p.addLast(new StringEncoder());
// 如果你的业务逻辑是完全异步的,或者完成得非常快,那么就不需要这样做
// 需要指定一个EventExecutorGroup,将用于执行ChannelHandler中的方法
p.addLast(eventExecutorGroup, "String Echo", new StringEchoHandler());
}
});
工具类
...
...
大部分都是代码中的注释翻译过来的,没写完,有空再补充吧!
常用功能
心跳
//心跳检测,6分钟无心跳,触发关闭
public void initChannel(SocketChannel ch) throws Exception {
......
pipeline.addLast( new IdleStateHandler( 6, 0, 0, TimeUnit.MINUTES ) );
......
}
//6分钟没有读取到消息,会触发:userEventTriggered 方法
XxxxHandler
@Override
public void userEventTriggered(ChannelHandlerContext ctx, Object evt) throws Exception {
if (evt instanceof IdleStateEvent) {
IdleStateEvent event = (IdleStateEvent) evt;
if (event.state() == IdleState.READER_IDLE) {
logger.warn("到达指定时间间隔没有收到心跳,关闭连接:{}", ctx.channel().remoteAddress());
ctx.fireUserEventTriggered(evt);
ctx.close();
}
} else {
super.userEventTriggered(ctx, evt);
}
}