youaremoon的专栏

前面几篇文章，我们从服务端的视角，分析了从启动到接收连接，到连接的read-write-close。现在我们开始切换到客户端的视角，看看客户端连接服务端的一些实现细节。还是从snoop的example代码开始，见HttpSnoopClient（稍有修改）

NioSocketChannel之服务端视角上篇文章对NioServerSocketChannel进行了分析，了解了一个客户端连接在netty中是如何接收的。本篇我们将详细的了解服务端收到的连接的整个生命周期。需要说明的是由于采用的是服务端视角，因此一个连接的生命周期主要包括：创建读取数据写数据关闭创建快捷键加粗 Ctrl + B 斜体 Ctr

前面我们讲了server的启动过程，同时介绍了其中非常重要的几个概念,ChannelPipeline,ChannelHandlerContext等。接下来我们看看server启动起来以后是如何运转的。

上一篇文章中，我们介绍了ServerBootstrap的启动过程，在这个过程中引出了一个很重要的类ChannelPipeline。如果说内存池，线程模型是netty的基础，我们接触的相对来说并不是那么直接，那么ChannelPipeline则是我们开发中直接能够接触到的概念，如果对其不了解，很容易造成一些不正确的使用姿势或一些然并卵的优化。现在我们就来看看ChannelPipeline的作用到底是

前面我们分析了netty内存池、线程模型，比较难的两个点已经被一一消化，接下来我们开始进入大家最关心的环节，总体流程分析。 这里我选了io.netty.example.http.snoop来作为分析的入口，分别从server端、client端的维度来看看netty是如果设计的。这里你将了解比较详细的netty处理流程，让你在今后的应用中不再感到疑惑 。 如果还有不清楚的地方，可以直接交流，通过交流

NioEventLoop里面使用了MpscLinkedQueue作为taskQueue，替换了父类中默认的LinkedBlockingQueue队列。taskQueue主要用于存放可执行任务，其调用的频率非常高，因此使用一个更高效的队列能带来很大的收益。 为什么在NioEvnetLoop里用MpscLinkedQueue替换了LinkedBlockingQueue，是使用了更好的算法？还是通过舍弃

并发的一个很大的敌人就是锁，很多时候我们必须加锁来应对并发带来的线程安全问题。而ThreadLocal则给我们开辟了另外一个思路，将数据与线程关联，一个线程无法读到其他线程的数据， 这样的数据存储方式，自然就能线程安全了。 那么ThreadLocal本身还有没有可以挖掘的优化点呢，号称性能极高的netty告诉你，有！        我们知道ThreadLocal的实现是在Thread里

NioEventLoop相对NioEventLoopGroup来说就复杂很多了，需要一定的耐心来看这篇文章。        首先从NioEventLoop的启动讲起，对于线程池来说，启动一般都是从第一个任务的添加开始的。经过跟踪，找到execute()方法在SingleThreadEventExecutor类中： public void execute(Runnable task)

阅读本文之前，你需要对java的线程池有一定的了解，因为这里不会过多的讲解。    今天我们主要的任务就是看下netty中一个非常重要的类EventLoop，通过这篇文章，你应该了解EventLoop适用的场景，不会滥用它而导致你的应用缓慢。Netty适用了典型的Reactor模型结构，这其中一个很重要的角色就是EventLoop，它使用循环的方式来处理已经准备好的IO或者其他事件。

冬天实在太冷了，习惯了广东的天气，突然换个地方还真有点不适应, 早就想写的学习笔记也一直拖到现在。下面进入正题，一起来学习下netty的线程池实现。 我们知道java本身实现了一套线程池，即我们常见的ExecutorService。那么netty为什么还要定义自己的线程模型，什么时候适合用netty线程池，什么时候适合用ExecutorService。相信你看了这几篇文章就会有眉目。

如果你看了前面的几篇内存池的介绍，你可能会觉得并没有什么卵用。 这里就搞点有用的 -- netty内存池可调优参数参数名说明默认值io.netty.allocator.pageSizepage的大小8192io.netty.allocator.maxOrder一个chunk的大小=pageSize 11io.n

看了前面的PoolArena分析，我们知道PoolArena在分配内存时，使用了synchronized来保证线程安全，这样就带来了一定的效率问题。如何能再此基础上再优化呢，答案很简单，使用ThreadLocal类似的解决方案避免加锁！ 为什么可以使用ThreadLocal，如果了解过netty线程模型（有兴趣后续可以一起学习），应该知道netty的woker线程池，它负责了数据的接收、发送（编解

前面我们讲到了内存池中的几个重要的类：        1、PoolChunk：维护一段连续内存，并负责内存块分配与回收，其中比较重要的两个概念：page:可分配的最小内存块单位；chunk:page的集合；        2、PoolSubpage：将page分为更小的块进行维护；        3、PoolChunkList：维护多个PoolChunk的生命周期。

前面我们介绍了PoolChunk以及针对page的更细粒度的PoolSubpage，其实在chunk的上层还有一个管理类：PoolChunkList，PoolChunkList负责管理多个chunk的生命周期，在此基础上对内存分配进行进一步的优化，那它是如何去做的呢？我们来简单的了解下，先看看它的几个属性：PoolArena arena; // 这个东西又出现了，看来是个终极boss啊，后面再

前面我们讲过了负责内存分配的类PoolChunk，它最小的分配单位为page, 而默认的page size为8K。在实际的应用中，会存在很多小块内存的分配，如果小块内存也占用一个page明显很浪费，针对这种情况，可以将8K的page拆成更小的块，这已经超出chunk的管理范围了，这个时候就出现了PoolSubpage, 其实PoolSubpage做的事情和PoolChunk做的事情类似，只是Poo

从netty 4开始，netty加入了内存池管理，采用内存池管理比普通的new ByteBuf性能提高了数(2)十倍。相信有些朋友会和我一样，对他的实现方式很感兴趣。这里把学习netty内存池的过程记录下来，与大家一起分享。首先给大家介绍的是PoolChunk, 该类主要负责内存块的分配与回收，下面看看几个重要的术语：page: 可以分配的最小的内存块单位。chunk: chunk是一

netty中用到内存泄露检测的地方主要有：1、CompositeByteBuf；2、HashedWheelTimer；3、继承AbstractByteBufAllocator的几个类。下面我们看看，netty里的内存检测类ResourceLeakDetector的具体实现：