1、利用實(shí)時(shí)Java設(shè)計(jì)數(shù)字音頻系統(tǒng)在傳統(tǒng)的信息技術(shù)領(lǐng)域，Java已成為首選的編程語(yǔ)言，因?yàn)樗芴岣唛_(kāi)發(fā)者的生產(chǎn)率、軟件復(fù)用率和可靠性，降低軟件維護(hù)成本，并提供更靈活、更通用的軟件結(jié)構(gòu)。 如今，在低級(jí)、硬件、實(shí)時(shí)軟件領(lǐng)域已有各種各樣的Java方案。但是，當(dāng)在像數(shù)字音頻信號(hào)處理這樣非常低級(jí)的軟件中應(yīng)用Java技術(shù)時(shí)，某些方案將更能發(fā)揮傳統(tǒng)Java技術(shù)的優(yōu)越性。 其中一種方法基于針對(duì)資源受限和安全關(guān)鍵的Java定義的推薦規(guī)范。設(shè)計(jì)該方案的主要目的是保持Java的可移植性、可維護(hù)性和可擴(kuò)展性?xún)?yōu)勢(shì)。在系統(tǒng)內(nèi)的信息流中包括兩臺(tái)計(jì)算機(jī)，這兩臺(tái)計(jì)算機(jī)協(xié)同操作以便通過(guò)網(wǎng)絡(luò)通訊通道交換音頻信息(圖1)。 在一個(gè)節(jié)點(diǎn)

2、上采集到的音頻信號(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ù)流。 這種簡(jiǎn)單的音頻處理應(yīng)用可以被當(dāng)作PERCPico應(yīng)用程序來(lái)實(shí)現(xiàn)。該軟件目前正在開(kāi)發(fā)中，它首次實(shí)現(xiàn)了針對(duì)安全關(guān)鍵和資源受限應(yīng)用所提出的實(shí)時(shí)Java(RTSJ)規(guī)范概要分析?！坝矊?shí)時(shí)概要分析(hardreal-timeprofile)”即指這種環(huán)境。 圖1：一個(gè)簡(jiǎn)單的數(shù)字音頻應(yīng)用構(gòu)成了本文討論的關(guān)鍵性軟件工程的基礎(chǔ)。維護(hù)和可擴(kuò)展性要求 摩爾定律推動(dòng)了典型嵌入式應(yīng)用的規(guī)模和復(fù)雜度快速增長(zhǎng)。競(jìng)爭(zhēng)壓力促使軟件不斷發(fā)展，以滿(mǎn)足

3、功能越來(lái)越強(qiáng)大的硬件的需求。對(duì)某些消費(fèi)電子設(shè)備的研究發(fā)現(xiàn)，新產(chǎn)品中代碼規(guī)模的增長(zhǎng)速度非常接近摩爾定律，大約每18至36個(gè)月就翻一番。 大約20年前，每個(gè)新的嵌入式設(shè)備中的所有軟件通常是由一個(gè)或兩個(gè)工程師在不到一年的時(shí)間內(nèi)寫(xiě)完。而現(xiàn)代嵌入式軟件的開(kāi)發(fā)則非常困難。假設(shè)每次新產(chǎn)品的軟件修訂都要求增加數(shù)十萬(wàn)，甚至數(shù)百萬(wàn)行的代碼，那么嵌入式軟件開(kāi)發(fā)人員的職責(zé)將更多地轉(zhuǎn)向如何解決集成許多獨(dú)立開(kāi)發(fā)的軟件組件所帶來(lái)的挑戰(zhàn)。 這個(gè)簡(jiǎn)單的數(shù)字音頻例子代表了一種原型的低級(jí)嵌入式軟件“產(chǎn)品”。對(duì)大多數(shù)產(chǎn)品而言，開(kāi)發(fā)原始軟件的成本要比整個(gè)產(chǎn)品生命周期內(nèi)的軟件維護(hù)成本小得多。以下列出了該應(yīng)用在產(chǎn)品生命周期內(nèi)的發(fā)展過(guò)程。

4、(1)軟件將需要被移植到不同的操作系統(tǒng)和不同的處理平臺(tái)上，這將改變它的CPU時(shí)間和內(nèi)存需求。 (2)軟件將與各種不同的補(bǔ)充功能集成在一起。也許下一代產(chǎn)品也將包括視頻信號(hào)。也許它將支持共享數(shù)字白板，以便于召開(kāi)遠(yuǎn)程會(huì)議，或者可能與電子郵件和日歷軟件集成在一起。或者，一些應(yīng)用可能增加錄制功能，以將會(huì)議實(shí)況保存在磁盤(pán)中。 (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)程序接口。音頻硬件本身有望繼

5、續(xù)發(fā)展，這要求軟件設(shè)備驅(qū)動(dòng)程序不斷發(fā)展。 (5)網(wǎng)絡(luò)通信協(xié)議可能需要作一些改變。在某些環(huán)境中，軟件將依賴(lài)底層操作系統(tǒng)服務(wù)來(lái)與網(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é)議棧?？梢圆捎脦_突檢測(cè)的載波偵聽(tīng)多路訪(fǎng)問(wèn)(CSMA/CD)技術(shù)、無(wú)線(xiàn)、光纖和其它有待發(fā)明的技術(shù)，在低成本專(zhuān)用串行通道、同軸電纜和雙絞線(xiàn)數(shù)據(jù)鏈接中實(shí)現(xiàn)相同的基礎(chǔ)通信能力。通信庫(kù)可能集成了壓縮、加密、檢錯(cuò)和糾錯(cuò)，以及滑動(dòng)窗口協(xié)議。 上面給出了軟件在商業(yè)化業(yè)務(wù)應(yīng)用中的幾種可能發(fā)

6、展方式，這里并非想窮舉所有的優(yōu)勢(shì)，只是為了說(shuō)明保留Java設(shè)計(jì)優(yōu)勢(shì)的好處，即使是對(duì)于一些資源受限和硬實(shí)時(shí)應(yīng)用來(lái)說(shuō)。 圖2：硬實(shí)時(shí)JAVA翻譯環(huán)境顯示了各種工具之間的關(guān)系，這些工具可使實(shí)時(shí)組件的開(kāi)發(fā)、維護(hù)和集成更容易。實(shí)時(shí)JAVA的能力 這些實(shí)時(shí)Java編程技術(shù)由RTSJ衍生發(fā)展而來(lái)。該規(guī)范具有很好通用性，能支持多種獨(dú)特的實(shí)時(shí)編程要求。由于本文主要關(guān)注非常低級(jí)的實(shí)時(shí)軟件，所以我們將開(kāi)發(fā)人員的操作限定在完整RTSJ規(guī)范的子集范疇內(nèi)。 這種概要分析可改善可移植性、可靠性和效率，因?yàn)樗故褂靡恍┬枰艽蟮倪\(yùn)行時(shí)間開(kāi)銷(xiāo)、會(huì)帶來(lái)不可移植的實(shí)現(xiàn)依賴(lài)性、增加軟件復(fù)雜度以致使程序員更容易出錯(cuò)的功能。硬實(shí)時(shí)概要

7、分析和完整RTSJ之間一些特殊差異包括： (1)完整的RTSJ對(duì)同步鎖采用優(yōu)先級(jí)繼承方法，并支持優(yōu)先級(jí)限高仿真可選。硬實(shí)時(shí)概要分析禁止使用優(yōu)先級(jí)繼承并要求支持優(yōu)先級(jí)限高仿真。 (2)完整的RTSJ允許即時(shí)修改各種線(xiàn)程調(diào)度和對(duì)象同步參數(shù)。硬實(shí)時(shí)概要分析禁止對(duì)線(xiàn)程調(diào)度和同步協(xié)議進(jìn)行即時(shí)調(diào)整。 (3)完整的RTSJ還支持一些機(jī)制，這樣每當(dāng)任務(wù)錯(cuò)過(guò)最終期限或超出其CPU時(shí)限時(shí)，就可以自動(dòng)觸發(fā)異步事件。請(qǐng)注意，這些服務(wù)的實(shí)現(xiàn)是完全不可移植的，而精確執(zhí)行會(huì)帶來(lái)極高的運(yùn)行時(shí)間開(kāi)銷(xiāo)。此外，在硬實(shí)時(shí)應(yīng)用中不需要運(yùn)行時(shí)間限制，因?yàn)樵诔绦驁?zhí)行之前，已經(jīng)靜態(tài)地滿(mǎn)足資源預(yù)算和最終期限要求。因此，硬實(shí)時(shí)概要分析不支持這些

8、機(jī)制。 (4)完整的RTSJ支持傳統(tǒng)線(xiàn)程、訪(fǎng)問(wèn)垃圾收集堆的實(shí)時(shí)線(xiàn)程，以及不訪(fǎng)問(wèn)垃圾收集堆的實(shí)時(shí)線(xiàn)程的混合體。這種不同線(xiàn)程類(lèi)型的混合大大增加了系統(tǒng)的復(fù)雜度和規(guī)模。這種復(fù)雜度將增加由于不同線(xiàn)程類(lèi)型之間不能正確共享信息而導(dǎo)致的實(shí)時(shí)編程出錯(cuò)的可能性，硬實(shí)時(shí)概要分析僅支持不訪(fǎng)問(wèn)垃圾收集堆的實(shí)時(shí)線(xiàn)程。 (5)完整的RTSJ提供一系列可供應(yīng)用程序員使用的庫(kù)，以便舉例說(shuō)明動(dòng)態(tài)內(nèi)存范圍，并在特定范圍內(nèi)分配對(duì)象。由于程序員在開(kāi)發(fā)或集成采用嵌套作用域(nested scope)的組件時(shí)可能會(huì)產(chǎn)生許多小錯(cuò)誤，所以這些庫(kù)的使用尤其成問(wèn)題。為執(zhí)行正確的區(qū)域性存儲(chǔ)器(scoped-memory)使用協(xié)議，RTSJ在每次讀取

9、和/或重寫(xiě)參考字段時(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)操作庫(kù)。相反，它要求程序員以編程注釋的形式描述其對(duì)作用域內(nèi)存(scoped-memory)的使用。在編譯期間，這些注釋可以被分析和執(zhí)行，例如本文應(yīng)用提到的Scoped和StaticAnalyzable注釋。 (6)RTSJ不會(huì)為了中斷處理或低級(jí)設(shè)備的I/O而對(duì)庫(kù)進(jìn)行標(biāo)準(zhǔn)化，而硬實(shí)時(shí)概要分析對(duì)這些庫(kù)進(jìn)行定義。 硬實(shí)時(shí)概要分析的商用

10、化前實(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簡(jiǎn)單得多，并且它還用編譯時(shí)間驗(yàn)證替代各種運(yùn)行時(shí)檢查。這種性能可以與相應(yīng)的C和C+程序相媲美，有時(shí)甚至更好。 盡管采用受限的硬實(shí)時(shí)概要分析比采用傳統(tǒng)Java更加困難，但這種平臺(tái)的代碼開(kāi)發(fā)和維護(hù)要比用C或C+開(kāi)發(fā)出的相應(yīng)平臺(tái)的維護(hù)容易。這是因?yàn)橛矊?shí)時(shí)Java平臺(tái)具有更好的可移植性，并提供高級(jí)的面向?qū)ο蟮某橄?。此外，硬?shí)時(shí)Java平臺(tái)包括可使實(shí)時(shí)組件的開(kāi)發(fā)、維護(hù)和集成更為容易的一些重要開(kāi)發(fā)工具(圖2)。 由于包含了強(qiáng)制嚴(yán)格遵守類(lèi)型安全的字節(jié)碼校驗(yàn)器，與C和C+相比，J

11、ava開(kāi)發(fā)可提高可靠性和可維護(hù)性。C和C+程序員可以利用多種讓使類(lèi)型安全無(wú)效的機(jī)制，而有意或無(wú)意地利用這些漏洞將使代碼更容易產(chǎn)生錯(cuò)誤，并降低可移植性。 受限的實(shí)時(shí)環(huán)境提供了比傳統(tǒng)Java更嚴(yán)格的字節(jié)碼驗(yàn)證。特別是，圖2中的硬實(shí)時(shí)驗(yàn)證器可確保指向堆棧分配對(duì)象的參數(shù)(指針)不會(huì)比對(duì)象本身的生存期更長(zhǎng)。它也確保用專(zhuān)用StaticAnalyzable注釋標(biāo)記的程序組件，可限制它們對(duì)可分析子集使用Java。與硬實(shí)時(shí)翻譯器的集成，則能提供確定執(zhí)行每個(gè)組件所需的CPU時(shí)間和堆棧內(nèi)存上限的能力。 執(zhí)行硬實(shí)時(shí)組件所需的所有臨時(shí)內(nèi)存分配，必須由正在執(zhí)行線(xiàn)程的運(yùn)行時(shí)棧來(lái)實(shí)現(xiàn)。執(zhí)行從單主線(xiàn)程開(kāi)始，而主線(xiàn)程的運(yùn)行時(shí)棧代

12、表了所有可重復(fù)使用的內(nèi)存。對(duì)于由主線(xiàn)程派生的每個(gè)附加線(xiàn)程，它提供了部分運(yùn)行時(shí)棧作為派生線(xiàn)程的運(yùn)行時(shí)棧。 圖3：該模塊圖說(shuō)明了SimpleAudio數(shù)字音頻應(yīng)用的體系結(jié)構(gòu)。數(shù)據(jù)音頻應(yīng)用的實(shí)現(xiàn) 圖3給出了數(shù)字音頻應(yīng)用的體系結(jié)構(gòu)。它共有6個(gè)線(xiàn)程，包括主線(xiàn)程和用Orchestrator實(shí)例表示的異步事件處理器。BufferPair將每個(gè)插座接口連接至相應(yīng)的DSP接口。主線(xiàn)程監(jiān)控用戶(hù)指令，并在用戶(hù)請(qǐng)求關(guān)閉會(huì)話(huà)時(shí)調(diào)用SimpleAudio實(shí)例的terminateActivity()方法。所有其它線(xiàn)程通過(guò)調(diào)用continueActivity()業(yè)務(wù)，定期輪詢(xún)SimpleAudio實(shí)例。到了關(guān)機(jī)時(shí)，該方法返回

13、false值。 在缺省配置中，該應(yīng)用以8kHz采樣頻率對(duì)麥克風(fēng)輸入進(jìn)行采樣，每次采樣采集8比特?cái)?shù)據(jù)。這種配置每秒鐘產(chǎn)生8k字節(jié)的數(shù)字音頻數(shù)據(jù)，這對(duì)簡(jiǎn)單的語(yǔ)音應(yīng)用來(lái)說(shuō)已經(jīng)足夠。但是，它不適合高保真立體聲信號(hào)。一般的CD錄制以44.1kHz的采樣頻率對(duì)兩個(gè)立體聲信道每次采樣16比特。這種高保真度信號(hào)的帶寬要求為176.4千字節(jié)/秒。 在缺省配置中，插槽讀模塊和寫(xiě)模塊采用足夠的帶寬進(jìn)行可靠傳輸，以可靠提供所有從DSPReader模塊采集的數(shù)據(jù)。我們采用了一種直接壓縮技術(shù)，一連串同樣的字節(jié)值(像出現(xiàn)在靜音期間的那樣)由一個(gè)專(zhuān)用的轉(zhuǎn)義(escape)值、重復(fù)次數(shù)和重復(fù)值表示。當(dāng)然，更先進(jìn)的壓縮技術(shù)將更為

14、合適。 在實(shí)時(shí)系統(tǒng)中，由抖動(dòng)描述特定實(shí)時(shí)組件的理想執(zhí)行時(shí)間的預(yù)期偏離，由一個(gè)確切的線(xiàn)程描述數(shù)字音頻應(yīng)用的每個(gè)組件。SocketWriter線(xiàn)程接收來(lái)自DSPReader模塊的原始數(shù)據(jù)流，對(duì)數(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每125s傳輸1字節(jié)數(shù)據(jù)。如果每秒的音頻數(shù)據(jù)有1個(gè)字節(jié)延遲半毫秒，則1小時(shí)后，累積延遲將約為2秒。為防止抖動(dòng)延遲的累積，該架構(gòu)包含一個(gè)運(yùn)行在16Hz的監(jiān)視線(xiàn)程。 在每個(gè)周期內(nèi)，該線(xiàn)程強(qiáng)制讓Soc

15、ketWriter和DSPWriter組件丟棄62.5ms之前的數(shù)據(jù)。由于我們處理的是音頻數(shù)據(jù)，所以通常來(lái)講，丟棄的臨時(shí)數(shù)據(jù)值比允許數(shù)據(jù)到達(dá)時(shí)間偏移更可取一些。人們通常不會(huì)注意到丟棄臨時(shí)數(shù)據(jù)字節(jié)的影響。 請(qǐng)注意在第1行出現(xiàn)的StaticAnalyzable注釋?zhuān)创a列表中的 StaticAnalyzable(enforce_time_analysis = false, enforce_non_blocking = false)。這代表了部分方法簽名(method signature)。注意該注釋給出了enforce_time_analysis 和enforce_non_blocking屬性的參

16、數(shù)值，兩者都是false。這表示該方法的實(shí)現(xiàn)無(wú)需將其本身限制在子集內(nèi)，對(duì)于該子集，靜態(tài)分析器可從中推斷執(zhí)行該方法所需要的嚴(yán)格CPU時(shí)間上限，也不要求靜態(tài)分析器驗(yàn)證該方法執(zhí)行時(shí)永遠(yuǎn)不會(huì)阻斷。 如果這些屬性定義沒(méi)有給出，硬實(shí)時(shí)驗(yàn)證器將認(rèn)為程序不合法，因?yàn)樵谠创a列表的(!orchestrator.destroy() through 57, 執(zhí)行時(shí)，靜態(tài)分析器無(wú)法確定該循環(huán)包含了多少次第55行。此外，main方法的執(zhí)行可能會(huì)在第59行的socket_ reader_thread.join()至63行的orchestrator_thread.join()之間阻斷，以及在第51行sa.awaitTermi

17、nation()調(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)存分配的上限就表示必需的主線(xiàn)程的運(yùn)行時(shí)棧大小。 注釋有助于軟件開(kāi)發(fā)，并大大簡(jiǎn)化軟件維護(hù)工作。通常，系統(tǒng)架構(gòu)師將復(fù)雜的系統(tǒng)功能分為較小的組件，以便由不同的開(kāi)發(fā)小組實(shí)現(xiàn)。因此，描述不同組件之間連接的接口定義，不僅詳細(xì)說(shuō)明了可以在組件間傳遞的

18、參數(shù)類(lèi)型，還包括在每個(gè)組件中必須實(shí)現(xiàn)的實(shí)時(shí)處理的限制，能減少軟件維護(hù)方面的開(kāi)銷(xiāo)。 對(duì)于現(xiàn)有軟件的修改必須遵從組件接口注釋中描述的所有其它特殊實(shí)時(shí)限制。如果軟件維護(hù)人員違反了這些接口要求，他們可以從字節(jié)碼驗(yàn)證器得到直接、明確的反饋。從而確?，F(xiàn)有大型實(shí)時(shí)軟件系統(tǒng)的不斷變化不會(huì)動(dòng)搖現(xiàn)有系統(tǒng)的穩(wěn)定性。 在對(duì)可靠運(yùn)行該主程序所需的堆棧內(nèi)存進(jìn)行分析時(shí)，靜態(tài)分析器必須確定在該方法以及該方法所調(diào)用的方法中，每個(gè)對(duì)象要求分配多大內(nèi)存。為了支持靜態(tài)分析結(jié)果的模塊化合成，字節(jié)碼驗(yàn)證器要求每個(gè)由主程序調(diào)用的方法被聲明為Static-Analyzable，而enforce_time_ analysis屬性設(shè)置為true

19、。快速?gòu)?fù)查main方法的實(shí)現(xiàn)可確保無(wú)限循環(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對(duì)象；每次分配描述了主程序派生的線(xiàn)程所使用的堆棧內(nèi)存。一般來(lái)說(shuō)，靜態(tài)分析工具可能難以確定可靠執(zhí)行這些子線(xiàn)程所必需的堆棧內(nèi)存數(shù)量。 每個(gè)ThreadStack構(gòu)造函數(shù)的參數(shù)為提供代碼由相應(yīng)線(xiàn)程執(zhí)行的類(lèi)(Class

20、)。靜態(tài)分析器要求每個(gè)在該環(huán)境中傳遞的NoHeapRealtimeThread子類(lèi)具有帶 StaticAnalyzable注釋?zhuān)襡nforce_ memory_analysis屬性設(shè)置為true的run()方法。如果ThreadStack構(gòu)造函數(shù)的參數(shù)并非來(lái)自BoundAsyncEventHandler(例如在Orchestrator類(lèi)的情況下)，則靜態(tài)分析器要求該類(lèi)的asyncEventHandler()方法采用StaticAnalyzable注釋來(lái)聲明，且enforce_memory_analysis屬性設(shè)置為true。 當(dāng)前線(xiàn)程的運(yùn)行時(shí)棧能滿(mǎn)足所有臨時(shí)內(nèi)存需要。請(qǐng)注意，我們?cè)诘?3行分

21、配了兩個(gè)臨時(shí)BufferPair實(shí)例，microphone_stream = new BufferPair()；而在第24行，speaker_stream = new Buffer-Pair()；然后這些對(duì)象的參數(shù)被傳遞至構(gòu)造函數(shù)，用于包含該軟件應(yīng)用的不同功能組件的各個(gè)線(xiàn)程。硬實(shí)時(shí)驗(yàn)證器實(shí)施的限制之一在于，stack-allocated對(duì)象的參數(shù)不能比引用參數(shù)的對(duì)象本身生存時(shí)間更長(zhǎng)，同樣是通過(guò)注釋機(jī)制來(lái)執(zhí)行。我們來(lái)看一下SocketReader類(lèi)的構(gòu)造函數(shù)：ScopedPureStaticAnalyzable(enforce_time_analysis = false, enforce_non

22、_blocking = false)SocketReader(SimpleAudio sa, Buffer-Pair buffers, String socket_name) throws FileNotFoundException ScopedPure注釋說(shuō)明該構(gòu)造函數(shù)的每個(gè)輸入引用參數(shù)(reference parameter)可以指代那些位于外部嵌套作用域的運(yùn)行時(shí)棧的對(duì)象。字節(jié)碼驗(yàn)證器確保這些參數(shù)的內(nèi)容絕不會(huì)復(fù)制到那些由于具有Scoped指派而未被同樣區(qū)分的變量上。 此外，它禁止將內(nèi)部嵌套作用域變量的值復(fù)制到外部嵌套作用域變量。一個(gè)例外情況是，在特殊環(huán)境下，它可證明帶參數(shù)對(duì)象位于與要賦值變量相同或更外層嵌套的作用域。如果這一構(gòu)造函數(shù)的參數(shù)未由Scoped注釋指定，字節(jié)碼驗(yàn)證器將不允許