1.Netty源码解析 -- FastThreadLocal与HashedWheelTimer
2.netty源码解析(三十五)---Netty启动3 成功bind 等待连接
3.Java的码讲并行世界-Netty中线程模型源码讲解-续集Handler、Channel
4.Netty源码-Sharable注解,码讲我猜你理解错了!码讲
5.Netty源码-Reactor线程模型之NioEventLoopGroup研究
6.Netty源码-一分钟掌握4种tcp粘包解决方案
Netty源码解析 -- FastThreadLocal与HashedWheelTimer
Netty源码分析系列文章接近尾声,码讲本文深入解析FastThreadLocal与HashedWheelTimer。码讲基于Netty 4.1.版本。码讲tiktok源码群控 FastThreadLocal简介: FastThreadLocal与FastThreadLocalThread协同工作。码讲FastThreadLocalThread继承自Thread类,码讲内部封装一个InternalThreadLocalMap,码讲该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的执行线程需要不断移动,造成性能消耗。另外,使用同一个线程调用和执行任务,某些任务执行时间过久会影响后续任务执行。为避免这种情况,可在任务中使用额外线程执行逻辑。如果任务过多,可能导致任务长期滞留在timeouts中而不能及时执行。 本文深入剖析FastThreadLocal与HashedWheelTimer的实现细节,旨在提供全面的技术洞察与实战经验。希望对您理解Netty源码与时间轮调度器有帮助。抄开源源码关注微信公众号,获取更多Netty源码解析与技术分享。netty源码解析(三十五)---Netty启动3 成功bind 等待连接
Netty启动过程中的bind操作在AbstractBootstrap类中启动,由于异步特性,ChannelFuture在register0方法后交给事件执行器处理,此时isDone返回为false。在sync同步等待时,主线程会阻塞在PendingRegistrationPromise上,等待绑定完成。
PendingRegistrationPromise的创建和ChannelFuture的监听器是为了在绑定成功后执行后续操作。当bind0方法中的safeSetSuccess成功后,会触发监听器,进一步调用AbstractChannel的bind方法。这个过程会通过DefaultChannelPipeline的tail处理,最后在AbstractChannelHandlerContext的HeadContext中,调用handler的bind方法,其中HeadContext的unsafe.bind方法会调用到NioServerSocketChannel的unsafe的dobind方法。
在NioServerSocketChannel中,真正的绑定操作是调用原生的jdk的bind方法。当绑定成功后,AbstractChannel的dobind方法会设置promise为success,从而唤醒主线程,继续执行后续代码。至此,Netty的bind操作等待连接的到来。
总结整个流程:Bootstrap创建Promise等待,然后通过管道传递到AbstractChannel,通过HeadContext调用unsafe.bind,百万流量站源码最终在NioServerSocketChannel中调用原生bind,主线程等待并处理bind结果。当连接到来时,整个绑定过程结束。
Java的并行世界-Netty中线程模型源码讲解-续集Handler、Channel
Netty 的核心组件 ChannelHandler 在网络应用中扮演着处理入站和出站事件及数据的关键角色。ChannelHandler 的子类负责执行不同类型的事件处理和数据操作,以实现特定的网络业务逻辑。以下是 ChannelHandler 子类的分类及其功能介绍:
首先,特殊类型的Handler,如 ChannelHandlerContext,它连接了处理器与Channel之间的上下文关系,方便数据交互和事件触发。
其次,ChannelInboundHandler 和 ChannelOutboundHandler 分别负责处理入站和出站的数据。ChannelInboundHandlerAdapter 示例如时间服务器,当连接建立时发送时间并断开,而 ChannelOutboundHandlerAdapter 则如客户端发送消息。
ByteToMessageDecoder 和 MessageToByteEncoder 分别负责数据的解码和编码,如基于换行符的文本协议服务器和字符串消息的编码。
ChannelDuplexHandler 如聊天服务器,处理双向通信,例如广播消息。SimpleChannelInboundHandler 提供了便捷的入站事件处理,避免了手动管理消息引用计数。
Channel相关的核心概念是 Channel,它代表了网络连接,隐藏了底层通信方式的细节,支持数据读写和事件监听。Netty 提供了多种Channel子类,如 NioServerSocketChannel 和 EpollServerSocketChannel,用于适应不同应用场景。
在服务器启动时,ChannelInitializer 用于初始化新连接的 ChannelPipeline,配置处理器以执行特定的业务逻辑。Netty 4.1 源码结构提供了学习的入口,后续会分享更详细的注释版源码。
总的来说,通过理解和使用这些 ChannelHandler 和 Channel 的特性,开发者可以构建出功能丰富的网络应用。持续关注,将分享更多源码解析和学习资源。
Netty源码-Sharable注解,我猜你理解错了!
学习目标
理解Sharable注解在Netty中的作用。个人臆想,只要在ChannelHandler上添加了@ChannelHandler.Sharable注解,所有的channel都共享这一个ChannelHandler实例。真是这样的吗?如果你认为所有channel共享一个pipeline,只能说明你对pipeline的初始化不理解。你臆想完全错误!!!
Sharable注解介绍
在深入探讨之前,建议阅读《Netty源码-ChannelPipeline的剖析》。阅读后,问题迎刃而解。同时,你可能还会疑惑Sharable注解的用途。它的主要目的是在pipeline之间共享信息,例如统计连接数、限流、白名单等。
如何使用Sharable注解
源码中有明确说明,你可以在ChannelHandler的成员变量上使用@ChannelHandler.Sharable注解,表示这个变量的实例可以被所有pipeline共享。如果不想共享,就每次创建新实例。通过代码示例可以直观理解共享实例和每次创建新实例的区别。
使用场景
Sharable注解适用于在pipeline之间需要共享数据或状态的场景。例如统计连接数、限流、白名单管理等。
注意事项
使用Sharable注解时,务必考虑线程安全。在多线程环境中,确保共享数据的正确性和一致性。
实战应用-统计当前连接数
通过实践,我们实现了一个简单的统计当前连接数的示例。执行结果如下:
Connected to the target VM, address: '.0.0.1:', transport: 'socket' count:1 InBoundHandler1-channelRead:abc InBoundHandler1-channelRead:asd count:2 InBoundHandler1-channelRead:abc InBoundHandler1-channelRead:asd
Netty源码-Reactor线程模型之NioEventLoopGroup研究
在Netty网络编程中,NioEventLoopGroup作为线程池的核心组件,其作用至关重要。从初始化的逻辑分析来看,NioEventLoopGroup扮演多重角色,不仅提供了线程池相关功能,同时也继承了线程模型的ScheduledExecutorService,ExecutorService和Executor接口,体现其多功能性。
其层次结构显示,NioEventLoopGroup从底层向上层层封装,实现了线程池模型的关键功能。进一步深入分析,NioEventLoopGroup通过继承自MultithreadEventLoopGroup,并在构造函数中执行关键初始化操作,展现了其独特的设计。首先,NioEventLoopGroup在初始化时创建线程工厂,构建线程执行器Executor,如果未提供自定义Executor,将使用DefaultThreadFactory创建FastThreadLocalThread线程执行任务。其次,根据指定数量nThreads创建子线程组,若nThreads未定义或设为0,则默认设置为2倍的CPU线程数。最后,在初始化子线程组时,NioEventLoopGroup通过newChild()方法执行初始化,这一步操作具体实现由NioEventLoop类完成,其初始化参数包括线程选择器chooser,以及其他多个关键参数,确保线程高效运行。
NioEventLoopGroup与Java线程池之间的区别主要体现在其面向特定应用场景的设计上,尤其在事件驱动和非阻塞IO模型的支持方面。Netty通过NioEventLoopGroup实现了更灵活、高效的并发处理机制,使得在处理高并发、高网络流量场景时,性能得到显著提升。
在研究NioEventLoopGroup的过程中,我们深入学习到了设计模式的应用,如单例模式确保了线程选择器的唯一性,工厂模式则负责创建不同类型的线程组。此外,模板设计模式的使用,使得NioEventLoopGroup能够提供高度抽象的初始化逻辑,同时保持了代码的复用性和可扩展性。通过这种设计,Netty不仅优化了资源管理,还提升了系统的整体性能和稳定性。
Netty源码-一分钟掌握4种tcp粘包解决方案
TCP报文的传输过程涉及内核中recv缓冲区和send缓冲区。发送端,数据先至send缓冲区,经Nagle算法判断是否立即发送。接收端,数据先入recv缓冲区,再由内核拷贝至用户空间。
粘包现象源于无明确边界。解决此问题的关键在于界定报文的分界。Netty提供了四种方案来应对TCP粘包问题。
Netty粘包解决方案基于容器存储报文,待所有报文收集后进行拆包处理。容器与拆包处理分别在ByteToMessageDecoder类的cumulation与decode抽象方法中实现。
FixedLengthFrameDecoder是通过设置固定长度参数来识别报文,非报文长度,避免误判。
LineBasedFrameDecoder以换行符作为分界符,确保准确分割报文,避免将多个报文合并。
LengthFieldPrepender通过设置长度字段长度,实现简单编码,为后续解码提供依据。
LengthFieldBasedFrameDecoder则是一种万能解码器,能够解密任意格式的编码,灵活性高。
实现过程中涉及的参数包括:长度字段的起始位置offset、长度字段占的字节数lengthFieldLength、长度的调整lengthAdjustment以及解码后需跳过的字节数initialBytesToStrip。
在实际应用中,为自定义协议,需在服务器与客户端分别实现编码与解码逻辑。服务器端负责发送经过编码的协议数据,客户端则接收并解码,以还原协议信息。