基于不断的对Netty框架和系统底层知识的理解过程，总结Netty采用的高性能技术与设计，构建自己的认知体系。不断完善中~
-
多路复用通讯方式
以在Linux系统中为例，Netty利用系统提供的event poll能力(epoll)，使得少量线程高效的同时处理大量网络连接称为可能。
-
“零拷贝”技术
所谓零拷贝，准确应该是称为”尽量减少数据在内存中的复制的各种相关技术“，netty中主要有以下几点：
-
Netty中的ByteBuf相当于是个虚拟Buffer，整合多个ByteBuffer。
以接收服务端数据为例，由于采用了非阻塞的io方式，数据必然是可能分多次read然后存放在不同的ByteBuffer上的，这是数据传输也就是TCP层面的，那么最后HTTP层面，我们实际需要的是一个完整的Request Message之后对完整的请求报文进行解析，然后处理请求逻辑。那么如果是用ByteBuffer的话，就需要进行组合而少不了buffer的复制。Netty使用虚拟buffer的方式管理了各个实际buffer的位置、而不是真正的把它们复制到一个完整的大buffer中去，这样对使用netty的开发者来说，就好像直接使用了一个完整的buffer一样，底层的结构对开发者透明。一种非常走心的封装。
Netty做文件传输的话，使用了transferTo方法。底层利用的是系统的sendfile能力。对于需要发送的文件数据来说，只进行了两次DMA复制而没有CPU参与复制，减轻了CPU的负担。另外，也避免了内核buffer与用户buffer之间的数据复制，减少了用户态内存的占用，也减少了上下文切换了次数。
-
Netty直接使用堆外的直接内存来做buffer，没有使用堆内存里的buffer。
首先明确的一个事实是，使用堆外内存是一种“必然”：Java是没有I/O能力的，得借助操作系统。数据从网卡通过DMA到了系统内核的socket缓冲，java想用这部分数据的话要么把数据复制到自己的堆上来操作，或者要么是java取得这部分堆外直接内存的映射关系、也就是拿到堆外内存地址，这样也可以拿到这些数据（unsafe包的能力）。所以说使用直接的内存的好处就看出来了，少了堆内存的占用、也免了gc，还免了内存复制和上下文切换。
-
-
内存池
上面提到Netty为了高性能而使用了堆外直接内存作为buffer缓冲区。带来的一个问题是堆外直接内存的申请与释放的开销是非常大的、是重量级的工作，得想办法复用，提到复用自然想到了池化技术。Netty提供了基于内存池的缓冲区复用机制。https://my.oschina.net/andylucc/blog/614589
-
高效Reactor线程模型
在操作系统的epoll()能力和NIO异步通讯模型的支持下，使得我们可以实现下面三种Reactor线程模型：
- 单reactor线程模型，一个reactor线程做所有的工作。
- 前边1个reactor线程也就是boss做accept，后边是N个reactor worker线程组成线程池做read和write工作。
- boss和worker都是线程池
无锁设计、线程绑定
EventLoop封装了IO相关的方法，非IO线程执行这些方法时，内部会将IO操作封装成task，根据channel与EventLoop的对应关系，提交到EventLoop内部的一个高性能CAS无锁队列里(org.jctools.queues.MpscUnboundedArrayQueue)，所以io task都由IO线程来执行，io线程一直不断循环处理：向selector轮询ACCEPT,READ,WRITE,CONNECT等IO事件->处理IO事件->处理队列里非io线程提交上来的io操作，这样一个loop过程。
这里有个细节，站在EventLoop的这些IO相关的方法的角度，需要判断当前的io操作是绑定到本EventLoop的IO线程调用的，还是非IO线程调用的，如果是前者，如果是则直接执行，否则入队列，这就是inEventLoop()方法的作用。
关于EventLoop内置的那个无锁队列，可以参考https://my.oschina.net/hmilyylimh/blog/1787788
