Netty源码分析系列文章已接近尾声，本文再来分析Netty中两个常见组件：FastThreadLoca与HashedWheelTimer。源码分析基于Netty 4.1.52

首先说明PoolChunk内存组织方式。PoolChunk的内存大小默认是16M，Netty将它划分为2048个page，每个page为8K。PoolChunk上可以分配Normal内存块。Normal内存块大小必须是page的倍数。

我们知道，Netty使用直接内存实现Netty零拷贝以提升性能，但直接内存的创建和释放可能需要涉及系统调用，是比较昂贵的操作，如果每个请求都创建和释放一个直接内存，那性能肯定是不能满足要求的。这时就需要使用内存池。即从系统中申请一大块内存，再在上面分配每个请求所需的内存。

Eureka分为Eureka Client，Eureka Server，多个Eureka Server节点组成一个Eureka集群，服务通过Eureka Client注册到Eureka Server。

本文分享spring cloud sleuth如何构建请求调用链路，并上报zipkin。如果大家在使用spring cloud sleuth时遇到traceId丢失，上报zipkin失败等问题，希望本文可以给大家一个思路。源码分析基于Spring Cloud Hoxton，Spring Cloud Sleuth版本为2.2.0.RELEASE

本文通过阅读源码，分享Spring Cloud Config与@RefreshScope的实现原理。源码分析基于Spring Cloud Hoxton

Netty中的ChannelPipeline可以理解为拦截器链，维护了一个ChannelHandler链表，ChannelHandler即具体拦截器，可以在读写过程中，对数据进行处理。ChannelHandler也可以分为两类。ChannelInboundHandler，监控Channel状态变化，如channelActive，channelRegistered，通常通过重写ChannelOutboundHandler#channelRead方法...

前面分享服务端和客户端启动过程的文章中说过，Netty通过事件循环机制(EventLoop)处理IO事件和异步任务，简单来说，就是通过一个死循环，不断处理当前已发生的IO事件和待处理的异步任务。示例如下

Netty是一个高性能的网络通信框架，支持NIO，OIO等多种IO模式。通常，我们都是使用NIO模式，该系列文章也是解析Netty下NIO模式的实现。首先，看一个NIO网络通信示意图Netty中NIO网络通信过程在此基础上实现，下面来看一下具体实现。

本文主要分享SpringCloud中RestTemplate与@LoadBalanced的实现原理。源码分析基于Spring Cloud Hoxton