皮皮网

1.Netty源码解析 -- FastThreadLocal与HashedWheelTimer
2.netty源码解析（三十五）---Netty启动3 成功bind 等待连接
3.Netty源码-Reactor线程模型之NioEventLoopGroup研究
4.Netty原理-从NIO开始
5.Netty源码-一分钟掌握4种tcp粘包解决方案

Netty源码解析 -- FastThreadLocal与HashedWheelTimer

       Netty源码分析系列文章接近尾声，码原本文深入解析FastThreadLocal与HashedWheelTimer。码原基于Netty 4.1.版本。码原

       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 若找不到值，溯源码312则调用initialize方法构建新对象。

       FastThreadLocal特点：

       FastThreadLocal无需使用hash算法，通过下标直接获取值，复杂度为log(1)，性能非常高效。

       HashedWheelTimer介绍：

       HashedWheelTimer是Netty提供的时间轮调度器，用于高效管理各种延时任务。时间轮是一种批量化任务调度模型，能够充分利用线程资源。简单说，就是将任务按照时间间隔存放在环形队列中，执行线程定时执行队列中的任务。

       例如，环形队列有个格子，执行线程每秒移动一个格子，则每轮可存放1分钟内的任务。任务执行逻辑如下：给定两个任务task1（秒后执行）、task2（2分秒后执行），当前执行线程位于第6格子。那么，crd生成源码task1将放到+6=格，轮数为0；task2放到+6=格，轮数为2。执行线程将执行当前格子轮数为0的任务，并将其他任务轮数减1。

       HashedWheelTimer的缺点：

       时间轮调度器的时间精度受限于执行线程的移动速度。例如，每秒移动一个格子，则调度精度小于一秒的任务无法准时调用。

       HashedWheelTimer关键字段：

       添加延迟任务时，使用HashedWheelTimer#newTimeout方法，如果HashedWheelTimer未启动，则启动HashedWheelTimer。启动后，构建HashedWheelTimeout并添加到timeouts集合。

       HashedWheelTimer运行流程：

       启动后阻塞HashedWheelTimer线程，直到Worker线程启动完成。计算下一格子开始执行的时间，然后睡眠到下次格子开始执行时间。获取tick对应的atis指南源码格子索引，处理已到期任务，移动到下一个格子。当HashedWheelTimer停止时，取消任务并停止时间轮。

       HashedWheelTimer性能比较：

       HashedWheelTimer新增任务复杂度为O(1)，优于使用堆维护任务的ScheduledExecutorService，适合处理大量任务。然而，当任务较少或无任务时，HashedWheelTimer的执行线程需要不断移动，造成性能消耗。另外，使用同一个线程调用和执行任务，某些任务执行时间过久会影响后续任务执行。为避免这种情况，可在任务中使用额外线程执行逻辑。如果任务过多，可能导致任务长期滞留在timeouts中而不能及时执行。

       本文深入剖析FastThreadLocal与HashedWheelTimer的实现细节，旨在提供全面的吉安ios源码技术洞察与实战经验。希望对您理解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结果。当连接到来时，整个绑定过程结束。

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原理-从NIO开始

       Netty是基于NIO的异步通信框架（曾经引入过AIO，后来放弃），故要说Netty原理我们要先从NIO开始。

        NIO 是JAVA在JDK4中引入的同步非阻塞通信模型，在NIO出现之前（JDK4之前）市场上只有一个BIO模型顾名思义BLOCKING IO （同步阻塞通信模型）

        BIO（BLOCKING I/O）：

        BIO 为一个连接 一个线程的模式，当有连接时服务器会开启一个线程来处理请求

        若此请求啥都不想干此时线程会怎么样？

        此线程会进入阻塞模式（BLOCKING）！---啥也不干，干等着zzZZ~

        这种一连接，一线程的模式会造成服务器资源不必要的开销并且在大量连接访问时 服务器会发生什么？车道（线程）不足，车太多--我堵车了

        由此就出现了NIO

        ↓

        NIO（new/NONBLOCKING I/O）:

        NIO为同步非阻塞通信模型，Select（多路复用器）为此模型的核心，实现了多个连接一个线程

        当有客户端连接请求时 此连接请求会被注册至select上，当select检测到此连接有I/O请求时才会打开一个线程去对此I/O请求进行处理-----单线程模型

        这个时候有人问了：这么多操作都在一个线程里，线程忙不过来怎么办？

        此时 由于网络请求、I/O读写、业务操作都在一个线程下，会导致在高并发的情况下存在性能瓶颈 于是乎有人就提出来 将业务操作丢到另一个线程怎么样？

        于是出现了第三种reactor模型-使用线程池进行操作网络请求、IO在一个线程，业务操作在另个一个线程 的业务分离----线程池模型

        从此图中可以看出此时 模型中使用一个线程池来进行网络请求、IO读取

        当读取完成后将业务操作绑定在线程池中另外的线程上-------网络IO与业务操作可以同步进行了！一切都完美了起来！

        但是！事情还没完！！这个时候又有人提出问题：在高并发的时候咋办？会不会有性能瓶颈

        因为网络IO是非常消耗CPU的，当网络请求与网络IO在同个线程中时，造CK的情况下单个线程并不足以支撑起所有的IO操作！因此也形成了在高并发状态下的性能瓶颈

        于是大佬们就想着，如果把IO拆出来让单个线程池去接收网络请求，用另一个线程池来进行IO与业务操作会不会更好

        于是第四种Reactor模型应运而生--主从Reactor多线程模型

        此模型中 mainReactor只用于接收网络请求，而subReactor中为一个线程池，线程池中每个线程上绑定一个select

        当mainReactor接收到请求时（一个描述符） 系统会生成一个新的描述符代表此连接生效，此时mainReactor会将新的描述符通过一个算法在线程池中选定一个线程 将此描述符绑定至此线程池上的select上，由此线程来对请求进行I/O 与业务操作

        从此百万连接高并发不是问题

        写到这 我们是不是想起了Netty的启动过程

        1、声明两个EventLoopGroup一个为boss（mainReactor）一个为worker（subReactor）

        EventLoopGroup（线程池）初始化的时候会生成（懒加载）指定数量的EventLoop（线程）若无指定 则会生成CPU数X2的线程

        2、声明一个启动辅助类Bootstrap并将EventLoopGroup注册到启动辅助类BootStrap上(bootStrap.group)

        接着再给bootstrap指定channel模型等属性，再添加上业务流水线（channelpipeline）并且在pipeline中添加上业务操作handler，（通过channelpipeline可以对传入数据为所欲为）

        3、绑定端口

        Netty启动完成

        这时候可能有人会问了：这和你上面说的reactor？NIO有啥关系？

        这个时候我们要这么看

        ↓

        若我们将boss与worker线程池设置为相同的一个线程池，那么会发生什么事？

        此时关注一下第三个Reactor模型时就会发现 当BOSS=WORKER时候 netty实现的就是第三种Reactor模型 使用线程池模型

        而当boss不等于worker的时候使用的就是第四种 主从多线程模型

        Netty就是基于Reactor模型来对NIO进行了易用化封装，从Netty源码中就可以看出来其实底层还都是NIO的接口

        此次处为自己读源码之后的理解 如有误请指正

        感恩

        反手拿下第一个赞

Netty源码-一分钟掌握4种tcp粘包解决方案

       TCP报文的传输过程涉及内核中recv缓冲区和send缓冲区。发送端，数据先至send缓冲区，经Nagle算法判断是否立即发送。接收端，数据先入recv缓冲区，再由内核拷贝至用户空间。

       粘包现象源于无明确边界。解决此问题的关键在于界定报文的分界。Netty提供了四种方案来应对TCP粘包问题。

       Netty粘包解决方案基于容器存储报文，待所有报文收集后进行拆包处理。容器与拆包处理分别在ByteToMessageDecoder类的cumulation与decode抽象方法中实现。

       FixedLengthFrameDecoder是通过设置固定长度参数来识别报文，非报文长度，避免误判。

       LineBasedFrameDecoder以换行符作为分界符，确保准确分割报文，避免将多个报文合并。

       LengthFieldPrepender通过设置长度字段长度，实现简单编码，为后续解码提供依据。

       LengthFieldBasedFrameDecoder则是一种万能解码器，能够解密任意格式的编码，灵活性高。

       实现过程中涉及的参数包括：长度字段的起始位置offset、长度字段占的字节数lengthFieldLength、长度的调整lengthAdjustment以及解码后需跳过的字节数initialBytesToStrip。

       在实际应用中，为自定义协议，需在服务器与客户端分别实现编码与解码逻辑。服务器端负责发送经过编码的协议数据，客户端则接收并解码，以还原协议信息。