NIO的理解，请参照：http://www.goldendoc.org/category/java-nio/
Netty的一些理解，请参照：
http://www.kafka0102.com/2010/06/167.html
http://rdc.taobao.com/team/jm/archives/423
Netty的高可靠性，可伸缩性，以及效率的确让人着迷，为什么Netty这么快呢？
Netty高效的原因：
- 实现了多路Selector用于读和注册，线程数量是cpu*2，reactor都是这么做的，自己处理写事件，这个我在自己框架中也是这么做的，nio的selector处理注册和读，并且也优化了wakeup，Netty中的wakeup也是优化过的，本身一次wakeup对Nio并不大，但是大批量并发的时候就需要进行优化处理了，只有当selector堵塞的时候进行wakeup，或者说需要下次立刻返回的时候wakeup。
- Netty在开启多路读写的时候，用的是DirectBuffer，并用了SoftReferrence来做缓存优化，减少传输数据的内存移动和GC。还有预测数据算法，这个具体能不能提高有待讨论
- 并发的控制，基于SEDA的设计理论构建的高效事件模型，真正的异步处理，吞吐量和伸缩性都可以得到保证。
nio的实现并不复杂，但想让你的底层通讯，效率，以及可伸缩性和高可靠性做好，还是极具挑战性的。
目前有个项目是自己写的nio，但效率比起netty来，小了几个数量级，当然以本人一己之力能做到目前这个情况，还算自己满意，也用到生产环境中了，一个web game，及时性要求很高，一台server，5000人没问题。同时广播消息在10000人以内，当然有些优化是在业务逻辑层面的。当然比起netty的效率来讲还是差了几个数量级。
除了高效，Netty在扩展性方面做的不错：
- 丰富的decoder/encoder实现，你可以轻松的继承一个类实现自己的逻辑，例如游戏中，直接继承FiledLengthBaseFrameDecoder即可。
- 自行添加decoder或者encoder，自由的控制事件流向顺序，通过这个，可以实现一些协议加密解密，协议过滤器，统计工具等等
- 提供很多工具类：Timeout的一些实现，还有ChannelBuffers的一些工具，通常情况下，我们为了减少对Netty的依赖，会自己再封装一层，以完全达到脱离Netty的目的，都会再次封装一层ChannelBuffer，这样目的是不要让上层逻辑跟底层通讯有任何关联，降低耦合，当然也在为考虑更换底层通讯而不影响上层逻辑。
- 提供监听底层消息的ChannelFuture，例如发送完消息可以断开连接等等
- 可调控的通讯架构，可以根据业务的吞吐量来调整，Netty的各项参数不只有socket的一些设置，还能控制事件流顺序和吞吐量的大小等等。
最后，基于Netty我简单封装了一个web game所具备的一些GameBuffer，目前比较简陋，后续可能加入一些别的功能。
项目在:https://github.com/cuixin/XGameEnginee/