netty替代原生的nio原因？

JAVA NIO相对于Old IO APIs 有非常大的改进，但是使用NIO是受限制的。有些是设计问题，有些是缺陷导致，而netty已经解决了这些问题。

①跨平台与兼容性

NIO算是底层的APIs需依赖奥佐系统的IO APIs。但Jvava NIO发现在不同系统平台会出现问题。大量测试也耗不少时间；NIO2只支持JDK1.7+，而且没提供DatagramSocket，故NIO2不支持UDP协议。

而Netty提供统一接口，同一语句无论在JDK6.X 还是JDK7.X 都可运行，无需关心底层架构功能！

②JAVA NIO的ByteBuffer构造函数私有，无法扩展。Netty提供了自己的ByteBuffer实现，通过简单APIs对其进行构造、使用和操作，一此解决NIO的一些限制。

③NIO对缓冲区的聚合与分散操作可能会导致内存泄漏。

直到JDK1.7才解决此问题。

④压碎著名的Epoll缺陷。

Linux-like OSs的选择器使用的是epoll-IO事件通知工具。这是一个在操作系统以异步方式工作的网络stack.Unfortunately，即使是现在，著名的epoll-bug也可能会导致无效的状态的选择和100%的CPU利用率。要解决epoll-bug的唯一方法是回收旧的选择器，将先前注册的通道实例转移到新创建的选择器上。

这里发生的是，不管有没有已选择的SelectionKey，Selector.select()方法总是不会阻塞并且会立刻返回。这违反了Javadoc中对Selector.select()方法的描述，Javadoc中的描述：Selector.select() must not unblock if nothing is selected. (Selector.select()方法若未选中任何事件将会阻塞。)

 

NIO中对epoll问题的解决方案是有限制的，Netty提供了更好的解决方案。

下面是epoll-bug的一个例子：

…

while (true) {

int selected = selector.select();

Set<SelectedKeys> readyKeys = selector.selectedKeys();

Iterator iterator = readyKeys.iterator();

while (iterator.hasNext()) {

…

…

}

}

…

The effect of this code is that the while loop eats CPU:

这段代码的作用是while循环消耗CPU：

…

while (true) {

}

…

 

该值将永远是假的，代码将持续消耗你的CPU资源。这会有一些副作用，因为CPU消耗完了就无法再去做其他任何的工作。

这些仅仅是在使用NIO时可能会出现的一些问题。不幸的是，虽然在这个领域发展了多年，问题依然存在；幸运的是，Netty给了你解决方案。

 

转载于:https://my.oschina.net/grindwheel/blog/749036