七、 真相大白 : 可爱的Java你太不容易了
使用Linux下的strace命令，我们可以方便地证明这一点。参看下图。图中，请注意下面几点：
1） 26654是主线程，之前我输出notify the select字符串是为了做一个标记，而不至于迷失在大量的strace log中。
2） 26662是侦听线程，也就是select阻塞的线程。
3） 图中选中的两行。26654的write正是wakeup()方法的系统调用，而紧接着的就是26662的epoll_wait的返回。
从上图可见，这和我们之前的猜想正好一样。可见，JDK的Selector自己和自己建的那些TCP连接或是pipe，正是用来实现Selector的notify和wakeup的功能的。
这两个方法完全是来模仿Linux中的的kill和pthread_kill给阻塞在select上的线程发信号的。但因为发信号这个东西并不是一个跨平台的标准（pthread_kill这个系统调用也不是所有Unix/Linux都支持的），而pipe是所有的Unix/Linux所支持的，但Windows又不支持，所以，Windows用了TCP连接来实现这个事。
关于Windows，我一直在想，Windows的防火墙的设置是不是会让Java的类似的程序执行异常呢？呵呵。如果不知道Java的SDK有这样的机制，谁知道会有多少个程序为此引起的问题度过多少个不眠之夜，尤其是Java程序员。
八、 后记
文章到这里是可以结束了，但关于Java NIO的Selector引出来的其它话题还有许多，比如关于GNU 的Java编译器又是如何，它是否会像Sun的Java解释器如此做傻事？我在这里先卖一个关子，关于GNU的Java编译器，我会在另外一篇文章中讲述，近期发布，敬请期待。
关于本文中所使用的实验平台如下：
· Windows：Windows XP + SP2, Sun J2SE (build 1.7.0-ea-b23)
· Linux：Ubuntu 7.10 + Linux Kernel 2.6.22-14-generic, J2SE (build 1.6.0_03-b05)