站長資訊網(wǎng)自從J2SE
1.4版本以來，JDK發(fā)布了全新的I/O類庫，簡稱NIO，其不但引入了全新的高效的I/O機制，同時，也引入了多路復用的異步模式。下面將介紹Java
NIO類庫Selector機制的解析。
一、 前言
自從J2SE
1.4版本以來，JDK發(fā)布了全新的I/O類庫，簡稱NIO，其不但引入了全新的高效的I/O機制，同時，也引入了多路復用的異步模式。NIO的包中主要包含了這樣幾種抽象數(shù)據(jù)類型：
◆ Buffer：包含數(shù)據(jù)且用于讀寫的線形表結(jié)構(gòu)。其中還提供了一個特殊類用于內(nèi)存映射文件的I/O操作。
◆ Charset：它提供Unicode字符串影射到字節(jié)序列以及逆映射的操作。
◆ Channels：包含socket，file和pipe三種管道，都是全雙工的通道。
◆ Selector：多個異步I/O操作集中到一個或多個線程中（可以被看成是Unix中select()函數(shù)的面向?qū)ο蟀姹荆?/p>
我的大學同學趙錕在使用NIO類庫書寫相關(guān)網(wǎng)絡程序的時候，發(fā)現(xiàn)了一些Java異常RuntimeException，異常的報錯信息讓他開始了對NIO的Selector進行了一些調(diào)查。當趙錕對我共享了Selector的一些底層機制的猜想和調(diào)查時候，我們覺得這是一件很有意思的事情，于是在伙同趙錕進行過一系列的調(diào)查后，我倆發(fā)現(xiàn)了很多有趣的事情，于是導致了這篇文章的產(chǎn)生。這也是為什么本文的作者署名為我們兩人的原因。
先要說明的一點是，趙錕和我本質(zhì)上都是出身于Unix/Linux/C/C++的開發(fā)人員，對于Java，這并不是我們的長處，這篇文章本質(zhì)上出于對Java的Selector的好奇，因為從表面上來看Selector似乎做到了一些讓我們這些C/C++出身的人比較驚奇的事情。
下面讓我來為你講述一下這段故事。
二、 故事開始 : 讓C++程序員寫Java程序!
沒有嚴重內(nèi)存問題，大量豐富的SDK類庫，超容易的跨平臺，除了在性能上有些微辭，C++出身的程序員從來都不會覺得Java是一件很困難的事情。當然，對于長期習慣于使用操作系統(tǒng)API（系統(tǒng)調(diào)用System Call）的C/C++程序來說，面對Java中的比較“另類”地操作系統(tǒng)資源的方法可能會略感困惑，但萬變不離其宗，只需要對面向?qū)ο蟮脑O計模式有一定的了解，用不了多長時間，Java的SDK類庫也能玩得隨心所欲。
在使用Java進行相關(guān)網(wǎng)絡程序的的設計時，出身C/C++的人，首先想到的框架就是多路復用，想到多路復用，Unix/Linux下馬上就能讓從想到select,
poll,
epoll系統(tǒng)調(diào)用。于是，在看到Java的NIO中的Selector類時必然會倍感親切。稍加查閱一下SDK手冊以及相關(guān)例程，不一會兒，一個多路復用的框架便呈現(xiàn)出來，隨手做個單元測試，沒啥問題，一切和C/C++照舊。然后告訴兄弟們，框架搞定，以后咱們就在Windows上開發(fā)及單元測試，完成后到運行環(huán)境Unix上集成測試。心中并暗自念到，跨平臺就好啊，開發(fā)活動都可以跨平臺了。
然而，好景不長，隨著代碼越來越多，邏輯越來越復雜。好好的框架居然在Windows上單元測試運行開始出現(xiàn)異常，看著Java運行異常出錯的函數(shù)棧，異常居然由Selector.open()拋出，錯誤信息居然是Unable
to establish loopback connection。
“Selector.open()居然報loopback
connection錯誤，憑什么？不應該啊？open的時候又沒有什么loopback的socket連接，怎么會報這個錯？”
長期使用C/C++的程序當然會對操作系統(tǒng)的調(diào)用非常熟悉，雖然Java的虛擬機搞的什么系統(tǒng)調(diào)用都不見了，但C/C++的程序員必然要比Java程序敏感許多。
三、 開始調(diào)查 : 怎么Java這么“傻”!
于是，C/C++的老鳥從SystemInternals上下載Process Explorer來查看一下究竟是什么個Loopback Connection。
果然，打開java運行進程，發(fā)現(xiàn)有一些自己連接自己的localhost的TCP/IP鏈接。于是另一個問題又出現(xiàn)了，“憑什么啊？為什么會有自己和自己的連接？我程序里沒有自己連接自己啊，怎么可能會有這樣的鏈接啊？而自己連接自己的端口號居然是些奇怪的端口。”
問題變得越來越蹊蹺了。難道這都是Selector.open()在做怪？難道Selector.open()要創(chuàng)建一個自己連接自己的鏈接？寫個程序看看：
- import java.nio.channels.Selector;
- import java.lang.RuntimeException;
- import java.lang.Thread;
- public class TestSelector {
- private static final int MAXSIZE=5;
- public static final void main( String argc[] ) {
- Selector [] sels = new Selector[ MAXSIZE];
- try{
- for( int i = 0 ;i< MAXSIZE ;++i ) {
- sels[i] = Selector.open();
- //sels[i].close();
- }
- Thread.sleep(30000);
- }catch( Exception ex ){
- throw new RuntimeException( ex );
- }
- }
- }
這個程序什么也沒有，就是做5次Selector.open()，然后休息30秒，以便我使用Process
Explorer工具來查看進程。程序編譯沒有問題，運行起來，在Process
Explorer中看到下面的對話框：（居然有10個連接，從連接端口我們可以知道，互相連接， 如：第一個連第二個，第二個又連第一個）
不由得贊嘆我們的Java啊，先不說這是不是一件愚蠢的事。至少可以肯定的是，Java在消耗寶貴的系統(tǒng)資源方面，已經(jīng)可以趕的上某些蠕蟲病毒了。
如果不信，不妨把上面程序中的那個MAXSIZE的值改成65535試試，不一會你就會發(fā)現(xiàn)你的程序有這樣的錯誤了：（在我的XP機器上大約運行到2000個Selector.open()
左右）
Exception in thread "main" java.lang.RuntimeException: java.io.IOException: Unable to establish loopback connection at Test.main(Test.java:18) Caused by: java.io.IOException: Unable to establish loopback connection at sun.nio.ch.PipeImpl$Initializer.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at sun.nio.ch.PipeImpl.(Unknown Source) at sun.nio.ch.SelectorProviderImpl.openPipe(Unknown Source) at java.nio.channels.Pipe.open(Unknown Source) at sun.nio.ch.WindowsSelectorImpl.(Unknown Source) at sun.nio.ch.WindowsSelectorProvider.openSelector(Unknown Source) at java.nio.channels.Selector.open(Unknown Source) at Test.main(Test.java:15) Caused by: java.net.SocketException: No buffer space available (maximum connections reached?): connect at sun.nio.ch.Net.connect(Native Method) at sun.nio.ch.SocketChannelImpl.connect(Unknown Source) at java.nio.channels.SocketChannel.open(Unknown Source) ... 9 more
四、 繼續(xù)調(diào)查 : 如此跨平臺
當然，沒人像我們這么變態(tài)寫出那么多的Selector.open()，但這正好可以讓我們來明白Java背著大家在干什么事。上面的那些“愚蠢連接”是在Windows平臺上，如果不出意外，Unix/Linux下應該也差不多吧。
于是我們把上面的程序放在Linux下跑了跑。使用netstat
命令，并沒有看到自己和自己的Socket連接。貌似在Linux上使用了和Windows不一樣的機制？！
如果在Linux上不建自己和自己的TCP連接的話，那么文件描述符和端口都會被省下來了，是不是也就是說我們調(diào)用65535個Selector.open()的話，應該不會出現(xiàn)異常了。
可惜，在實現(xiàn)運行過程序當中，還是一樣報錯：（大約在400個Selector.open()左右，還不如Windows）
Exception in thread "main" java.lang.RuntimeException: java.io.IOException: Too many open files at Test1.main(Test1.java:19) Caused by: java.io.IOException: Too many open files at sun.nio.ch.IOUtil.initPipe(Native Method) at sun.nio.ch.EPollSelectorImpl.(EPollSelectorImpl.java:49) at sun.nio.ch.EPollSelectorProvider.openSelector(EPollSelectorProvider.java:18) at java.nio.channels.Selector.open(Selector.java:209) at Test1.main(Test1.java:15)
我們發(fā)現(xiàn)，這個異常錯誤是“Too many open files”，于是我想到了使用lsof命令來查看一下打開的文件。
看到了有一些pipe文件，一共5對，10個（當然，管道從來都是成對的）。可見，Selector.open()在Linux下不用TCP連接，而是用pipe管道。看來，這個pipe管道也是自己給自己的。所以，我們可以得出下面的結(jié)論：
1）Windows下，Selector.open()會自己和自己建立兩條TCP鏈接。不但消耗了兩個TCP連接和端口，同時也消耗了文件描述符。
2）Linux下，Selector.open()會自己和自己建兩條管道。同樣消耗了兩個系統(tǒng)的文件描述符。
估計，在Windows下，Sun的JVM之所以選擇TCP連接，而不是Pipe，要么是因為性能的問題，要么是因為資源的問題。可能，Windows下的管道的性能要慢于TCP鏈接，也有可能是Windows下的管道所消耗的資源會比TCP鏈接多。這些實現(xiàn)的細節(jié)還有待于更為深層次的挖掘。
但我們至少可以了解，原來Java的Selector在不同平臺上的機制。
