Java NIO 類庫Selector機制解析（續）

在前些天的《 Java NIO類庫Selector機制解析 》文章中，咱們知道了下面的事情：

 

1）Sun的JVM在實現Selector上，在Linux和Windows平臺下的細節。

2）Selector類的wakeup()方法如何喚醒阻塞在select()系統調用上的細節。

 

先給你們作一個簡單的回顧，在Windows下，Sun的Java虛擬機在Selector.open()時會本身和本身創建loopback的TCP連接；在Linux下，Selector會建立pipe。這主要是爲了Selector.wakeup()能夠方便喚醒阻塞在select()系統調用上的線程（經過向本身所創建的TCP連接和管道上隨便寫點什麼就能夠喚醒阻塞線程）

 

咱們知道，不管是創建TCP連接仍是創建管道都會消耗系統資源，而在Windows上，某些Windows上的防火牆設置還可能會致使Java的Selector由於創建不起loopback的TCP連接而出現異常。

 

而在個人另外一篇文章《 用GDB調試Java程序 》中介紹了另外一個Java的解釋器——GNU的gij，以及編譯器gcj，不但能夠比較高效地運行Java程序，並且還能夠把Java程序直接編譯成可執行文件。

 

GNU的之因此要重作一個Java的編譯和解釋器，其一個重要緣由就是想解釋Sun的JVM的效率和資源耗費問題。固然，GNU的Java編譯/解釋器並不須要考慮太多複雜的平臺，他們只須要專一於Linux和衍生自Unix System V的操做系統，對於開發人員來講，離開了Windows，一切都會變得簡單起來。在這裏，讓咱們看看GNU的gij是如何解釋Selector.open()和Selector.wakeup()的。

 

一樣，咱們須要一個測試程序。在這裏，爲了清晰，我不會例出全部的代碼，我只給出我所使用的這個程序的一些關鍵代碼。

 

個人這個測試程序中，和全部的Socket程序同樣，下面是一個比較標準的框架，固然，這個框架應該是在一個線程中，也就是一個須要繼承Runnable接口，並實現run()方法的一個類。（注意：其中的s是一個成員變量，是Selector類型，以便主線程序使用）

 

 

        // 生成一個偵聽端

        ServerSocketChannel ssc = ServerSocketChannel.open();

        // 將偵聽端設爲異步方式

        ssc.configureBlocking(false);

        // 生成一個信號監視器

        s = Selector.open();

        // 偵聽端綁定到一個端口

        ssc.socket().bind(new InetSocketAddress(port));

        // 設置偵聽端所選的異步信號 OP_ACCEPT

        ssc.register(s,SelectionKey.OP_ACCEPT);

  

        System.out.println("echo server has been set up ......");

 

        while(true){

            int n = s.select();

            if (n == 0) { // 沒有指定的 I/O 事件發生

               continue;

            }    

            Iterator it = s.selectedKeys().iterator();    

            while (it.hasNext()) {

                SelectionKey key = (SelectionKey) it.next();

                if (key.isAcceptable()) { // 偵聽端信號觸發

                     …… …… ……

                     …… …… ……

                }  

                if (key.isReadable()) { // 某 socket 可讀信號

                     …… …… ……

                     …… …… ……                   

                }    

                it.remove();

            }

         }

 

而在主線程中，咱們能夠經過Selector.wakeup()來喚醒這個阻塞在select()上的線程，下面是寫在主線程中的喚醒程序：

 

 

new Thread(this).start();

try{

    //Sleep 30 seconds

    Thread.sleep(30000);

    System.out.println("wakeup the select");

    s.wakeup();

}catch(Exception e){

        e.printStackTrace();

}

 

 

這個程序在主線程中，先啓動一個線程，也就是上面那個Socket線程，而後休息30秒，爲的是讓上面的那個線程有阻塞在select()，而後打印出一條信息，這是爲了咱們用strace命令查看具體的系統調用時可以快速定位。以後調用的是Selector的wakeup()方法來喚醒偵聽線程。

 

接下來，咱們能夠經過兩種方式來編譯這個程序：

1）使用gcj或是sun的javac編譯成class文件，而後使用gij解釋執行。

2）使用gcj直接編譯成可執行文件。

（不管你用那種方法，都是同樣的結果，本文使用第二種方法，關於gcj的編譯方法，請參看個人《 用GDB調試Java程序 》）

 

編譯成可執行文件後，執行程序時，使用lsof命令，咱們能夠看到沒有任何pipe的創建。可見GNU的解釋更爲的節省資源。而對於一個Unix的C程序員來講，這意味着若是要喚醒select()只能使用pthread_kill()來發送一個信號了。下面就讓咱們使用strace命令來驗證這個想法。

 

下圖是使用strace命令來跟蹤整個程序運行時的系統調用，咱們利用咱們的輸出的「wakeup the select」字符串快速的找到了wakeup的實際系統調用。

 

 

果真，咱們可能夠看到，tgkill(5829, 5831, SIGHUP)這個系統調用，第一個參數是「源線程id」，第二個參數是「目的線程id」，第三個參數是「信號SIGHUP」。經過每一行前面的線程號咱們能夠看到緊接着tgkill後面的5831線程的「… select resumed」字樣。

 

可見，GNU的確是使用最爲傳統的pthread_kill或kill系統調用向阻塞線程發信號的方法來實現Selector.wakeup()的，這也證實了GNU的Java編譯/解釋器是不會消耗系統文件描述符的。而咱們也終於看到了迴歸經典的Java實現機制。

 

歡迎使用MSN和郵件和我聯繫： [email]haoel@hotmail.com[/email] 。