1.Netty源码解析 -- FastThreadLocal与HashedWheelTimer
2.Netty基础篇2-Netty核心模块组件
3.Netty源码-一分钟掌握4种tcp粘包解决方案
Netty源码解析 -- FastThreadLocal与HashedWheelTimer
Netty源码分析系列文章接近尾声,码下本文深入解析FastThreadLocal与HashedWheelTimer。码下基于Netty 4.1.版本。码下 FastThreadLocal简介: FastThreadLocal与FastThreadLocalThread协同工作。码下FastThreadLocalThread继承自Thread类,码下内部封装一个InternalThreadLocalMap,码下uboot源码在线阅读该map只能用于当前线程,码下存放了所有FastThreadLocal对应的码下值。每个FastThreadLocal拥有一个index,码下用于定位InternalThreadLocalMap中的码下值。获取值时,码下首先检查当前线程是码下否为FastThreadLocalThread,如果不是码下,则从UnpaddedInternalThreadLocalMap.slowThreadLocalMap获取InternalThreadLocalMap,码下这实际上回退到使用ThreadLocal。码下 FastThreadLocal获取值步骤: #1 获取当前线程的InternalThreadLocalMap,如果是FastThreadLocalThread则直接获取,否则通过UnpaddedInternalThreadLocalMap.slowThreadLocalMap获取。#2 通过每个FastThreadLocal的index,获取InternalThreadLocalMap中的值。
#3 若找不到值,则调用initialize方法构建新对象。
FastThreadLocal特点: FastThreadLocal无需使用hash算法,通过下标直接获取值,复杂度为log(1),宝塔怎么下载源码性能非常高效。 HashedWheelTimer介绍: HashedWheelTimer是Netty提供的时间轮调度器,用于高效管理各种延时任务。时间轮是一种批量化任务调度模型,能够充分利用线程资源。简单说,就是将任务按照时间间隔存放在环形队列中,执行线程定时执行队列中的任务。 例如,环形队列有个格子,执行线程每秒移动一个格子,则每轮可存放1分钟内的任务。任务执行逻辑如下:给定两个任务task1(秒后执行)、task2(2分秒后执行),当前执行线程位于第6格子。那么,task1将放到+6=格,轮数为0;task2放到+6=格,轮数为2。执行线程将执行当前格子轮数为0的任务,并将其他任务轮数减1。 HashedWheelTimer的缺点: 时间轮调度器的时间精度受限于执行线程的移动速度。例如,每秒移动一个格子,驱动级按键源码则调度精度小于一秒的任务无法准时调用。 HashedWheelTimer关键字段: 添加延迟任务时,使用HashedWheelTimer#newTimeout方法,如果HashedWheelTimer未启动,则启动HashedWheelTimer。启动后,构建HashedWheelTimeout并添加到timeouts集合。 HashedWheelTimer运行流程: 启动后阻塞HashedWheelTimer线程,直到Worker线程启动完成。计算下一格子开始执行的时间,然后睡眠到下次格子开始执行时间。获取tick对应的格子索引,处理已到期任务,移动到下一个格子。当HashedWheelTimer停止时,取消任务并停止时间轮。 HashedWheelTimer性能比较: HashedWheelTimer新增任务复杂度为O(1),优于使用堆维护任务的ScheduledExecutorService,适合处理大量任务。然而,当任务较少或无任务时,HashedWheelTimer的执行线程需要不断移动,造成性能消耗。另外,alsa驱动源码分析使用同一个线程调用和执行任务,某些任务执行时间过久会影响后续任务执行。为避免这种情况,可在任务中使用额外线程执行逻辑。如果任务过多,可能导致任务长期滞留在timeouts中而不能及时执行。 本文深入剖析FastThreadLocal与HashedWheelTimer的实现细节,旨在提供全面的技术洞察与实战经验。希望对您理解Netty源码与时间轮调度器有帮助。关注微信公众号,获取更多Netty源码解析与技术分享。Netty基础篇2-Netty核心模块组件
欢迎大家关注?github.com/hsfxuebao?,希望对大家有所帮助,要是觉得可以的话麻烦给点一下Star哈1. Bootstrap 和 ServerBootstrapBootstrap 意思是引导,一个 Netty 应用通常由一个 Bootstrap 开始,主要作用是配置整个 Netty 程序,串联各个组件,Netty 中 Bootstrap 类是客户端程序的启动引导类,ServerBootstrap 是服务端启动引导类
常见的方法有:
public?ServerBootstrap?group(EventLoopGroup?parentGroup,?EventLoopGroup?childGroup),该方法用于服务器端,用来设置两个?EventLooppublic?B?group(EventLoopGroup?group)?,该方法用于客户端,用来设置一个?EventLooppublic?B?channel(Class<?extends?C>?channelClass),该方法用来设置一个服务器端的葫芦鱼 暗堡源码通道实现public?<T>?B?option(ChannelOption<T>?option,?T?value),用来给?ServerChannel?添加配置public?<T>?ServerBootstrap?childOption(ChannelOption<T>?childOption,?T?value),用来给接收到的通道添加配置public?ServerBootstrap?childHandler(ChannelHandler?childHandler),该方法用来设置业务处理类(自定义的?handler)public?ChannelFuture?bind(int?inetPort)?,该方法用于服务器端,用来设置占用的端口号public?ChannelFuture?connect(String?inetHost,?int?inetPort)?,该方法用于客户端,用来连接服务器端2. Future 和 ChannelFuturesNetty 中所有的 IO 操作都是异步的,不能立刻得知消息是否被正确处理。但是可以过一会等它执行完成或者直接注册一个监听,具体的实现就是通过 Future 和 ChannelFutures,他们可以注册一个监听,当操作执行成功或失败时监听会自动触发注册的监听事件
常见的方法有:
Channel?channel(),返回当前正在进行?IO?操作的通道ChannelFuture?sync(),等待异步操作执行完毕3. ChannelNetty 网络通信的组件,能够用于执行网络 I/O 操作。
通过Channel 可获得当前网络连接的通道的状态
通过Channel 可获得 网络连接的配置参数 (例如接收缓冲区大小)
Channel 提供异步的网络 I/O 操作(如建立连接,读写,绑定端口),异步调用意味着任何 I/O 调用都将立即返回,并且不保证在调用结束时所请求的 I/O 操作已完成
调用立即返回一个 ChannelFuture 实例,通过注册监听器到 ChannelFuture 上,可以 I/O 操作成功、失败或取消时回调通知调用方
支持关联 I/O 操作与对应的处理程序
不同协议、不同的阻塞类型的连接都有不同的 Channel 类型与之对应,常用的 Channel 类型:
NioSocketChannel,异步的客户端 TCP Socket 连接。
NioServerSocketChannel,异步的服务器端 TCP Socket 连接。
NioDatagramChannel,异步的 UDP 连接。
NioSctpChannel,异步的客户端 Sctp 连接。
NioSctpServerChannel,异步的 Sctp 服务器端连接,这些通道涵盖了 UDP 和 TCP 网络 IO 以及文件 IO。
4. SelectorNetty 基于 Selector 对象实现 I/O 多路复用,通过 Selector 一个线程可以监听多个连接的 Channel 事件。
当向一个 Selector 中注册 Channel 后,Selector 内部的机制就可以自动不断地查询(Select) 这些注册的 Channel 是否有已就绪的 I/O 事件(例如可读,可写,网络连接完成等),这样程序就可以很简单地使用一个线程高效地管理多个 Channel
5. ChannelHandler 及其实现类ChannelHandler 是一个接口,处理 I/O 事件或拦截 I/O 操作,并将其转发到其 ChannelPipeline(业务处理链)中的下一个处理程序。
ChannelHandler 本身并没有提供很多方法,因为这个接口有许多的方法需要实现,方便使用期间,可以继承它的子类。ChannelHandler 及其实现类一览图(后)
ChannelInboundHandler 用于处理入站 I/O 事件。
ChannelOutboundHandler 用于处理出站 I/O 操作。
//适配器
ChannelInboundHandlerAdapter 用于处理入站 I/O 事件。
ChannelOutboundHandlerAdapter 用于处理出站 I/O 操作。
ChannelDuplexHandler 用于处理入站和出站事件。
我们经常需要自定义一个 Handler 类去继承 ChannelInboundHandlerAdapter,然后通过重写相应方法实现业务逻辑,我们接下来看看一般都需要重写哪些方法
public?class?ChannelInboundHandlerAdapter?extends?ChannelHandlerAdapter?implements?ChannelInboundHandler?{ ?@Skip?@Override?public?void?channelRegistered(ChannelHandlerContext?ctx)?throws?Exception?{ ?ctx.fireChannelRegistered();?}?@Skip?@Override?public?void?channelUnregistered(ChannelHandlerContext?ctx)?throws?Exception?{ ?ctx.fireChannelUnregistered();?}?//?通道就绪事件?@Skip?@Override?public?void?channelActive(ChannelHandlerContext?ctx)?throws?Exception?{ ?ctx.fireChannelActive();?}?@Skip?@Override?public?void?channelInactive(ChannelHandlerContext?ctx)?throws?Exception?{ ?ctx.fireChannelInactive();?}?@Skip?@Override?//?通道读取数据事件?public?void?channelRead(ChannelHandlerContext?ctx,?Object?msg)?throws?Exception?{ ?ctx.fireChannelRead(msg);?}?@Skip?@Override?//?数据读取完毕事件?public?void?channelReadComplete(ChannelHandlerContext?ctx)?throws?Exception?{ ?ctx.fireChannelReadComplete();?}?@Skip?@Override?public?void?userEventTriggered(ChannelHandlerContext?ctx,?Object?evt)?throws?Exception?{ ?ctx.fireUserEventTriggered(evt);?}?@Skip?@Override?public?void?channelWritabilityChanged(ChannelHandlerContext?ctx)?throws?Exception?{ ?ctx.fireChannelWritabilityChanged();?}?@Skip?@Override?@SuppressWarnings("deprecation")?//?通道发生异常事件?public?void?exceptionCaught(ChannelHandlerContext?ctx,?Throwable?cause)?throws?Exception?{ ?ctx.fireExceptionCaught(cause);?}}6. Pipeline 和ChannelPipelineChannelPipeline 是一个重点:
ChannelPipeline 是一个 Handler 的集合,它负责处理和拦截 inbound 或者 outbound 的事件和操作,相当于一个贯穿 Netty 的链。(也可以这样理解:ChannelPipeline 是 保存 ChannelHandler 的 List,用于处理或拦截 Channel 的入站事件和出站操作)
ChannelPipeline 实现了一种高级形式的拦截过滤器模式,使用户可以完全控制事件的处理方式,以及 Channel 中各个的 ChannelHandler 如何相互交互
在 Netty 中每个 Channel 都有且仅有一个 ChannelPipeline 与之对应,它们的组成关系如下
一个 Channel 包含了一个 ChannelPipeline,而 ChannelPipeline 中又维护了一个由 ChannelHandlerContext 组成的双向链表,并且每个 ChannelHandlerContext 中又关联着一个 ChannelHandler
入站事件和出站事件在一个双向链表中,入站事件会从链表 head 往后传递到最后一个入站的 handler,出站事件会从链表 tail 往前传递到最前一个出站的 handler,两种类型的 handler 互不干扰
常用方法
?ChannelPipeline?addFirst(ChannelHandler...?handlers),把一个业务处理类(handler)添加到链中的第一个位置?ChannelPipeline?addLast(ChannelHandler...?handlers),把一个业务处理类(handler)添加到链中的最后一个位置7. ChannelHandlerContext保存 Channel 相关的所有上下文信息,同时关联一个 ChannelHandler 对象,即ChannelHandlerContext 中 包 含 一 个 具 体 的 事 件 处 理 器 ChannelHandler , 同 时ChannelHandlerContext 中也绑定了对应的 pipeline 和 Channel 的信息,方便对 ChannelHandler进行调用.
常用方法:
ChannelFuture?close(),关闭通道ChannelOutboundInvoker?flush(),刷新ChannelFuture?writeAndFlush(Object?msg)?,?将?数?据?写?到?ChannelPipeline?中?当?前ChannelHandler?的下一个?ChannelHandler?开始处理(出站)8. ChannelOptionNetty 在创建 Channel 实例后,一般都需要设置 ChannelOption 参数。 ChannelOption 参数如下:
ChannelOption.SO_BACKLOG: 对应 TCP/IP 协议 listen 函数中的 backlog 参数,用来初始化服务器可连接队列大小。服务端处理客户端连接请求是顺序处理的,所以同一时间只能处理一个客户端连接。多个客户端来的时候,服务端将不能处理的客户端连接请求放在队列中等待处理,backlog 参数指定了队列的大小。
ChannelOption.SO_KEEPALIVE : 一直保持连接活动状态
9. EventLoopGroup 和实现类NioEventLoopGroupEventLoopGroup 是一组 EventLoop 的抽象,Netty 为了更好的利用多核 CPU 资源,一般会有多个 EventLoop 同时工作,每个 EventLoop 维护着一个 Selector 实例。
EventLoopGroup 提供 next 接口,可以从组里面按照一定规则获取其中一个 EventLoop来处理任务。在 Netty 服务器端编程中,我们一般都需要提供两个 EventLoopGroup,例如:BossEventLoopGroup 和 WorkerEventLoopGroup。
通常一个服务端口即一个 ServerSocketChannel对应一个Selector 和一个EventLoop线程。BossEventLoop 负责接收客户端的连接并将 SocketChannel 交给 WorkerEventLoopGroup 来进行 IO 处理,如下图所示:
BossEventLoopGroup 通常是一个单线程的 EventLoop,EventLoop 维护着一个注册了ServerSocketChannel 的 Selector 实例BossEventLoop 不断轮询 Selector 将连接事件分离出来
通常是 OP_ACCEPT 事件,然后将接收到的 SocketChannel 交给 WorkerEventLoopGroup
WorkerEventLoopGroup 会由 next 选择其中一个 EventLoop来将这个 SocketChannel 注册到其维护的 Selector 并对其后续的 IO 事件进行处理
常用方法
?public?NioEventLoopGroup(),构造方法?public?Future<?>?shutdownGracefully(),断开连接,关闭线程. Unpooled类Netty 提供一个专门用来操作缓冲区(即Netty的数据容器)的工具类
常用方法如下所示
?//通过给定的数据和字符编码返回一个?ByteBuf?对象(类似于?NIO?中的?ByteBuffer?但有区别)?public?static?ByteBuf?copiedBuffer(CharSequence?string,?Charset?charset)举例说明Unpooled 获取 Netty的数据容器ByteBuf 的基本使用 案例演示
案例1:
public?class?NettyByteBuf?{ ?public?static?void?main(String[]?args)?{ ?//创建一个ByteBuf?//说明?//1.?创建?对象,该对象包含一个数组arr?,?是一个byte[]?//2.?在netty?的buffer中,不需要使用flip?进行反转?//底层维护了?readerindex?和?writerIndex?//3.?通过?readerindex?和?writerIndex?和?capacity,?将buffer分成三个区域?//?0---readerindex?已经读取的区域?//?readerindex---writerIndex?,?可读的区域?//?writerIndex?--?capacity,?可写的区域?ByteBuf?buffer?=?Unpooled.buffer(5);?for?(int?i?=?0;?i?<?5;?i++)?{ ?buffer.writeByte(i);?}?System.out.println("capacity="?+?buffer.capacity());?//?//输出//for?(int?i?=?0;?i?<?buffer.capacity();?i++)?{ //System.out.println(buffer.getByte(i));//}?for?(int?i?=?0;?i?<?buffer.capacity();?i++)?{ ?System.out.println(buffer.readByte());?}?System.out.println("执行完毕");?}}执行结果为:
capacity=执行完毕案例2:
public?class?NettyByteBuf?{ ?public?static?void?main(String[]?args)?{ ?//创建ByteBuf?ByteBuf?byteBuf?=?Unpooled.copiedBuffer("hello,world!",?Charset.forName("utf-8"));?//使用相关的方法?if?(byteBuf.hasArray())?{ ?//?true?byte[]?content?=?byteBuf.array();?//将?content?转成字符串?System.out.println(new?String(content,?Charset.forName("utf-8")));?System.out.println("byteBuf="?+?byteBuf);?System.out.println(byteBuf.arrayOffset());?//?0?System.out.println(byteBuf.readerIndex());?//?0?System.out.println(byteBuf.writerIndex());?//??System.out.println(byteBuf.capacity());?//??//System.out.println(byteBuf.readByte());?//?System.out.println(byteBuf.getByte(0));?//??int?len?=?byteBuf.readableBytes();?//可读的字节数??System.out.println("len="?+?len);?//使用for取出各个字节?for?(int?i?=?0;?i?<?len;?i++)?{ ?System.out.println((char)?byteBuf.getByte(i));?}?//按照某个范围读取?System.out.println(byteBuf.getCharSequence(0,?4,?Charset.forName("utf-8")));?System.out.println(byteBuf.getCharSequence(4,?6,?Charset.forName("utf-8")));?}?}}执行结果为:
Channel?channel(),返回当前正在进行?IO?操作的通道ChannelFuture?sync(),等待异步操作执行完毕0参考文档Netty学习和源码分析github地址Netty从入门到精通视频教程(B站) Netty权威指南 第二版
原文:/post/
Netty源码-一分钟掌握4种tcp粘包解决方案
TCP报文的传输过程涉及内核中recv缓冲区和send缓冲区。发送端,数据先至send缓冲区,经Nagle算法判断是否立即发送。接收端,数据先入recv缓冲区,再由内核拷贝至用户空间。
粘包现象源于无明确边界。解决此问题的关键在于界定报文的分界。Netty提供了四种方案来应对TCP粘包问题。
Netty粘包解决方案基于容器存储报文,待所有报文收集后进行拆包处理。容器与拆包处理分别在ByteToMessageDecoder类的cumulation与decode抽象方法中实现。
FixedLengthFrameDecoder是通过设置固定长度参数来识别报文,非报文长度,避免误判。
LineBasedFrameDecoder以换行符作为分界符,确保准确分割报文,避免将多个报文合并。
LengthFieldPrepender通过设置长度字段长度,实现简单编码,为后续解码提供依据。
LengthFieldBasedFrameDecoder则是一种万能解码器,能够解密任意格式的编码,灵活性高。
实现过程中涉及的参数包括:长度字段的起始位置offset、长度字段占的字节数lengthFieldLength、长度的调整lengthAdjustment以及解码后需跳过的字节数initialBytesToStrip。
在实际应用中,为自定义协议,需在服务器与客户端分别实现编码与解码逻辑。服务器端负责发送经过编码的协议数据,客户端则接收并解码,以还原协议信息。
2024-11-27 15:27
2024-11-27 14:39
2024-11-27 14:29
2024-11-27 14:19
2024-11-27 14:13
2024-11-27 14:12
2024-11-27 14:05
2024-11-27 13:30