四、 继续调查 : 如此跨平台
当然，没人像我们这么变态写出那么多的Selector.open()，但这正好可以让我们来明白Java背着大家在干什么事。上面的那些“愚蠢连接”是在Windows平台上，如果不出意外，Unix/Linux下应该也差不多吧。
于是我们把上面的程序放在Linux下跑了跑。使用netstat 命令，并没有看到自己和自己的Socket连接。貌似在Linux上使用了和Windows不一样的机制？！
如果在Linux上不建自己和自己的TCP连接的话，那么文件描述符和端口都会被省下来了，是不是也就是说我们调用65535个Selector.open()的话，应该不会出现异常了。
可惜，在实现运行过程序当中，还是一样报错：（大约在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.<init>(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)
我们发现，这个异常错误是“Too many open files”，于是我想到了使用lsof命令来查看一下打开的文件。
看到了有一些pipe文件，一共5对，10个（当然，管道从来都是成对的）。如下图所示。
可见，Selector.open()在Linux下不用TCP连接，而是用pipe管道。看来，这个pipe管道也是自己给自己的。所以，我们可以得出下面的结论：
1）Windows下，Selector.open()会自己和自己建立两条TCP链接。不但消耗了两个TCP连接和端口，同时也消耗了文件描述符。
2）Linux下，Selector.open()会自己和自己建两条管道。同样消耗了两个系统的文件描述符。
估计，在Windows下，Sun的JVM之所以选择TCP连接，而不是Pipe，要么是因为性能的问题，要么是因为资源的问题。可能，Windows下的管道的性能要慢于TCP链接，也有可能是Windows下的管道所消耗的资源会比TCP链接多。这些实现的细节还有待于更为深层次的挖掘。
但我们至少可以了解，原来Java的Selector在不同平台上的机制。