JAVA NIO相對(duì)于Old IO APIs 有非常大的改進(jìn)，但是使用NIO是受限制的。有些是設(shè)計(jì)問(wèn)題，有些是缺陷導(dǎo)致，而netty已經(jīng)解決了這些問(wèn)題。
①跨平臺(tái)與兼容性
NIO算是底層的APIs需依賴奧佐系統(tǒng)的IO APIs。但Jvava NIO發(fā)現(xiàn)在不同系統(tǒng)平臺(tái)會(huì)出現(xiàn)問(wèn)題。大量測(cè)試也耗不少時(shí)間；NIO2只支持JDK1.7+，而且沒(méi)提供DatagramSocket，故NIO2不支持UDP協(xié)議。
而Netty提供統(tǒng)一接口，同一語(yǔ)句無(wú)論在JDK6.X 還是JDK7.X 都可運(yùn)行，無(wú)需關(guān)心底層架構(gòu)功能！
②JAVA NIO的ByteBuffer構(gòu)造函數(shù)私有，無(wú)法擴(kuò)展。Netty提供了自己的ByteBuffer實(shí)現(xiàn)，通過(guò)簡(jiǎn)單APIs對(duì)其進(jìn)行構(gòu)造、使用和操作，一此解決NIO的一些限制。
③NIO對(duì)緩沖區(qū)的聚合與分散操作可能會(huì)導(dǎo)致內(nèi)存泄漏。
直到JDK1.7才解決此問(wèn)題。
④壓碎著名的Epoll缺陷。
On Linux-like OSs the selector makes use of the epoll- IO event notification facility. This is a high-performance technique in which the OS works asynchronously with the networking stack.Unfortunately,? even? today? the “famous” epoll- bug? can? lead? to? an “invalid” state? in? the selector, resulting in 100% CPU-usage and spinning. The only way to recover is to recycle the old? selector? and? transfer? the? previously? registered? Channel? instances? to? the? newly? created Selector.
Linux-like OSs的選擇器使用的是epoll-IO事件通知工具。這是一個(gè)在操作系統(tǒng)以異步方式工作的網(wǎng)絡(luò)stack.Unfortunately，即使是現(xiàn)在，著名的epoll-bug也可能會(huì)導(dǎo)致無(wú)效的狀態(tài)的選擇和100%的CPU利用率。要解決epoll-bug的唯一方法是回收舊的選擇器，將先前注冊(cè)的通道實(shí)例轉(zhuǎn)移到新創(chuàng)建的選擇器上。
What? happens? here? is? that? the Selector.select() method? stops? to? block? and? returns immediately-even? if? there? are? no? selected? SelectionKeys? present.? This? is? against? the contract,? which? is? in? the? Javadocs? of? the? Selector.select()? method:Selector.select() must not unblock if nothing is selected.
這里發(fā)生的是，不管有沒(méi)有已選擇的SelectionKey，Selector.select()方法總是不會(huì)阻塞并且會(huì)立刻返回。這違反了Javadoc中對(duì)Selector.select()方法的描述，Javadoc中的描述：Selector.select() must not unblock if nothing is selected. (Selector.select()方法若未選中任何事件將會(huì)阻塞。)
The range of solutions to this epoll- problem is limited, but Netty attempts to automatically detect and prevent it. The following listing is an example of the epoll- bug.
NIO中對(duì)epoll問(wèn)題的解決方案是有限制的，Netty提供了更好的解決方案。
下面是epoll-bug的一個(gè)例子：
…
while (true) {
int selected = selector.select();
Set readyKeys = selector.selectedKeys();
Iterator iterator = readyKeys.iterator();
while (iterator.hasNext()) {
…
…
}
}
…
The effect of this code is that the while loop eats CPU:
這段代碼的作用是while循環(huán)消耗CPU：
…
while (true) {
}
…
The value will never be false, and the code keeps your CPU spinning and eats resources. This can have some undesirable side effects as it can consume all of your CPU, preventing any other CPU-bound work.
該值將永遠(yuǎn)是假的，代碼將持續(xù)消耗你的CPU資源。這會(huì)有一些副作用，因?yàn)镃PU消耗完了就無(wú)法再去做其他任何的工作。
These are only a few of the possible problems you may see while using non-blocking IO. Unfortunately, even after years of development in this area, issues still need to be resolved; thankfully, Netty addresses them for you.
這些僅僅是在使用NIO時(shí)可能會(huì)出現(xiàn)的一些問(wèn)題。不幸的是，雖然在這個(gè)領(lǐng)域發(fā)展了多年，問(wèn)題依然存在；幸運(yùn)的是，Netty給了你解決方案。
⑤ Summary
This chapter provided an overview of Netty’s features, design and benefits. I discussed the difference between blocking and non-blocking processing to give you a fundamental understanding of the reasons to use a non-blocking framework. You learned how to use the JDK API to write network code in both blocking and non-blocking modes. This included the new non-blocking API, which comes with JDK 7. After seeing the NIO APIs in action, it was also important to understand some of the known issues that you may run into. In fact, this is why so many people use Netty: to take care of workarounds and other JVM quirks. In the next chapter, you’ll learn the basics of the Netty API and programming model, and, finally, use Netty to write some useful code.
