NIO vs Netty

跨平臺和兼容性

NIO依賴操作系統(tǒng)平臺底層IO系統(tǒng)，Linux平臺上開發(fā)的功能可能在Windows平臺上并不奏效。除非將這些功能在所有的平臺上進(jìn)行測試，這無疑是很大的工作量。

NIO.2只在JDK7開始支持，在JDK6上并不能使用。JDK中并沒有提供在NIO.2－簡介中提到的對AsynchronousDatagramChannel(UDP)的支持，這樣我們就只能局限在TCP上。

是否選擇擴(kuò)展 ByteBuffer

我們并不能從ByteBuffer獲取一個(gè)ByteBuffer數(shù)組的擴(kuò)展，因?yàn)樗臉?gòu)造器并不對外開放。而在實(shí)際應(yīng)用中一個(gè)ByteBuffer數(shù)組能夠很大程度上減少內(nèi)存拷貝帶來的開銷。

分散和聚集可能引發(fā)內(nèi)存泄漏

在JDK6、JDK7中會印發(fā) OutOfMemoryError。

epoll bug

在類Linux系統(tǒng)上,選擇器使用了 epoll - IO事件通知功能.這是一個(gè)高性能的技術(shù),在網(wǎng)絡(luò)棧的異步工作的系統(tǒng)上.不幸地是,即使今天,"著名的" epoll-bug 可能導(dǎo)致在選擇器中"無效的"狀態(tài),導(dǎo)致了100%CPU使用和自旋.修復(fù)的唯一方式就是回收老的selector,然后將之前注冊的 Channel 實(shí)例傳給新創(chuàng)建的 Selector.

Selector.select() 會停止阻塞，直接返回，但是并沒有選擇人和的SelectorKey實(shí)例。這樣導(dǎo)致會有一個(gè)死循環(huán)吃掉你的CPU。

好吧，Netty都避免了上面的問題 大寫的NB