Java的并行世界-Netty中线程模型源码讲解-续集Handler、Channel

       Netty 的核心组件 ChannelHandler 在网络应用中扮演着处理入站和出站事件及数据的关键角色。ChannelHandler 的子类负责执行不同类型的事件处理和数据操作，以实现特定的网络业务逻辑。以下是spring mvc i源码 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原理-从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的接口

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

        感恩

        反手拿下第一个赞

Java编程方法论-Reactor-Netty与Spring WebFlux解读 之 第4章 Reactor Netty针对EventLoopGroup的封装

       Java编程方法论-Reactor-Netty与Spring WebFlux解读整体简介第4章 Reactor Netty针对EventLoopGroup的封装

       在功能使用层面，为对应如HttpServer、TcpServer等类中的Create方法，Reactor Netty设计了EventLoopGroup的Create方法，以适应响应式环境，实现功能增强。此章节将深入解析这一过程。

       针对EventLoopGroup的接口设计采用装饰器模式，引入reactor.netty.resources.LoopResources接口，它继承自Disposable接口，php计时系统源码EventLoopGroup作为其实现类的一部分。默认的Create方法返回此接口的默认实现。

       在顶层接口内，设置了默认方法，用于获取客户端或服务端的EventLoopGroup。对Netty中的workerGroup和bossGroup进行设定。确认EventLoopGroup是否可关闭，并提供了相应的daemon方法。

       EventLoopGroup继承EventExecutorGroup，关闭操作通过调用EventExecutorGroup的shutdownGracefully方法实现，包装为Mono.defer，订阅执行关闭逻辑。顶层接口中定义了disposeLater方法，用于封装这一逻辑，实现类中重写。

       获取EventLoopGroup与对应的ServerChannel，提供onServerChannel方法进行确认。通过preferNative方法判断本地是否支持Epoll与KQueue，实现层面判断功能支持，使用Class.forName进行判断，异常表示不支持。

       针对操作系统支持的EventLoopGroup，DefaultLoop接口提供获取实例、确认支持的源码熊的网址Channel类型和名称获取方法。实现中通过静态代码块进行逻辑判断，选择对应类型，实现懒汉模式。

       LoopResources接口的create方法返回默认的EventLoopGroup实例，考虑多核处理和缓存策略，使用AtomicReference管理实例。针对selectCount的策略设定，实现bossGroup与workerGroup共享或独立。

       获取EventLoopGroup实例的逻辑分为本地支持情况下的默认实现和不支持时的通用NioEventLoopGroup获取。cacheNativeServerLoops和cacheNioServerLoops分别处理本地支持和不支持情况。

       通过拓展ThreadFactory设定线程名称，结合原子计数获取EventLoopGroup线程数，实现更清晰的线程属性描述。Reactor Netty的Dispose逻辑通过Mono.defer封装，确保所有资源释放完毕后结束订阅。

       本章学习到Reactor Netty针对EventLoopGroup的封装设计，通过上层接口提供核心功能，隐藏实现细节，融合Reactor与Netty，了解原子类、ThreadFactory等技术的用法，以及封装、缓存策略等实践。

实现一款高可用的水滴理财源码 TCP 数据传输服务器（Java版）

       实现一款高可用的TCP数据传输服务器，可以利用Netty这款高性能、封装性良好且灵活的开源框架。Netty能够用于手写web服务器、TCP服务器等，支持丰富协议，如HTTP、HTTPS、WEBSOCKET，提供大量方法，可根据需求定制服务器。

       使用Netty编写TCP服务器或客户端时，可以自由设计数据传输协议、自定义编码规则和解码规则、处理socket流攻击、TCP粘包和拆包问题。

       创建普通Maven项目，无需依赖第三方web服务器，通过main方法执行。加入POM依赖，设计基于TCP的数据传输协议。使用进制表示协议的开始位（0x）和结束位（0x），用字节进行表示。

       TCP服务器启动类需要使用bootstrap绑定工作线程组、channel类以及自定义pipeline中的handler类。注意，自定义handler的添加顺序决定了数据流动路径：底层字节流的解码/编码处理器、业务处理处理器。

       编码器负责按照协议格式将数据发送给客户端，实现继承MessageToByteEncoder。解码器为核心部分，自定义解码协议、处理粘包和拆包问题，实现继承ByteToMessageDecoder。

       解决粘包问题时，正常数据传输为完整数据包，但在接收到的数据中可能存在多个数据包的情况。Netty默认将二进制字节码放入byteBuf中，因此需要按照协议设计原则处理粘包问题，解析协议、数据字节、结束标志，并将数据放入out列表中。

       拆包问题同样由ByteToMessageDecoder解决。在解决拆包问题时，需等待不完整数据的剩余部分，将已收到的数据与后续数据合并后进行解码。Netty设计原则是：当读取到的长度超过byteBuf可读内容时，表示发生拆包，调用resetReaderIndex复位读操作指针并结束decode方法。

       业务处理handler类处理完整的解析数据，通过进一步反序列化对象，避免在反序列化时需要处理多种对象类型的情况。使用DTObject包装数据，避免每增加一种对象类型时的if判断。

       编写TCP客户端进行测试。启动类的init方法定义客户端handler，模拟连接建立后向服务端发送数据，使用channel的write方法发送数据。配置编码器，将对象自动转换成字节码放入bytebuf中。

       进行正常数据传输测试，结果成功解析出实体对象。在debug模式下输出数据抓包展示，数据转换为字节码以二进制形式传输，以进制显示，包括开始标志、长度、数据内容和结束标志。

       模拟粘包问题，注释编码器，发送多帧数据封装在单个包中，修改EchoHandler。服务器成功解析出三帧数据，BusinessHandler的channelRead方法被调用多次。抓包显示数据被黏合在同一个包中。

       模拟拆包问题，再次注释编码器，修改EchoHandler。客户端将数据分割成两包发送，服务端在第一包数据时终止解码，并在channelRead中等待第二包数据，将两包数据合并再次解码。

       同时出现拆包、粘包场景时，注释编码器，修改EchoHandler。查看服务端输出结果，验证Netty成功处理了数据的拆包与粘包问题。

       总结：通过遵循Netty的设计原则，可以轻松解决TCP数据传输中的拆包、粘包问题。尽管使用DTObject包装数据避免了处理多种对象类型时的if判断，但仍然无法处理传输List、Map等复杂数据结构的情况。

让我们一起探索一下Netty(Java)底层的“零拷贝Zero-Copy”技术

       Netty中的零拷贝技术主要体现在其底层对操作系统零拷贝策略的应用以及在ByteBuf实现上的优化。零拷贝指的是数据传输过程中，数据不需要经过CPU的拷贝操作，直接在用户空间与内核空间之间传输。传统的零拷贝实现方式需经历四次数据拷贝和四次上下文切换，Netty通过使用Java的FileChannel.transferTo方法避免了不必要的数据拷贝步骤，达到了零拷贝效果。在操作系统的层面，Netty实现了零拷贝，而在ByteBuf层面，Netty进一步提供了零拷贝的实现。

       对于ByteBuffer，Netty提供了两个接口：Direct Buffers和堆外内存。Direct Buffers允许在内存区域直接分配空间，无需在堆内存中分配，从而减少数据在JVM堆内存与堆外内存之间的不必要的拷贝。堆外内存则允许在JVM内部执行I/O操作时，数据直接在堆外内存中操作，避免了数据从堆内存到堆外内存的移动，实现了零拷贝。

       在ByteBuf实现上，Netty提供了多种优化。例如，对于传统的ByteBuffer，如果需要将两个ByteBuffer中的数据组合到一起，则需要创建新的数组并进行数据拷贝。然而，Netty提供的组合ByteBuf（Composite ByteBuf）实现了零拷贝，它保存了多个Buffer的引用而非实际组合，避免了数据的物理移动。此外，Netty在I/O操作中使用了FileChannel的transferTo方法，该方法依赖于操作系统实现零拷贝，进一步优化了数据传输效率。

       Netty的零拷贝技术总结起来主要体现在操作系统级别的零拷贝、ByteBuffer的Direct Buffers和堆外内存应用以及ByteBuf的实现优化。这些技术共同作用于减少数据拷贝和上下文切换，提高系统性能和效率。在堆外内存的回收方面，Netty依赖于JVM的垃圾回收机制，但在实际应用中，开发者需要主动调用System.gc()来触发内存回收，以避免DirectByteBuffer对象及关联的堆外内存占用过多资源。合理管理DirectByteBuffer对象及其堆外内存的使用，可以有效避免内存泄漏和资源浪费，确保系统稳定运行。