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給了你解決方案。