Java在嵌入式系統(tǒng)中的解決方案

　　A)性能

　　如前所述、解釋Java字節(jié)碼比相當(dāng)?shù)腃或C++寫的程序運(yùn)行起來要慢5到10倍。對(duì)一些并非受制于CPU的嵌入系統(tǒng)來說，這一個(gè)性能缺點(diǎn)不是問題，但是更經(jīng)常的較慢的速度會(huì)導(dǎo)致無(wú)法接受的應(yīng)答時(shí)間。有幾種可能的解決方案可緩解速度慢的問題。

　　1)使用更快、更強(qiáng)大的處理器，使系統(tǒng)響應(yīng)時(shí)間縮小到可以接受的范圍。這個(gè)方法將增加每個(gè)系統(tǒng)的成本。

　　2)使用母語(yǔ)Java編譯器來獲得比較好的性能。但這樣做，你就放棄了與Java平臺(tái)無(wú)關(guān)的優(yōu)點(diǎn)，好在大多數(shù)嵌入系統(tǒng)都只在一種平臺(tái)上運(yùn)行。

　　3)在你的系統(tǒng)上并入一個(gè)JIT編譯器，這樣Java類裝入時(shí)就被編譯。若你為接納JIT編譯器而不得不增加額外的內(nèi)存，這個(gè)方法也會(huì)增加系統(tǒng)成本。另外，若你的系統(tǒng)各部分是按需求逐漸添加，你應(yīng)控制程序裝入的時(shí)機(jī)，以使在裝入類進(jìn)行編譯時(shí)產(chǎn)生的暫停不會(huì)影響系統(tǒng)的響應(yīng)時(shí)間。

　　B)垃圾收集的系統(tǒng)開銷

　　前面論述過，Java中的自動(dòng)內(nèi)存分配和垃圾收集性能是實(shí)惠的，因?yàn)樗サ袅俗钔ǔ５某绦蝈e(cuò)誤根源并簡(jiǎn)化了程序設(shè)計(jì)人員的工作。但是，從實(shí)時(shí)系統(tǒng)的角度來看，它的問題恰好就在于它是自動(dòng)的。當(dāng)垃圾收集進(jìn)行時(shí)，你的控制就受限了。

　　垃圾收集運(yùn)行時(shí)，它凍結(jié)了系統(tǒng)其余部分的處理。這是因?yàn)樗仨氁趦?nèi)存中移動(dòng)對(duì)象，并必須在程序再次運(yùn)行前，更新所有引用(指向)那些對(duì)象的程序變量。垃圾收集能凍結(jié)處理達(dá)數(shù)十分之一秒，具體取決于內(nèi)存量和處理器的速度。很顯然，這對(duì)硬實(shí)時(shí)系統(tǒng)是無(wú)法接受的，甚至極端時(shí)對(duì)軟實(shí)時(shí)系統(tǒng)也是成問題的。

　　垃圾收集以三種方式開啟。首先JVM有一個(gè)后臺(tái)垃圾收集線程，此線程傾向于在它一看見系統(tǒng)有空閑就開始垃圾收集，若有事件想要喚醒另一個(gè)線程，后臺(tái)垃圾收集就會(huì)被該線程占先，但它不會(huì)立刻被占先，它得更新那些已被移動(dòng)得對(duì)象的所有引用后，才能讓一個(gè)線程運(yùn)行。

　　其次，若JVM沒找到足夠內(nèi)存來滿足某個(gè)內(nèi)存分配請(qǐng)求，它將啟動(dòng)一個(gè)不會(huì)被占先的垃圾收集，在該操作完成之前，系統(tǒng)的其余部分被禁止。

　　最后，一個(gè)應(yīng)用程序能通過調(diào)用Systev.gc()方法來啟動(dòng)垃圾收集。所有，如果你知道系統(tǒng)暫時(shí)不會(huì)執(zhí)行任何時(shí)序上關(guān)鍵的任務(wù)，你可以啟動(dòng)垃圾收集，并希望避免稍后在更關(guān)鍵時(shí)段進(jìn)行收集。

　　C) JVM的系統(tǒng)開銷

　　我們已經(jīng)論述了許多JVM的內(nèi)置特點(diǎn)，比如圖形和網(wǎng)絡(luò)，它們使得你的Java程序更快上市。所有這些特點(diǎn)的負(fù)面是JVM的內(nèi)存開銷。因?yàn)镴VM是一個(gè)整塊(要達(dá)到Java的可移植的目的，你必須完整的采納)，JVM的內(nèi)存占用量不能減少?，F(xiàn)在的JVM最少需要2MB以上的內(nèi)存。

　　但是如果你的Java程序也在使用一些消耗內(nèi)存的功能，由于一個(gè)JVM中有那么多的功能，各個(gè)Java應(yīng)用程序就能寫的小一點(diǎn)。如果你建立的是一個(gè)從網(wǎng)絡(luò)上動(dòng)態(tài)下載并運(yùn)行多個(gè)程序的系統(tǒng)，那么這將是個(gè)很大的優(yōu)點(diǎn)。但Java仍然不具備可配置性和可伸縮性，而這些是嵌入操作系統(tǒng)一直以老字號(hào)自居的特點(diǎn)。

　　D)硬件訪問

　　Java實(shí)現(xiàn)可移植性的安全性的方法也意味著它缺乏直接同硬件接口的能力。JVM僅僅是一個(gè)虛擬的機(jī)器，一個(gè)對(duì)硬件的軟件抽象，該抽象僅僅使連接是直接的。虛擬機(jī)控制與實(shí)際硬件的接口，而我們只能和虛擬機(jī)打交道。

　　但這并非無(wú)法逾越的限制，很多C程序使用內(nèi)嵌匯編來規(guī)避性能上的瓶頸，所以Java程序也能使用C來獲得對(duì)硬件的直接訪問。

　　讓Java和C一起工作有兩種方式。第一、可以使用本地方式，它們是用C/C++或另一種語(yǔ)言寫的，但當(dāng)調(diào)用時(shí)，則裝入與JVM同樣的內(nèi)存空間，運(yùn)行于同樣的環(huán)境。因?yàn)樗鼈儽痪幾g成機(jī)器碼，本地方式運(yùn)行更快并能直接訪問硬件。本地過程與Java代碼之間通過套接來彼此交流，就像網(wǎng)絡(luò)中通信端點(diǎn)使用的套接一樣。在你選擇了混合語(yǔ)言方法后，Java的與平臺(tái)無(wú)關(guān)和安全特點(diǎn)就沒有了。

　　可以考慮將前面提到的Java處理器作為軟件JVM的解釋器部分作為一種硬件實(shí)現(xiàn)方案。Java程序能在這些處理器上直接運(yùn)行并操縱硬件，要注意Sun必需加一些特殊目的的指令給這種語(yǔ)言才能直接與這些處理器一起工作。

　　E) 語(yǔ)言尚不夠成熟

　　Java于1996年5月發(fā)布，幾個(gè)月就有了beta版。第一個(gè)主要修訂版，Java Development Kit(JDK)1.1在一年以后開發(fā)出來，以標(biāo)準(zhǔn)的程序設(shè)計(jì)語(yǔ)言角度來看，Java還很年輕，也很粗糙。實(shí)際上，所有通用語(yǔ)言，都要幾年時(shí)間才能夠成熟到能可靠的寫出作為產(chǎn)品的應(yīng)用程序的程度。

　　在其進(jìn)一步發(fā)展中，Sun公司分了三個(gè)步驟來促進(jìn)Java成為一種通用語(yǔ)言和計(jì)算機(jī)平臺(tái)。首先，用Java編程實(shí)現(xiàn)現(xiàn)存的商業(yè)和企業(yè)的一些功能活動(dòng)，諸如電子郵件、日歷和字處理程序。在這些方面，Java將與傳統(tǒng)的編程語(yǔ)言和傳統(tǒng)的編程方法競(jìng)爭(zhēng)。其次，把Java提供給企業(yè)，使他成為一種編寫內(nèi)部應(yīng)用程序的方法。信息科學(xué)部門常常要用一種必須編譯的(因而是針對(duì)具體平臺(tái)的)語(yǔ)言來產(chǎn)生客戶程序，因此由于平臺(tái)不同而編譯和維護(hù)不同的版本。如使用Java，信息科學(xué)部門只需編寫和維護(hù)一種版本。最后一步，是為傳統(tǒng)嵌入式設(shè)備應(yīng)用，比如移動(dòng)電話、機(jī)頂盒以及打印機(jī)定義Java API以及語(yǔ)言功能。

　　Java開發(fā)的編程工具也仍在發(fā)展之中。有幾個(gè)廠家提供編譯器和開發(fā)工具，如Symantec、Microsoft以及Sun公司。Sun不再是JVM和JIT的僅有選擇，其他幾個(gè)供應(yīng)商的產(chǎn)品也很有競(jìng)爭(zhēng)力，這些公司在開發(fā)檢測(cè)和調(diào)試工具上較慢。市場(chǎng)上有了一些初步的產(chǎn)品， Parasoft的Jtest軟件自動(dòng)為Java模塊生成檢測(cè)案例，而Numega的Jcheck為JVM中的程序行為提供一定的可見性。

　　目前仍然沒有完善的交叉調(diào)試解決方案，即那種傳統(tǒng)上被嵌入系統(tǒng)開發(fā)者用來處理目標(biāo)平臺(tái)上程序的方案，你很可能必須用C/C++來寫你的程序中針對(duì)硬件的部分。不管怎樣，你最好用一個(gè)C/C++交互調(diào)試器來調(diào)試那些代碼，并在你的目標(biāo)系統(tǒng)上用彈出對(duì)話框，保持記錄文件，或其他類技巧來調(diào)試你的Java。

　　4、總結(jié)

　　由上可見，Java的嵌入式應(yīng)用是排在Sun公司日程的最后的，Sun在繼續(xù)為這些用途發(fā)展此語(yǔ)言，但對(duì)這方面的發(fā)展會(huì)次于桌面及企業(yè)用途。