下面的是ServerBootstrap 的内部类 ServerBootstrapAcceptor extends ChannelInboundHandlerAdapter 的方法 这里其实卡住了我很长时间,为啥AbastracHandlerContext的handler()方法,返回的会是ServerBootstrapAcceptor 的对象呢? 先看handler方法,这是个重写的方法,会在子类里实现,到底是哪个子类实现的?往上看,调用handler的方法参数,从上面传进来的是一个 在 pip

Netty源码分析第五章: ByteBuf 第十节: SocketChannel读取数据过程 我们第三章分析过客户端接入的流程, 这一小节带大家剖析客户端发送数据, Server读取数据的流程: 首先温馨提示, 这一小节高度耦合第三章的第1, 2节的内容, 很多知识这里并不会重复讲解, 如果对之前的知识印象不深刻建议恶补第三章的第1, 2节的内容之后再学习这一小节 我们首先看NioEventLoop的processSelectedKey方法: private void processSelect

前面两篇博客[Netty源码分析]Netty服务端bind端口过程和[Netty源码分析]客户端connect服务端过程中我们分别介绍了服务端绑定端口和客户端连接到服务端的过程,接下来我们分析一下数据发送的过程. future.channel().writeAndFlush("Hello Netty Server ,I am a common client"); 调用AbstractChannel的writeAndFlush函数 @Override public ChannelFutu

参考文献:极客时间傅健老师的<Netty源码剖析与实战>Talk is cheap.show me the code! ----主线:worker thread ①多路复用器(Selector)接受到OP_READ事件 ②处理OP_READ事件:NioSocketChannel.NioSocketChannelUnsafe.read(); -1分配一个初始1024字节的byte buffer来接受数据 -2从Channel接受数据到byte buffer -3记录实际接受数据大小,调整下次分配

Netty源码分析第七章: 编码器和写数据 概述: 上一小章我们介绍了解码器, 这一章我们介绍编码器 其实编码器和解码器比较类似, 编码器也是一个handler, 并且属于outbounfHandle, 就是将准备发出去的数据进行拦截, 拦截之后进行相应的处理之后再次进发送处理, 如果理解了解码器, 那么编码器的相关内容理解起来也比较容易 第一节: writeAndFlush的事件传播 我们之前在学习pipeline的时候, 讲解了write事件的传播过程, 但在实际使用的时候, 我们通常不会调

Netty源码分析第七章: Netty源码分析 第二节: MessageToByteEncoder 同解码器一样, 编码器中也有一个抽象类叫MessageToByteEncoder, 其中定义了编码器的骨架方法, 具体编码逻辑交给子类实现 解码器同样也是个handler, 将写出的数据进行截取处理, 我们在学习pipeline中我们知道, 写数据的时候会传递write事件, 传递过程中会调用handler的write方法, 所以编码器码器可以重写write方法, 将数据编码成二进制字节流然后再继

Netty源码分析七章: 编码器和写数据 第三节: 写buffer队列 之前的小节我们介绍过, writeAndFlush方法其实最终会调用write和flush方法 write方法最终会传递到head节点, 调用HeadContext的write方法: public void write(ChannelHandlerContext ctx, Object msg, ChannelPromise promise) throws Exception { unsafe.write(msg, prom

Netty源码分析第七章: 编码器和写数据 第四节: 刷新buffer队列 上一小节学习了writeAndFlush的write方法, 这一小节我们剖析flush方法 通过前面的学习我们知道, flush方法通过事件传递, 最终会传递到HeadContext的flush方法: public void flush(ChannelHandlerContext ctx) throws Exception { unsafe.flush(); } 这里最终会调用AbstractUnsafe的flush方法

Netty源码分析第七章: 编码器和写数据 第五节: Future和Promise Netty中的Future, 其实类似于jdk的Future, 用于异步获取执行结果 Promise则相当于一个被观察者, 其中promise对象会一直跟随着channel的读写事件, 并跟踪着事件状态, 然后执行相应的回调 这种设计思路也就是java设计模式的观察者模式 首先我们看一段写在handler中的业务代码: @Override public void channelRead(ChannelHandle

参考文献:极客时间傅健老师的<Netty源码剖析与实战>Talk is cheap.show me the code! 开始之前先介绍下Netty写数据的三种方式: ①:write:写到一个buffer,flush:把buffer里的数据发送出去 ②:writeAndFlush:写到buffer,立马发送 ③:write和flush之间有个ChannelOutboundBuffer 可以用生活中快递场景来类比下: write相当于揽收到仓库,flush相当于从仓库发货,writeAndFlus

ChannelPipeline类似于一个管道,管道中存放的是一系列对读取数据进行业务操作的ChannelHandler. 1.ChannelPipeline的结构图: 在之前的博客[Netty源码学习]入门示例我们看到了如下的代码: future.channel().writeAndFlush("Hello Netty Server ,I am a common client"); 其实就是Client向Server发送数据,其具体实现是在AbstractChannel类中 @Over

Netty 源码 Channel(二)核心类 Netty 系列目录(https://www.cnblogs.com/binarylei/p/10117436.html) 一.Channel 类图 二.AbstractChannel 2.1 几个重要属性 // SocketChannel 的 parent 是 ServerSocketChannel private final Channel parent; // 唯一标识 private final ChannelId id; // Netty

Netty 源码 NioEventLoop(三)执行流程 Netty 系列目录(https://www.cnblogs.com/binarylei/p/10117436.html) 上文提到在启动 NioEventLoop 线程时会执行 SingleThreadEventExecutor#doStartThread(),在这个方法中调用 SingleThreadEventExecutor.this.run(),NioEventLoop 重写了 run() 方法.NioEventLoop#run(

前言 在 Netty 源码剖析之 unSafe.read 方法 一文中,我们研究了 read 方法的实现,这是读取内容到容器,再看看 Netty 是如何将内容从容器输出 Channel 的吧. 1. ctx.writeAndFlush 方法 当我们调用此方法时,会从当前节点找上一个 outbound 节点,进行,并调用下个节点的 write 方法.具体看代码: @1 public ChannelFuture writeAndFlush(Object msg) { return writeAndF

Netty源码分析(完整版) 前言 前段时间公司准备改造redis的客户端, 原生的客户端是阻塞式链接, 并且链接池初始化的链接数并不高, 高并发场景会有获取不到连接的尴尬, 所以考虑了用netty长连接解决连接数和阻塞io问题 为此详细阅读了netty源码, 熟悉了netty的各个主要的特性以及疏通各个组件的关联关系, 所以想把这段时间的学习内容, 学习经验毫无保留的分享给大家, 自己提高的同时也帮助大家一起成长 内容中我会把每个知识点通过每个章节去进行剖析, 每个章节也会尽可能的将关键的流程

Netty 源码(一)服务端启动 Netty 系列目录(https://www.cnblogs.com/binarylei/p/10117436.html) ServerBootstap 创建时序图如下: 一.参数配置 (1) 绑定 Reactor 线程池 服务端通常会构建两个线程池,bossGroup 负责接收连接,childGroup 负责处理网络 IO 以及系统 Task. public ServerBootstrap group(EventLoopGroup parentGroup, E

原文地址: haifeiWu的博客 博客地址:www.hchstudio.cn 欢迎转载,转载请注明作者及出处,谢谢! 近期一直在做网络协议相关的工作,所以博客也就与之相关的比较多,今天楼主结合 Redis的协议 RESP 看看在 Netty 源码中是如何实现的. RESP 协议 RESP 是 Redis 序列化协议的简写.它是一种直观的文本协议,优势在于实现非常简单,解析性能极好. Redis 协议将传输的结构数据分为 5 种最小单元类型,单元结束时统一加上回车换行符号\r\n,来表示该单元的

Netty源码分析第五章: ByteBuf 概述: 熟悉Nio的小伙伴应该对jdk底层byteBuffer不会陌生, 也就是字节缓冲区, 主要用于对网络底层io进行读写, 当channel中有数据时, 将channel中的数据读取到字节缓冲区, 当要往对方写数据的时候, 将字节缓冲区的数据写到channel中 但是jdk的byteBuffer是使用起来有诸多不便, 比如只有一个标记位置的指针position, 在进行读写操作时要频繁的通过flip()方法进行指针位置的移动, 极易出错, 并且by

Netty源码分析第五章: ByteBuf 第九节: ByteBuf回收 之前的章节我们提到过, 堆外内存是不受jvm垃圾回收机制控制的, 所以我们分配一块堆外内存进行ByteBuf操作时, 使用完毕要对对象进行回收, 这一小节, 就以PooledUnsafeDirectByteBuf为例讲解有关内存分配的相关逻辑 PooledUnsafeDirectByteBuf中内存释放的入口方法是其父类AbstractReferenceCountedByteBuf中的release方法: @Overrid

Netty源码分析第六章: 解码器 概述: 在我们上一个章节遗留过一个问题, 就是如果Server在读取客户端的数据的时候, 如果一次读取不完整, 就触发channelRead事件, 那么Netty是如何处理这类问题的, 在这一章中, 会对此做详细剖析 之前的章节我们学习过pipeline, 事件在pipeline中传递, handler可以将事件截取并对其处理, 而之后剖析的编解码器, 其实就是一个handler, 截取byteBuf中的字节, 然后组建成业务需要的数据进行继续传播 编码器,

Netty源码分析第八章: 高性能工具类FastThreadLocal和Recycler 第七节: 获取异线程释放的对象 上一小节分析了异线程回收对象, 原理是通过与stack关联的WeakOrderQueue进行回收 如果对象经过异线程回收之后, 当前线程需要取出对象进行二次利用, 如果当前stack中为空, 则会通过当前stack关联的WeakOrderQueue进行取出, 这也是这一小写要分析的, 获取异线程释放的对象 在介绍之前我们首先看Stack类中的两个属性: private Wea