這篇是筆者打算寫的J2se部分的最后一篇了,這篇結束之后,再寫J2ee部分,不知道是否還合適寫在這個版塊?大家可以給點意見,謝謝大家對小弟這么鼓勵一路寫完前六篇Java雜談的J2se部分。最后這篇打算談一談Java中的RMI機制和JVM沙箱安全框架。  

        1.   Java中的RMI機制  
        RMI的全稱是遠程方法調用,相信不少朋友都聽說過,基本的思路可以用一個經典比方來解釋:A計算機想要計算一個兩個數的加法,但A自己做不了,于是叫另外一臺計算機B幫忙,B有計算加法的功能,A調用它就像調用這個功能是自己的一樣方便。這個就叫做遠程方法調用了。  
         
        遠程方法調用是EJB實現的支柱,建立分布式應用的核心思想。這個很好理解,再拿上面的計算加法例子,A只知道去call計算機B的方法,自己并沒有B的那些功能,所以A計算機端就無法看到B執行這段功能的過程和代碼,因為看都看不到,所以既沒有機會竊取也沒有機會去改動方法代碼。EJB正式基于這樣的思想來完成它的任務的。當簡單的加法變成復雜的數據庫操作和電子商務交易應用的時候,這樣的安全性和分布式應用的便利性就表現出來優勢了。  

        好了,回到細節上,要如何實現遠程方法調用呢?我希望大家學習任何技術的時候可以試著依賴自己的下意識判斷,只要你的想法是合理健壯的,那么很可能實際上它就是這么做的,畢竟真理都蘊藏在平凡的生活細節中。這樣只要帶著一些薄弱的Java基礎來思考RMI,其實也可以想出個大概來。  
         
        a)   需要有一個服務器角色,它擁有真正的功能代碼方法。例如B,它提供加法服務  
        b)   如果想遠程使用B的功能,需要知道B的IP地址  
        c)   如果想遠程使用B的功能,還需要知道B中那個特定服務的名字  

        我們很自然可以想到這些,雖然不完善,但已經很接近正確的做法了。實際上RMI要得以實現還得意于Java一個很重要的特性,就是Java反射機制。我們需要知道服務的名字,但又必須隱藏實現的代碼,如何去做呢?答案就是:接口!  
        舉個例子:  
        public   interface   Person(){  
public   void   sayHello();  
        }  

        Public   class   PersonImplA   implements   Person{  
public   PersonImplA(){}  

public   void   sayHello(){     System.out.println(“Hello!”);}  
        }  

        Public   class   PersonImplB   implements   Person{  
public   PersonImplB(){}  

public   void   sayHello(){     System.out.println(“Nice   to   meet   you!”);}  
        }  

        客戶端:Person   p   =   Naming.lookup(“PersonService”);  
      p.sayHello();  

        就這幾段代碼就包含了幾乎所有的實現技術,大家相信么?客戶端請求一個say   hello服務,服務器運行時接到這個請求,利用Java反射機制的Class.newInstance()返回一個對象,但客戶端不知道服務器返回的是 ImplA還是ImplB,它接受用的參數簽名是Person,它知道實現了Person接口的對象一定有sayHello()方法,這就意味著客戶端并不知道服務器真正如何去實現的,但它通過了解Person接口明確了它要用的服務方法名字叫做sayHello()。  

        如此類推,服務器只需要暴露自己的接口出來供客戶端,所有客戶端就可以自己選擇需要的服務。這就像餐館只要拿出自己的菜單出來讓客戶選擇,就可以在后臺廚房一道道的按需做出來,它怎么做的通常是不讓客戶知道的!(祖傳菜譜吧,^_^)  

        最后一點是我調用lookup,查找一個叫PersonService名字的對象,服務器只要看到這個名字,在自己的目錄(相當于電話簿)中找到對應的對象名字提供服務就可以了,這個目錄就叫做JNDI   (Java命名與目錄接口),相信大家也聽過的。  

        有興趣的朋友不妨自己做個RMI的應用,很多前輩的博客中有簡單的例子。提示一下利用Jdk的bin目錄中rmi.exe和 rmiregistry.exe兩個命令就可以自己建起一個服務器,提供遠程服務。因為例子很容易找,我就不自己舉例子了!  

        2.   JVM沙箱&框架  
        RMI羅唆得太多了,實在是盡力想把它說清楚,希望對大家有幫助。最后的最后,給大家簡單講一下JVM框架,我們叫做Java沙箱。Java沙箱的基本組件如下:  
        a)   類裝載器結構      
        b)   class文件檢驗器      
        c)   內置于Java虛擬機的安全特性  
        d)   安全管理器及Java   API  

      其中類裝載器在3個方面對Java沙箱起作用:  
        a.   它防止惡意代碼去干涉善意的代碼  
        b.   它守護了被信任的類庫邊界  
        c.   它將代碼歸入保護域,確定了代碼可以進行哪些操作  

        虛擬機為不同的類加載器載入的類提供不同的命名空間,命名空間由一系列唯一的名稱組成,每一個被裝載的類將有一個名字,這個命名空間是由Java虛擬機為每一個類裝載器維護的,它們互相之間甚至不可見。  
         
        我們常說的包(package)是在Java虛擬機第2版的規范第一次出現,正確定義是由同一個類裝載器裝載的、屬于同一個包、多個類型的集合。類裝載器采用的機制是雙親委派模式。具體的加載器框架我在Java雜談(一)中已經解釋過了,當時說最外層的加載器是AppClassLoader,其實算上網絡層的話AppClassLoader也可以作為parent,還有更外層的加載器URLClassLoader。為了防止惡意攻擊由URL加載進來的類文件我們當然需要分不同的訪問命名空間,并且制定最安全的加載次序,簡單來說就是兩點:  
         
        a.   從最內層JVM自帶類加載器開始加載,外層惡意同名類得不到先加載而無法使用  
        b.   由于嚴格通過包來區分了訪問域,外層惡意的類通過內置代碼也無法獲得權限訪問到內層類,破壞代碼就自然無法生效。  

        附:關于Java的平臺無關性,有一個例子可以很明顯的說明這個特性:  
        一般來說,C或C++中的int占位寬度是根據目標平臺的字長來決定的,這就意味著針對不同的平臺編譯同一個C++程序在運行時會有不同的行為。然而對于 Java中的int都是32位的二進制補碼標識的有符號整數,而float都是遵守IEEE   754浮點標準的32位浮點數。  
     
        PS:   這個小弟最近也沒時間繼續研究下去了,只是想拋磚引玉的提供給大家一個初步認識JVM的印象。有機會了解一下JVM的內部結構對今后做Java開發是很有好處的。