作者：rickiyang

出处：www.cnblogs.com/rickiyang/p/11074238.html

开发出高质量的 NIO 程序并不是一件简单的事情。

除去 NIO 固有的复杂性和 Bug 不谈，作为一个 NIO 服务端,需要能够处理网络的闪断、客户端的重复接入、客户端的安全认证、消息的编解码、半包读写等情况， 如果你没有足够的 NIO 编程经验积累， 一个 NIO 框架的稳定往往需要半年甚至更长的时间。

更为糟糕的是，一旦在生产环境中发生问题，往往会导致跨节点的服务调用中断，严重的可能会导致整个集群环境都不可用， 需要重启服务器，这种非正常停机会带来巨大的损失。

从可维护性角度看，由于 NIO 采用了异步非阻塞编程模型，而且是一个 I/O 线程处理多条链路，它的调试和跟踪非常麻烦，特别是生产环境中的问题，我们无法进行有效的调试和跟踪，往往只能靠一些日志来帮助分析，定位难度很大。

对于 Java 原生的 IO 我们之所以不选择使用是因为：

1. NIO的类库和API繁杂使用麻烦，你需要熟练掌握Selectol,ServerSocketChannel,
   SocketChannel,ByteBuffer 等。
2. 需妥具备其他的额外技能做制垫，例如熟悉Java 多线程编程。这是因为NIO编程涉及到Reactor 模式，你必须对多钱程和网络编程非常如悉，才能编写出高质量的NIO程序。
3. 可靠性能力补齐， 工作量和难度都非常大。例如客户端面临断连重连、网络间断、半包读写、失败缓存、网络拥塞和异常码流的处理等问题， NI0 编程的特点是功能开发相对容易，但是可靠性能力补齐的工作量和难度都非常大。
4. JDK NIO的BUG，比如epoll bug，这个BUG会在linux上导致cpu 100%，使得nio server/client不可用，这个BUG直到jdk 6u4才解决，但是直到JDK1.7中仍然有这个问题，该问题并未被完全解决，只是发生的频率降低了而已。

基于上述原因大多数场景下都不建议直接使原生 NIO，除非你精通 NIO 编程或者是有特殊的需要，否则作为服务器编程的NIO可能会带来巨大的生产隐患。

关于Netty：

Netty是一个高性能、异步事件驱动的NIO框架，它提供了对TCP、UDP和文件传输的支持，作为一个异步NIO框架，Netty的所有IO操作都是异步非阻塞的，通过Future-Listener机制，用户可以方便的主动获取或者通过通知机制获得IO操作结果。

作为当前最流行的NIO框架，Netty在互联网领域、大数据分布式计算领域、游戏行业、通信行业等获得了广泛的应用，一些业界著名的开源组件也基于Netty的NIO框架构建。

与Netty同样功能的NIO框架还有Mina，Netty的主导作者与Mina的主导作者是同一人，在设计理念上与Mina基本上是一致的。Mina出身于开源界的大牛Apache组织，Netty出身于商业开源大亨Jboss。

这几年Netty社区相对比较活跃，所以我们就先选择Netty作为入手网络编程的首选，有时间再学习一下Mina。