利用實(shí)時(shí)Java設(shè)計(jì)數(shù)字音頻系統(tǒng)
掃描二維碼
隨時(shí)隨地手機(jī)看文章
如今，在低級(jí)、硬件、實(shí)時(shí)軟件領(lǐng)域已有各種各樣的Java方案。但是，當(dāng)在像數(shù)字音頻信號(hào)處理這樣非常低級(jí)的軟件中應(yīng)用Java技術(shù)時(shí)，某些方案將更能發(fā)揮傳統(tǒng)Java技術(shù)的優(yōu)越性。
其中一種方法基于針對資源受限和安全關(guān)鍵的Java定義的推薦規(guī)范。設(shè)計(jì)該方案的主要目的是保持Java的可移植性、可維護(hù)性和可擴(kuò)展性優(yōu)勢。在系統(tǒng)內(nèi)的信息流中包括兩臺(tái)計(jì)算機(jī)，這兩臺(tái)計(jì)算機(jī)協(xié)同操作以便通過網(wǎng)絡(luò)通訊通道交換音頻信息(圖1)。
在一個(gè)節(jié)點(diǎn)上采集到的音頻信號(hào)被傳輸至其它節(jié)點(diǎn)，并被輸出至遠(yuǎn)程計(jì)算機(jī)的揚(yáng)聲器。在第二個(gè)節(jié)點(diǎn)上采集到的音頻信號(hào)則在第一臺(tái)計(jì)算機(jī)的揚(yáng)聲器中輸出。從概念上講，信息流被構(gòu)造成兩個(gè)獨(dú)立的數(shù)字音頻數(shù)據(jù)流。
這種簡單的音頻處理應(yīng)用可以被當(dāng)作PERC Pico應(yīng)用程序來實(shí)現(xiàn)。該軟件目前正在開發(fā)中，它首次實(shí)現(xiàn)了針對安全關(guān)鍵和資源受限應(yīng)用所提出的實(shí)時(shí)Java(RTSJ)規(guī)范概要分析?！坝矊?shí)時(shí)概要分析(hard real-time profile)”即指這種環(huán)境。
 |
| 圖1：一個(gè)簡單的數(shù)字音頻應(yīng)用構(gòu)成了本文討論的關(guān)鍵性軟件工程的基礎(chǔ)。 |
維護(hù)和可擴(kuò)展性要求
摩爾定律推動(dòng)了典型嵌入式應(yīng)用的規(guī)模和復(fù)雜度快速增長。競爭壓力促使軟件不斷發(fā)展，以滿足功能越來越強(qiáng)大的硬件的需求。對某些消費(fèi)電子設(shè)備的研究發(fā)現(xiàn)，新產(chǎn)品中代碼規(guī)模的增長速度非常接近摩爾定律，大約每18至36個(gè)月就翻一番。
大約20年前，每個(gè)新的嵌入式設(shè)備中的所有軟件通常是由一個(gè)或兩個(gè)工程師在不到一年的時(shí)間內(nèi)寫完。而現(xiàn)代嵌入式軟件的開發(fā)則非常困難。假設(shè)每次新產(chǎn)品的軟件修訂都要求增加數(shù)十萬，甚至數(shù)百萬行的代碼，那么嵌入式軟件開發(fā)人員的職責(zé)將更多地轉(zhuǎn)向如何解決集成許多獨(dú)立開發(fā)的軟件組件所帶來的挑戰(zhàn)。
這個(gè)簡單的數(shù)字音頻例子代表了一種原型的低級(jí)嵌入式軟件“產(chǎn)品”。對大多數(shù)產(chǎn)品而言，開發(fā)原始軟件的成本要比整個(gè)產(chǎn)品生命周期內(nèi)的軟件維護(hù)成本小得多。以下列出了該應(yīng)用在產(chǎn)品生命周期內(nèi)的發(fā)展過程。
(1)軟件將需要被移植到不同的操作系統(tǒng)和不同的處理平臺(tái)上，這將改變它的CPU時(shí)間和內(nèi)存需求。
(2)軟件將與各種不同的補(bǔ)充功能集成在一起。也許下一代產(chǎn)品也將包括視頻信號(hào)。也許它將支持共享數(shù)字白板，以便于召開遠(yuǎn)程會(huì)議，或者可能與電子郵件和日歷軟件集成在一起。或者，一些應(yīng)用可能增加錄制功能，以將會(huì)議實(shí)況保存在磁盤中。
(3)雙節(jié)點(diǎn)網(wǎng)絡(luò)拓?fù)淇赡苄枰M(jìn)行通用化，以支持有任意多參加者的會(huì)議。
(4)模數(shù)轉(zhuǎn)換器(ADC)和數(shù)字信號(hào)處理器(DSP)的接口可以不斷發(fā)展。在一些配置中，操作系統(tǒng)提供了這種服務(wù)。而在其它配置中，這種應(yīng)用可能包括連接音頻子系統(tǒng)硬件和DMA內(nèi)存設(shè)備的設(shè)備驅(qū)動(dòng)程序接口。音頻硬件本身有望繼續(xù)發(fā)展，這要求軟件設(shè)備驅(qū)動(dòng)程序不斷發(fā)展。
(5)網(wǎng)絡(luò)通信協(xié)議可能需要作一些改變。在某些環(huán)境中，軟件將依賴底層操作系統(tǒng)服務(wù)來與網(wǎng)絡(luò)連接。隨著各種網(wǎng)絡(luò)通信協(xié)議的發(fā)展，連接操作系統(tǒng)網(wǎng)絡(luò)業(yè)務(wù)的接口甚至也可能發(fā)生變化，以便提供新的QoS參數(shù)和更高帶寬。在其它情況下，這種應(yīng)用將需要包含面向硬件接口的低級(jí)設(shè)備驅(qū)動(dòng)程序，也可能需要實(shí)現(xiàn)通信協(xié)議棧?？梢圆捎脦_突檢測的載波偵聽多路訪問(CSMA/CD)技術(shù)、無線、光纖和其它有待發(fā)明的技術(shù)，在低成本專用串行通道、同軸電纜和雙絞線數(shù)據(jù)鏈接中實(shí)現(xiàn)相同的基礎(chǔ)通信能力。通信庫可能集成了壓縮、加密、檢錯(cuò)和糾錯(cuò)，以及滑動(dòng)窗口協(xié)議。
上面給出了軟件在商業(yè)化業(yè)務(wù)應(yīng)用中的幾種可能發(fā)展方式，這里并非想窮舉所有的優(yōu)勢，只是為了說明保留Java設(shè)計(jì)優(yōu)勢的好處，即使是對于一些資源受限和硬實(shí)時(shí)應(yīng)用來說。
 |
| 圖2：硬實(shí)時(shí)JAVA翻譯環(huán)境顯示了各種工具之間的關(guān)系，這些工具可使實(shí)時(shí)組件的開發(fā)、維護(hù)和集成更容易。 |
實(shí)時(shí)JAVA的能力
這些實(shí)時(shí)Java編程技術(shù)由RTSJ衍生發(fā)展而來。該規(guī)范具有很好通用性，能支持多種獨(dú)特的實(shí)時(shí)編程要求。由于本文主要關(guān)注非常低級(jí)的實(shí)時(shí)軟件，所以我們將開發(fā)人員的操作限定在完整RTSJ規(guī)范的子集范疇內(nèi)。
這種概要分析可改善可移植性、可靠性和效率，因?yàn)樗故褂靡恍┬枰艽蟮倪\(yùn)行時(shí)間開銷、會(huì)帶來不可移植的實(shí)現(xiàn)依賴性、增加軟件復(fù)雜度以致使程序員更容易出錯(cuò)的功能。硬實(shí)時(shí)概要分析和完整RTSJ之間一些特殊差異包括：
(1)完整的RTSJ對同步鎖采用優(yōu)先級(jí)繼承方法，并支持優(yōu)先級(jí)限高仿真可選。硬實(shí)時(shí)概要分析禁止使用優(yōu)先級(jí)繼承并要求支持優(yōu)先級(jí)限高仿真。
(2)完整的RTSJ允許即時(shí)修改各種線程調(diào)度和對象同步參數(shù)。硬實(shí)時(shí)概要分析禁止對線程調(diào)度和同步協(xié)議進(jìn)行即時(shí)調(diào)整。
(3)完整的RTSJ還支持一些機(jī)制，這樣每當(dāng)任務(wù)錯(cuò)過最終期限或超出其CPU時(shí)限時(shí)，就可以自動(dòng)觸發(fā)異步事件。請注意，這些服務(wù)的實(shí)現(xiàn)是完全不可移植的，而精確執(zhí)行會(huì)帶來極高的運(yùn)行時(shí)間開銷。此外，在硬實(shí)時(shí)應(yīng)用中不需要運(yùn)行時(shí)間限制，因?yàn)樵诔绦驁?zhí)行之前，已經(jīng)靜態(tài)地滿足資源預(yù)算和最終期限要求。因此，硬實(shí)時(shí)概要分析不支持這些機(jī)制。
(4)完整的RTSJ支持傳統(tǒng)線程、訪問垃圾收集堆的實(shí)時(shí)線程，以及不訪問垃圾收集堆的實(shí)時(shí)線程的混合體。這種不同線程類型的混合大大增加了系統(tǒng)的復(fù)雜度和規(guī)模。這種復(fù)雜度將增加由于不同線程類型之間不能正確共享信息而導(dǎo)致的實(shí)時(shí)編程出錯(cuò)的可能性，硬實(shí)時(shí)概要分析僅支持不訪問垃圾收集堆的實(shí)時(shí)線程。
(5)完整的RTSJ提供一系列可供應(yīng)用程序員使用的庫，以便舉例說明動(dòng)態(tài)內(nèi)存范圍，并在特定范圍內(nèi)分配對象。由于程序員在開發(fā)或集成采用嵌套作用域(nested scope)的組件時(shí)可能會(huì)產(chǎn)生許多小錯(cuò)誤，所以這些庫的使用尤其成問題。為執(zhí)行正確的區(qū)域性存儲(chǔ)器(scoped-memory)使用協(xié)議，RTSJ在每次讀取和/或重寫參考字段時(shí)都執(zhí)行特殊的運(yùn)行時(shí)檢查。在完整的RTSJ中，運(yùn)行時(shí)進(jìn)行檢查會(huì)使程序組件出錯(cuò)，從而使得程序由于非法分配、非法讀取、區(qū)域性存儲(chǔ)器協(xié)議錯(cuò)誤、內(nèi)存不足錯(cuò)誤等原因，以運(yùn)行時(shí)間異常方式終止執(zhí)行。硬實(shí)時(shí)概要分析禁止使用RTSJ內(nèi)存作用域(memory scope)操作庫。相反，它要求程序員以編程注釋的形式描述其對作用域內(nèi)存(scoped-memory)的使用。在編譯期間，這些注釋可以被分析和執(zhí)行，例如本文應(yīng)用提到的@Scoped和@StaticAnalyzable注釋。
(6)RTSJ不會(huì)為了中斷處理或低級(jí)設(shè)備的I/O而對庫進(jìn)行標(biāo)準(zhǔn)化，而硬實(shí)時(shí)概要分析對這些庫進(jìn)行定義。
硬實(shí)時(shí)概要分析的商用化前實(shí)現(xiàn)試驗(yàn)顯示，它運(yùn)行在某些CPU密集型基準(zhǔn)程序的速度比標(biāo)準(zhǔn)Java和完整RTSJ的速度快三倍。這是因?yàn)橛矊?shí)時(shí)執(zhí)行環(huán)境比標(biāo)準(zhǔn)RTSJ簡單得多，并且它還用編譯時(shí)間驗(yàn)證替代各種運(yùn)行時(shí)檢查。這種性能可以與相應(yīng)的C和C++程序相媲美，有時(shí)甚至更好。
盡管采用受限的硬實(shí)時(shí)概要分析比采用傳統(tǒng)Java更加困難，但這種平臺(tái)的代碼開發(fā)和維護(hù)要比用C或C++開發(fā)出的相應(yīng)平臺(tái)的維護(hù)容易。這是因?yàn)橛矊?shí)時(shí)Java平臺(tái)具有更好的可移植性，并提供高級(jí)的面向?qū)ο蟮某橄?。此外，硬?shí)時(shí)Java平臺(tái)包括可使實(shí)時(shí)組件的開發(fā)、維護(hù)和集成更為容易的一些重要開發(fā)工具(圖2)。
由于包含了強(qiáng)制嚴(yán)格遵守類型安全的字節(jié)碼校驗(yàn)器，與C和C++相比，Java開發(fā)可提高可靠性和可維護(hù)性。C和C++程序員可以利用多種讓使類型安全無效的機(jī)制，而有意或無意地利用這些漏洞將使代碼更容易產(chǎn)生錯(cuò)誤，并降低可移植性。
受限的實(shí)時(shí)環(huán)境提供了比傳統(tǒng)Java更嚴(yán)格的字節(jié)碼驗(yàn)證。特別是，圖2中的硬實(shí)時(shí)驗(yàn)證器可確保指向堆棧分配對象的參數(shù)(指針)不會(huì)比對象本身的生存期更長。它也確保用專用@StaticAnalyzable注釋標(biāo)記的程序組件，可限制它們對可分析子集使用Java。與硬實(shí)時(shí)翻譯器的集成，則能提供確定執(zhí)行每個(gè)組件所需的CPU時(shí)間和堆棧內(nèi)存上限的能力。
執(zhí)行硬實(shí)時(shí)組件所需的所有臨時(shí)內(nèi)存分配，必須由正在執(zhí)行線程的運(yùn)行時(shí)棧來實(shí)現(xiàn)。執(zhí)行從單主線程開始，而主線程的運(yùn)行時(shí)棧代表了所有可重復(fù)使用的內(nèi)存。對于由主線程派生的每個(gè)附加線程，它提供了部分運(yùn)行時(shí)棧作為派生線程的運(yùn)行時(shí)棧。
 |
| 圖3：該模塊圖說明了SimpleAudio數(shù)字音頻應(yīng)用的體系結(jié)構(gòu)。 |
數(shù)據(jù)音頻應(yīng)用的實(shí)現(xiàn)
圖3給出了數(shù)字音頻應(yīng)用的體系結(jié)構(gòu)。它共有6個(gè)線程，包括主線程和用Orchestrator實(shí)例表示的異步事件處理器。BufferPair將每個(gè)插座接口連接至相應(yīng)的DSP接口。主線程監(jiān)控用戶指令，并在用戶請求關(guān)閉會(huì)話時(shí)調(diào)用SimpleAudio實(shí)例的terminateActivity()方法。所有其它線程通過調(diào)用continueActivity()業(yè)務(wù)，定期輪詢SimpleAudio實(shí)例。到了關(guān)機(jī)時(shí)，該方法返回false值。
在缺省配置中，該應(yīng)用以8kHz采樣頻率對麥克風(fēng)輸入進(jìn)行采樣，每次采樣采集8比特?cái)?shù)據(jù)。這種配置每秒鐘產(chǎn)生8k字節(jié)的數(shù)字音頻數(shù)據(jù)，這對簡單的語音應(yīng)用來說已經(jīng)足夠。但是，它不適合高保真立體聲信號(hào)。一般的CD錄制以44.1kHz的采樣頻率對兩個(gè)立體聲信道每次采樣16比特。這種高保真度信號(hào)的帶寬要求為176.4千字節(jié)/秒。
在缺省配置中，插槽讀模塊和寫模塊采用足夠的帶寬進(jìn)行可靠傳輸，以可靠提供所有從DSPReader模塊采集的數(shù)據(jù)。我們采用了一種直接壓縮技術(shù)，一連串同樣的字節(jié)值(像出現(xiàn)在靜音期間的那樣)由一個(gè)專用的轉(zhuǎn)義(escape)值、重復(fù)次數(shù)和重復(fù)值表示。當(dāng)然，更先進(jìn)的壓縮技術(shù)將更為合適。
在實(shí)時(shí)系統(tǒng)中，由抖動(dòng)描述特定實(shí)時(shí)組件的理想執(zhí)行時(shí)間的預(yù)期偏離，由一個(gè)確切的線程描述數(shù)字音頻應(yīng)用的每個(gè)組件。SocketWriter線程接收來自DSPReader模塊的原始數(shù)據(jù)流，對數(shù)據(jù)進(jìn)行壓縮，并將數(shù)據(jù)傳送至網(wǎng)絡(luò)插座通道。如果網(wǎng)絡(luò)插座通道的帶寬有限，只能達(dá)到預(yù)算的8千字節(jié)/秒，那么任何導(dǎo)致SocketWriter延遲數(shù)據(jù)傳輸?shù)亩秳?dòng)影響將隨著時(shí)間而累積。
在缺省配置中，預(yù)計(jì)SocketWriter每125µs傳輸1字節(jié)數(shù)據(jù)。如果每秒的音頻數(shù)據(jù)有1個(gè)字節(jié)延遲半毫秒，則1小時(shí)后，累積延遲將約為2秒。為防止抖動(dòng)延遲的累積，該架構(gòu)包含一個(gè)運(yùn)行在16Hz的監(jiān)視線程。
在每個(gè)周期內(nèi)，該線程強(qiáng)制讓SocketWriter和DSPWriter組件丟棄62.5ms之前的數(shù)據(jù)。由于我們處理的是音頻數(shù)據(jù)，所以通常來講，丟棄的臨時(shí)數(shù)據(jù)值比允許數(shù)據(jù)到達(dá)時(shí)間偏移更可取一些。人們通常不會(huì)注意到丟棄臨時(shí)數(shù)據(jù)字節(jié)的影響。
請注意在第1行出現(xiàn)的@StaticAnalyzable注釋，源碼列表中的@ StaticAnalyzable(enforce_time_analysis = {false}, enforce_non_blocking = {false})。這代表了部分方法簽名(method signature)。注意該注釋給出了enforce_time_analysis 和enforce_non_blocking屬性的參數(shù)值，兩者都是false。這表示該方法的實(shí)現(xiàn)無需將其本身限制在子集內(nèi)，對于該子集，靜態(tài)分析器可從中推斷執(zhí)行該方法所需要的嚴(yán)格CPU時(shí)間上限，也不要求靜態(tài)分析器驗(yàn)證該方法執(zhí)行時(shí)永遠(yuǎn)不會(huì)阻斷。
如果這些屬性定義沒有給出，硬實(shí)時(shí)驗(yàn)證器將認(rèn)為程序不合法，因?yàn)樵谠创a列表的(!orchestrator.destroy()) { through 57, }執(zhí)行時(shí)，靜態(tài)分析器無法確定該循環(huán)包含了多少次第55行。此外，main方法的執(zhí)行可能會(huì)在第59行的socket_ reader_thread.join()至63行的orchestrator_thread.join()之間阻斷，以及在第51行sa.awaitTermination()調(diào)用的await-Termination()方法中阻斷。
在@StaticAnalyzable注釋中未注明的是enforce_memory_analysis屬性的值。該屬性的缺省值為true，這意味著該方法的實(shí)現(xiàn)必須符合限定的指導(dǎo)方針以使執(zhí)行該方法時(shí)靜態(tài)分析器能夠確定將要分配的最大內(nèi)存。假設(shè)該環(huán)境的實(shí)時(shí)Java規(guī)則將內(nèi)存作為運(yùn)行棧的一部分，則臨時(shí)內(nèi)存分配的上限就表示必需的主線程的運(yùn)行時(shí)棧大小。
注釋有助于軟件開發(fā)，并大大簡化軟件維護(hù)工作。通常，系統(tǒng)架構(gòu)師將復(fù)雜的系統(tǒng)功能分為較小的組件，以便由不同的開發(fā)小組實(shí)現(xiàn)。因此，描述不同組件之間連接的接口定義，不僅詳細(xì)說明了可以在組件間傳遞的參數(shù)類型，還包括在每個(gè)組件中必須實(shí)現(xiàn)的實(shí)時(shí)處理的限制，能減少軟件維護(hù)方面的開銷。
對于現(xiàn)有軟件的修改必須遵從組件接口注釋中描述的所有其它特殊實(shí)時(shí)限制。如果軟件維護(hù)人員違反了這些接口要求，他們可以從字節(jié)碼驗(yàn)證器得到直接、明確的反饋。從而確?，F(xiàn)有大型實(shí)時(shí)軟件系統(tǒng)的不斷變化不會(huì)動(dòng)搖現(xiàn)有系統(tǒng)的穩(wěn)定性。
在對可靠運(yùn)行該主程序所需的堆棧內(nèi)存進(jìn)行分析時(shí)，靜態(tài)分析器必須確定在該方法以及該方法所調(diào)用的方法中，每個(gè)對象要求分配多大內(nèi)存。為了支持靜態(tài)分析結(jié)果的模塊化合成，字節(jié)碼驗(yàn)證器要求每個(gè)由主程序調(diào)用的方法被聲明為@Static-Analyzable，而enforce_time_ analysis屬性設(shè)置為true?？焖購?fù)查main方法的實(shí)現(xiàn)可確保無限循環(huán)內(nèi)不產(chǎn)生分配。這是字節(jié)碼驗(yàn)證器所要執(zhí)行的任務(wù)之一。
在第37行的socket_reader_thread = new Thread-Stack(SocketReader.class)；到41行的orchestrator_thread = new ThreadStack(Orchestrator.class)之間分配了幾個(gè)新的ThreadStack對象；每次分配描述了主程序派生的線程所使用的堆棧內(nèi)存。一般來說，靜態(tài)分析工具可能難以確定可靠執(zhí)行這些子線程所必需的堆棧內(nèi)存數(shù)量。
每個(gè)ThreadStack構(gòu)造函數(shù)的參數(shù)為提供代碼由相應(yīng)線程執(zhí)行的類(Class)。靜態(tài)分析器要求每個(gè)在該環(huán)境中傳遞的NoHeapRealtimeThread子類具有帶@ StaticAnalyzable注釋，且enforce_ memory_analysis屬性設(shè)置為true的run()方法。如果ThreadStack構(gòu)造函數(shù)的參數(shù)并非來自BoundAsyncEventHandler(例如在Orchestrator類的情況下)，則靜態(tài)分析器要求該類的asyncEventHandler()方法采用@StaticAnalyzable注釋來聲明，且enforce_memory_analysis屬性設(shè)置為true。
當(dāng)前線程的運(yùn)行時(shí)棧能滿足所有臨時(shí)內(nèi)存需要。請注意，我們在第23行分配了兩個(gè)臨時(shí)BufferPair實(shí)例，microphone_stream = new BufferPair()；而在第24行，speaker_stream = new Buffer-Pair()；然后這些對象的參數(shù)被傳遞至構(gòu)造函數(shù)，用于包含該軟件應(yīng)用的不同功能組件的各個(gè)線程。硬實(shí)時(shí)驗(yàn)證器實(shí)施的限制之一在于，stack-allocated對象的參數(shù)不能比引用參數(shù)的對象本身生存時(shí)間更長，同樣是通過注釋機(jī)制來執(zhí)行。我們來看一下SocketReader類的構(gòu)造函數(shù)：
@ScopedPure
@StaticAnalyzable(enforce_time_analysis = {false}, enforce_non_blocking = {false})
SocketReader(SimpleAudio sa, Buffer-Pair buffers, String socket_name) throws
FileNotFoundException
@ScopedPure注釋說明該構(gòu)造函數(shù)的每個(gè)輸入引用參數(shù)(reference parameter)可以指代那些位于外部嵌套作用域的運(yùn)行時(shí)棧的對象。字節(jié)碼驗(yàn)證器確保這些參數(shù)的內(nèi)容絕不會(huì)復(fù)制到那些由于具有@Scoped指派而未被同樣區(qū)分的變量上。
此外，它禁止將內(nèi)部嵌套作用域變量的值復(fù)制到外部嵌套作用域變量。一個(gè)例外情況是，在特殊環(huán)境下，它可證明帶參數(shù)對象位于與要賦值變量相同或更外層嵌套的作用域。如果這一構(gòu)造函數(shù)的參數(shù)未由@Scoped注釋指定，字節(jié)碼驗(yàn)證器將不允許主程序?qū)?shù)傳至堆棧分配的BufferPair和SimpleAudio對象。
本應(yīng)用展示的RTSJ支持的實(shí)時(shí)編程抽象之一為PeriodicTimer類。注意，本應(yīng)用在第49行舉例說明了PeriodicTimer對象，drumbeat = new PeriodicTimer(start_time, period, orchestrator)；并將結(jié)果賦值給本地drumbeat變量。參數(shù)之一為orchestrator對象的引用參數(shù)，其本身是BoundAsyncEventHandler的一個(gè)實(shí)例。該drumbeat周期計(jì)時(shí)器被設(shè)置為每秒觸發(fā)orchestrator對象的handleAsyncEvent()方法執(zhí)行16次，即每62.5微秒一次。
采用C或C++語言的實(shí)時(shí)開發(fā)人員可以實(shí)現(xiàn)這些實(shí)時(shí)Java技術(shù)所支持的許多相同構(gòu)造。但是，C或C++程序員必須產(chǎn)生懸掛指針(dangling pointer)以及內(nèi)存泄漏，他們還缺乏標(biāo)準(zhǔn)工具的支持來自動(dòng)分析執(zhí)行時(shí)間和堆棧大小。
另外，C和C++程序員還缺乏完整性檢查以確保方法的實(shí)現(xiàn)能夠滿足文檔化實(shí)時(shí)接口的要求，并確保方法調(diào)用能夠傳遞同樣滿足文檔接口要求的參數(shù)。最后，在對現(xiàn)在軟件系統(tǒng)進(jìn)行維護(hù)的過程中，C和C++程序員沒有工具支持來保證對現(xiàn)有軟件的修改與在原軟件開發(fā)過程中假設(shè)的各種組成要求是相符的。
傳統(tǒng)Java在生產(chǎn)效率和成本上具有許多優(yōu)勢。規(guī)范地使用實(shí)時(shí)Java技術(shù)可提供許多這樣的優(yōu)勢。與使用C和C++相比，一般Java程序員在新代碼開發(fā)期間具有2倍的生產(chǎn)率，而在現(xiàn)在軟件維護(hù)期間具有5到10倍的生產(chǎn)率。隨著嵌入實(shí)時(shí)軟件的大小和復(fù)雜度增加，這些激發(fā)人們向更現(xiàn)代的軟件工程技術(shù)(如由實(shí)時(shí)Java實(shí)現(xiàn)的工程技術(shù))轉(zhuǎn)化的因素已越來越重要了。
下載文檔
