阻礙Java獲得廣泛應用的一個主要因素是Java程式的運行效率。Java是介於解釋型和編譯型之間的一種語言，同樣的程式，如果用編譯型語言C來實現，其運行速度一般要比Java快一倍以上。Java具有平臺無關性，這使人們在開發企業級應用的時候總是把它作爲主要候選方案之一，但是性能方面的因素又大大削弱了它的競爭力。爲此，提高Java的性能就顯得十分重要。 問題的提出 Sun公司及Java的支持者們爲提高Java的運行速度已經做出了許多努力，其中大多數集中在程式設計的方法和模式選擇方面。由於演算法和設計模式的優化是通用的，對Java有效的優化演算法和設計模式，對其他編譯語言也基本同樣適用，因此不能從根本上改變Java程式與編譯型語言在執行效率方面的差異。 JIT(Just In Time，及時編譯)技術是個比較好的思想。它的基本原理是：首先通過Java編譯器把Java源代碼編譯成平臺無關的二進位位元組碼。然後在Java程式真正執行之前，系統通過JIT編譯器把Java的位元組碼編譯爲本地化機器碼。最後，系統執行本地化機器碼，節省了對位元組碼進行解釋的時間。這樣做的優點是大大提高了Java程式的性能，縮短了載入程式的時間；同時，由於編譯的結果並不在程式運行間保存，因此也節約了存儲空間。缺點是由於JIT編譯器對所有的代碼都想優化，因此同樣也佔用了很多時間。 動態優化技術是提高Java性能的另一個嘗試。該技術試圖通過把Java根源程式直接編譯成機器碼，以充分利用Java動態編譯和靜態編譯技術來提高Java的性能。該方法把輸入的Java源碼或位元組碼轉換爲經過高度優化的可執行代碼和動態庫 (Windows中的. dll文件或Unix中的. so文件)。該技術能大大提高程式的性能，但卻破壞了Java的可攜性。 JNI技術 實際上，有一種通常爲我們忽視的技術可以在很大程度上解決這個難題，那就是JNI(Java Native Interface, Java本地化方法)。主張採用純Java的人們通常反對本地化代碼的使用，他們認爲在Java程式執行的過程中調用C/C++程式會影響程式的可攜性和安全性。還有一些人認爲JNI只是對過去混合編程技術的簡單擴展，其實際目的是爲了充分利用大量原有的C程式庫。 其實，我們不必拘泥於嚴格的平臺獨立性限制，因爲採用JNI技術只是針對一些嚴重影響Java性能的代碼段，該部分可能只占根源程式的極少部分，所以幾乎可以不考慮該部分代碼在主流平臺之間移植的工作量。同時，也不必過分擔心類型匹配問題，我們完全可以控制代碼不出現這種錯誤。此外，也不必擔心安全控制問題，因爲Java安全模型已擴展爲允許非系統類載入和調用本地方法。根據Java規範，從JDK 1. 2開始，FindClass將設法找到與當前的本地方法關聯的類載入器。如果平臺相關代碼屬於一個系統類，則無需涉及任何類載入器; 否則，將調用適當的類載入器來載入和鏈結已命名的類。換句話說，如果在Java程式中直接調用C/C++語言産生的機器碼，該部分代碼的安全性就由Java虛擬機控制。 JNI實現步驟 編寫JNI代碼的大致流程如下圖所示： JNI實現流程圖 1. 首先編寫需要JNI功能的Java類原始檔案。其中，需要JNI實現的方法應當用native關鍵字聲明。在該類中，用System. loadLibrary()方法載入需要的動態連結程式庫。關鍵代碼如下： //Compute.java …… public class Compute { public native double comp (double [] params); …… static { // 調用動態連結程式庫 System. loadLibrary(“mathlib”); } …… } 2. 將該類原始檔案用Java類編譯器編譯成二進位位元組碼文件。由於採用了native關鍵字聲明，編譯器會忽視沒有代碼體的JNI方法部分。 3. 利用javah -jni *.class 生成相關JNI方法的頭文件。我們可以手工生成該文件，但是由於Java虛擬機是根據一定的命名規範完成對JNI方法的調用，所以手工編寫頭文件需要特別小心。 上述文件産生的頭文件部分代碼如下： //Compute. h …… extern “C” { JNIEXPORT jdouble JNICALL Java_Compute_comp (JNIEnv *, jobject, jdoubleArray); } …… 可以看出，JNI函數名稱分爲三部分：首先是Java關鍵字，供Java虛擬機識別；然後是調用者類名稱（全限定的類名，其中用下劃線代替名稱分隔符號）；最後是對應的方法名稱，各段名稱之間用下劃線分割。 JNI函數的參數也由三部分組成: 首先是JNIEnv *，是一個指向JNI運行環境的指標；第二個參數隨本地方法是靜態還是非靜態而有所不同——非靜態本地方法的第二個參數是對物件的引用，而靜態本地方法的第二個參數是對其 Java 類的引用; 其餘的參數對應通常 Java 方法的參數，參數類型需要根據一定規則進行映射。 4. 根據頭文件編寫相應方法的實現代碼。由於篇幅所限，具體的實現部分在此不再贅述。在編碼過程中，需要注意變數的長度問題，例如Java的整型變數長度爲32位元，而C語言爲16位元，所以要仔細核對變數類型映射表，防止在傳值過程中出現問題。 5. 利用C/C++編譯器將JNI實現代碼編譯成動態連結程式庫。調用者類中需要顯式調用該程式庫。 在Win32環境下，可以利用Visual C ++或其他能産生DLL文件的C/C++編譯器將實現代碼編譯成動態連結程式庫。筆者利用的是Microsoft.NET Framework的編譯器。編譯指令如下，其中%Java_HOME%是筆者的jdk安裝目錄變數： cl -I%Java_HOME%\include -I%Java_HOME%\include\win32 -LD jnicomp. c -Femathlib. dll 在Sun Soloaris下，相應指令爲： cc -G -I/usr/local/java/include -I/usr/local/java/include/solaris jnicomp. c \ -o mathlib. so 注意，編譯的時候需要用I指令包含必要的庫文件路徑。 經過上述處理，就基本上完成了一個包含本地化方法的Java類的開發。 JNI技術的應用 一些主要的Java技術，如JDBC和RMI，大部分都採用JNI方式實現。但是，採用JNI確實會影響程式的平臺無關性，所以只能在特別需要的地方才能使用。 通常來說，如果遇到下面的情況，我們可以考慮JNI: ● 需要直接操作物理設備，而沒有相關的驅動程式，這時候我們可能需要用C甚至組合語言來編寫該設備的驅動，然後通過JNI調用； ● 涉及大量數學運算的部分，用Java會帶來些效率上的損失； ● 用Java會産生系統難以支付的開銷，如需要大量網路鏈結的場合； ● 存在大量可重用的C/C++代碼，通過JNI可以減少開發工作量，避免重復開發。 另外，在利用JNI技術的時候要注意以下幾點： ● 由於Java安全機制的限制，不要試圖通過Jar文件的方式發佈包含本地化方法的Applet到用戶端； ● 注意記憶體管理問題，雖然在本地方法返回 Java 後將自動釋放局部引用，但過多的局部引用將使虛擬機在執行本地方法時耗盡記憶體； ● JNI技術不僅可以讓Java程式調用C/C++代碼，也可以讓C/C++代碼調用Java代碼。 (出處:不明,知道者煩請告知) 討論區相關連結文章: http://delphi.ktop.com.tw/topic.php?topic_id=31934 http://delphi.ktop.com.tw/topic.php?topic_id=22052 發表人 - nlj859 於 2004/08/10 01:38:57

http://www2.ccw.com.cn/02/0203/c/0203c05_3.asp http://www.cooltang.com/box/topic/character/program/cn-java/0164.htm