引言 在许多业务场景中，我们都会碰到延迟任务，定时任务这种需求。特别的，在网络连接的场景中，常常会出现一些超时控制。由于服务端的连接数量很大，这些超时任务的数量往往也是很庞大的。实现对大量任务的超时管理并不是一个容易的事情。 本章我们将介绍几种用于实现超时任务的数据结构，并且最后分析 Netty 在超时任务上采取的结构和代码。 JDK 原生提供的超时任务支持 java.util.Timer JDK 在 1.3 的时候引入了Timer数据结构用于实现定时任务。Timer的实现思路比较简单，其内部有两个主要属性：  TaskQueue：定时任务抽象类TimeTask的列表。 TimerThread...

引言 在前面关于内存分配的代码分析文章中，我们在多个场合见到了一个类FastThreadLocal。从名字可以看出，这应该是ThreadLocal的高性能版本。 在Netty中，为了打磨性能的细节，在很多方面都做了一些改造，这篇文章我们就来分析下关于FastThreadLocal设计与实现。 原生的ThreadLocal 在介绍Netty的FastThreadLocal之前，我们先来看下再JDK中的ThreadLocal是怎么样的一种解决方案，才能对比出二者的设计上差异化思考。 ThreadLocal的设计意图是让每一个线程都持有自身独立的变量副本，这样，多个线程之间使用的数据是独立的副本，没...

前言 在前面的四个章节中，我们介绍了 Netty 中用于内存管理的内存池算法。Netty4 开始默认都使用内存池用于分配内存空间。而承载池化内存空间的一般都是PooledByteBuf对象。使用池化ByteBuf可以提高性能，但是使用完毕需要注意是否需要进行手工释放。在需要手动释放的场合没有释放，就会因为申请的内存空间没有归还给内存池造成内存泄漏，最终应用程序OOM。 在复杂的应用程序中找到没有释放的PooledByteBuf是一个比较困难的事情，在没有工具辅助的情况下只能白盒检查所有的代码，效率无疑十分低下。 好在 Netty 也考虑到了这种情况，在 Netty 中设计了专门的泄漏检测接口用...

引言 前文我们介绍了Netty中内存池的总体管理相关算法与思路。涉及到的内容包含有：小内存分配，内存块管理，线程缓存。 本文我们将进一步分析其代码实现，帮助读者彻底的掌握 Netty 中内存管理的实现方式。 初始化与内存分配器 内存池初始化 内存池PollArena是内存分配的主要切入点。我们先来看下其属性。PoolArena的属性主要分为三类：  不可变的实例属性，用于存储一些基本信息，如下  内存页大小pageSize。 内存页大小的log2值pageShifts。 内存块大小chunkSize。 触发内存页等分的子页大小溢出掩码subpageOverflowMask。 存储不同的微小等分...

引言 前文我们分析了内存分配的相关算法，以及其在Netty当中的变种和代码实现。之前在内存块中申请内存，申请大小都大于一个内存页的大小。而如果在申请大小小于一个内存页时也分配一个内存页，就显得很浪费了。为此，Netty设计了专门的子页分配算法，用于处理小内存的分配场景。 子页管理算法 对于小于一个内存页大小的内存申请，首先也是需要在内存块上执行申请的，成功后就会得到一个内存页的空间。现在的问题就转化为一个内存页的空间上，如何避免小内存的申请而浪费一个内存页的剩余空间。最容易的想到的就是将小内存也按照内存块的算法分配思路再来一次。不过内存块的分配算法是需要额外的空间来存储元数据信息（二叉树节点相...

引言 前文我们通过引导，设问的方式一步步思考和总结出了一套管理连续内存的申请与分配的方法。同时也分析了相关算法思想下，Netty中算法的变种表现形式。今天，我们接着上文，来为大家梳理下Netty中针对这段算法的代码实现方式。 基础属性 用于实现内存分配算法的类是io.netty.buffer.PoolChunk。这是一个被final修饰的具备泛型的类。使用泛型的主要原因在于，用于分配的内存有两种形式：堆内内存，也就是byte[]和直接内存DirectByteBuffer。 这里有一个基础概念先明确下，进行内存空间的分配的基本是内存块，一个内存块在Netty中默认是64M大小。内存池则是有多个内...

引言 网络IO框架，最大的开销往往并不是在业务处理的环节，而是在高负载高并发下的byte[]对象申请或者ByteBuffer申请。很多时候，这些对象只是短暂的用于承载从通道读取数据或者向通道写出数据。在完成这个职能后，这些对象不再使用被GC回收。 当系统的负载很高时，频繁的申请byte[]或ByteBuffer对象，对内存的压力是很大的，很容易在短时间内消耗大量的内存。此时就只能等待GC将内存回收后系统才能继续运作。从JVM的监控表现来看，就是GC执行的十分频繁，耗时也多。表现在应用性能上，就是会出现时延毛刺和吞吐降低等情况。 Netty4相比于Netty3有一个很大改变在于实现了自行管理的内...

引言 在入门篇的学习中，我们曾经阐述过工作于TCP协议的应用出现的粘包和拆包现象。当时我们介绍了Netty用于解决拆包粘包问题的三种常见的解码器实现：  处理定长协议的FixedLengthFrameDecoder。 处理固定消息分隔符的DelimiterBasedFrameDecoder。 处理报文头+报文体模式协议的LengthFieldBasedFrameDecoder。  今天这篇文章，我们不再介绍更多编解码器的使用，而是从这些解码器的背后实现入手，弄明白他们的处理机制，以及其在Netty整个读写流程中所处的地位。 解码 将socket上读取到的二进制数据转换为后端业务可以理解的消息实...

引言 在前面的文章中，我们详细的学习了Netty处理流程中的方方面面。不过仍然有一些部分细节处的知识点为了避免影响主流程的学习而延后，这篇文章，我们就来好好分析一下Netty当中这些精彩的细节处理。 JDK 空轮训Bug 在JDK的NIO接口中有一个流传很广，影响很恶劣的bug，被称为NIO 100% CPU，也被称为NIO空轮训。来看下如下代码 while(true) { selector.select(); Set < SelectionKey > keys = selector.selectedKeys(); //省略代码：处理keys的内容 } 正常情况下，如果没有关注事件...

引言 在前文中我们介绍了连接就绪，读就绪，接受就绪三种事件流程的处理代码。这篇文章我们来介绍下最后一种流程，数据写出。当用户业务需要将数据写出时一般会调用channel.write或者是channel.writeAndFlush。相关的API在入门篇的例子中也有过演示。本文，我们将来分析这两个API背后的工作原理。 write和flush的区别 在Netty的设计中，写出侧存在一个写出缓存。当我们调用channel.write或者channelHandlerContext.write时，其实只是将需要写出的内容放入到写出缓存的队列中。而只有调用channel.flush或者channelHan...

引言 前文我们介绍了Netty如何让NioServerSocketChannel服务端通道接受并且初始化一个客户端链接。对于一个客户端链接而言，主要的处理任务有两类：处理就绪事件和处理队列任务。其中就绪事件又可以再细分为读就绪，写就绪，连接就绪和接受就绪。接受就绪我们在上文已经分析过了，本文主要来分析读就绪和连接就绪事件。 数据读取 当NioServerSocketChannel初始化完成一个链接后，Netty就可以在该链接上执行读取操作。不过在分析读取操作之前，我们先来复习下客户端链接初始化的一些细节。 客户端链接初始化细节 前文我们介绍了客户端链接在方法ServerBootstrapAcc...

引言 在上篇文章中我们分析了服务端的启动流程。在服务端启动成功后，就可以开始监听端口，并且处理客户端的接入请求了。 服务端的ServerChannel是注册在EventLoop线程上的，而对客户端的接入处理也是从这个地方开始。因此，在这里我们需要首先分析下在NioEventLoop NioEventLoop的run方法 源码篇第一讲，我们曾分析过NioEventLoop，它是一个特殊化的SingThreadEventExecutor，因为其run方法的实现并不是单纯的从队列中取出任务执行，还包含了在Selector对象上执行等待的流程。对于在端口上监听客户端接入请求的服务端程序而言，显然其监听...

引言 在Netty的引导程序中，启动一个服务端应用是一个十分简单的事情。配置链接类对象，配置子类初始化ChannelHandler，再调用bind方法绑定端口号，一个服务端应用就启动完毕了，接着只需要等待客户端发送连接请求，程序就能自动为我们完成客户端接入。看着是很简单的过程，Netty在背后却是做了相当多的工作，本文就以ServerBootStrap启动的时序动作为分析入手点，剖析在引导程序启动中，涉及到的具体代码内容。 总体时序流程 使用ServerBootStrap的bind方法执行对端口的监听，这里面涉及到好几个步骤，简单而言包括有：  按照给定的Channel类，实例化一个对象。 将...

前言 前文中，多次有提到pipeline这个组件。该组件也是Netty中比较核心的一个设计。任何一个通道对象在初始化的时候都会初始化一个pipeline对象。pipeline负责存储添加到通道上的ChannelHandler对象。其本身是一个责任链的设计，前文也多次提到了。那下面就来逐步对其进行代码分析。 类层次图 首先来看下类层次图  从ChannelPipeline继承的接口来看，管道同时对出站事件和入站事件进行传递。其也有唯一的实现类DefaultChannelPipeline。 源码阅读 首先来一张IO事件的处理顺序图，就比较好看的出来pipeline的工作顺序了，如下  这张图传递了...