如果不了解netty的，可以百度下，netty社区现在也比较活跃。

现在所谓的大数据，flume，storm等底层都是netty。

 

netty的性能模型：

io模型---->异步非阻塞io

1：jdk1.4开始提供了非阻塞io，即nio

jdk1.5以后，epoll代替了poll，打破了selector上链路的限制。

 

2：零拷贝

directbuffer vs heapbytebuffer

netty不用任何配置，默认线程发送和接受使用的就是directbuffer。

如果使用堆内存，tcp读取一条消息码流，先从fd句柄里读到directbuffer，然后从directbuffer拷贝到heapBuffer。

使用directbuffer，少了一次内存拷贝。

 

组合的buffer

我们做rpc或者私有协议时候，通常的消息都是由head和body组成，每次发送消息时都会内存拷贝，把老的buffer拷贝到新的buffer，把老的释放掉，再更新最新的buffer。但是使用组合的buffer时，可以把多个buffer聚合成一个buffer操作。

 

文件传输transferTo

在很多操作系统时，它会做优化，会在文件缓冲区，直接写到channel，省去了堆的操作。

 

3：内存池

poolbytebufAllocator

 

数据协议---->可定制的编解码框架

可定制的序列化框架，netty不绑架任何序列化工具。java序列化效率比较低，有兴趣的朋友可以自己做个试验。

 

线程模型---->reactor线程模型

 

1.单线程模型：

 

2.多线程模型：

 

3.无锁化串行设计：

java1.5以后，引入了线程池的概念，动态扩展。

netty使用了串行设计，串行化过程中，不存在锁的概念，如果多个串行共同执行效果避免了多线程竞争导致性能下降。

 

netty的可靠性：

netty提供了读空闲、写空闲、读写空闲的检测。

通常节点内部通信都是长连接，长连接一般都会做心跳检测，为了防止误判，连续xx次后关闭重连等。

我所接触的游戏都是自己设计channelHandler，然而netty本身提供了这种检测机制。监听这个event事件就可以了。

 

reactor线程保护

某个消息的异常不应该导致整条链路不可用

某条链路不可用不应该导致其他链路不可用

这与分布式服务，就是服务节点了，后面一章分析netty源码时会详细的说下。

 

jdk epoll空轮训：

空轮训导致cpu100%的bug，这个bug到现在也没有修复，内部设计的复杂程度可以想象。

但是netty采用的是rebuild，就是检测到的时候，把之前selector关闭（之前的channel转移到新的selector上）。

 

安全性：

ssl单向认证

 

内存分配与流量整形