王同洋，趙 磊

華中科技大學(xué)，湖北武漢 430074

0 引言

智能卡（Smartcard）在包括電信、銀行、公交、醫(yī)療、身份證件、數(shù)字電視、安全認(rèn)證等與普通消費(fèi)者息息相關(guān)的領(lǐng)域均獲得了廣泛的應(yīng)用。在未來(lái)移動(dòng)支付、信用卡等更加普及、對(duì)個(gè)人信息安全有更高訴求的時(shí)代，智能卡仍將發(fā)揮不可替代的重要作用。

傳統(tǒng)的Native卡存在先天缺陷，概括為如下3點(diǎn)：

1）應(yīng)用開(kāi)發(fā)的難度大、周期長(zhǎng)、成本高：native卡以匯編或C語(yǔ)言進(jìn)行開(kāi)發(fā)，缺乏通用開(kāi)發(fā)平臺(tái)，開(kāi)發(fā)、調(diào)試?yán)щy，要求開(kāi)發(fā)人員對(duì)硬件的底層細(xì)節(jié)熟悉；

2）不能很好的支持跨行業(yè)應(yīng)用和一卡多用，而一卡多用是智能卡發(fā)展的趨勢(shì)；

3）應(yīng)用在卡發(fā)行時(shí)便已經(jīng)固定下來(lái)，無(wú)法實(shí)現(xiàn)應(yīng)用的更新或升級(jí)，無(wú)法滿足客戶個(gè)性化的需求，也使供應(yīng)商在增值服務(wù)方面無(wú)法有所作為；

Native卡在互操作性和多功能應(yīng)用上的不足，在應(yīng)用開(kāi)發(fā)時(shí)的高難度、高成本已經(jīng)成為限制智能卡進(jìn)一步發(fā)展的最大障礙。在探索如何解決這些矛盾的過(guò)程中，以Sun為代表的公司開(kāi)始嘗試將更通用和安全的Java平臺(tái)引入智能卡行業(yè)，Java卡便應(yīng)運(yùn)而生。

1 Java智能卡平臺(tái)

Java卡是一種可以運(yùn)行Java程序的微處理器智能卡，在卡中運(yùn)行的程序叫Java Card Applet。Applet可以由用戶動(dòng)態(tài)裝載到卡上。Java卡是Java體系中最小的一個(gè)平臺(tái)，Applet可以在任何符合Java卡規(guī)范的卡上運(yùn)行，主要規(guī)范包括：Java卡虛擬機(jī)規(guī)范（JCVM），編程接口規(guī)范（API）和運(yùn)行時(shí)環(huán)境規(guī)范（JCRE），目前最新的規(guī)范是3.0版本。

1.1 Java卡體系結(jié)構(gòu)及優(yōu)點(diǎn)

1.1.1 Java卡體系結(jié)構(gòu)

Java卡的內(nèi)部結(jié)構(gòu)由 COS、Native Functions、Java VM、Java Framework 以及架構(gòu)在此上的應(yīng)用程序Applet所構(gòu)成，Java卡內(nèi)部結(jié)構(gòu)如圖1所示：

圖1 Java卡體系結(jié)構(gòu)

1.1.2 Java卡虛擬機(jī)結(jié)構(gòu)

與Java平臺(tái)相同，Java卡實(shí)現(xiàn)跨平臺(tái)和高安全的關(guān)鍵是虛擬機(jī)，同樣受限與硬件資源，Java卡虛擬機(jī)（JCVM）和普通Java虛擬機(jī)（JVM）的最重要的區(qū)別就在于JCVM是一個(gè)分離的結(jié)構(gòu)——卡外和卡內(nèi)虛擬機(jī)：

圖2 Java卡虛擬機(jī)分離模型

如圖2所示：卡外虛擬機(jī)部分主要包括一個(gè)converter，它運(yùn)行在PC或者工作站，主要用來(lái)裝載和預(yù)處理輸入的class文件，并將其轉(zhuǎn)化輸出為一種Java卡字節(jié)碼文件（即CAP，Converted Applet）；卡內(nèi)虛擬機(jī)部分包括Java卡字節(jié)碼解釋器Interpreter，用來(lái)解釋執(zhí)行Java卡字節(jié)碼文件。兩者結(jié)合，就構(gòu)成了完整的Java卡虛擬機(jī)，它們?cè)诳ㄍ獍惭b程序和卡上安裝器的共同工作下，完成CAP文件下載、安裝過(guò)程，如圖3所示：

圖3 CAP文件下載安裝過(guò)程

1.1.3 Java卡優(yōu)點(diǎn)

Java卡的優(yōu)點(diǎn)可以概括如下：

1）平臺(tái)無(wú)關(guān)性和互操作性：通過(guò)Java卡虛擬機(jī)技術(shù)實(shí)現(xiàn)了跨平臺(tái)和互操作的能力；

2）支持一卡多用，應(yīng)用的動(dòng)態(tài)下載及管理；

3）通用和開(kāi)放：Java卡不但兼容了現(xiàn)有的智能卡行業(yè)標(biāo)準(zhǔn)，它還提供了一整套標(biāo)準(zhǔn)的API，使智能卡應(yīng)用開(kāi)發(fā)回到主流的面向?qū)ο缶幊?，開(kāi)發(fā)人員無(wú)需了解復(fù)雜的智能卡硬件和專用技術(shù)；

4）安全：Java卡繼承了Java語(yǔ)言的安全特性，包括原子事務(wù)、應(yīng)用防火墻等，從而提供了一個(gè)安全高效的執(zhí)行環(huán)境。

1.2 Java智能卡內(nèi)存管理和對(duì)象管理

1.2.1 Java卡內(nèi)存管理模型和對(duì)象類型

作為低端嵌入式設(shè)備的Java卡，內(nèi)存是最寶貴的資源。通常在Java卡內(nèi)有3種存儲(chǔ)體：

1）ROM：通常存儲(chǔ)有Java卡虛擬機(jī)、API類庫(kù)、卡內(nèi)操作系統(tǒng)和卡商預(yù)先裝入的applet等，并在發(fā)卡前將它們掩膜到ROM中；

2）RAM：斷電后數(shù)據(jù)丟失，因此用來(lái)存儲(chǔ)暫態(tài)數(shù)據(jù)，包括局部變量、方法參數(shù)、中間運(yùn)算結(jié)果等；

3）EEPROM：用來(lái)存儲(chǔ)持久數(shù)據(jù)，包括下載到卡中的applet class和創(chuàng)建的持久對(duì)象。

目前在Java卡中執(zhí)行應(yīng)用時(shí)，Java卡虛擬機(jī)調(diào)用new指令創(chuàng)建對(duì)象，并默認(rèn)存儲(chǔ)于EEPROM中。對(duì)象包括兩類：

1）暫態(tài)對(duì)象（Transient Object），它分為兩種類型：CLEAR_ ON_RESET和CLEAR_ON_DESELECT。通過(guò)調(diào)用Java卡API來(lái)創(chuàng)建，并存儲(chǔ)在RAM中，斷電后對(duì)象的字段（field）值、字段類型等數(shù)據(jù)自動(dòng)丟失。CLEAR_ON_RESET類型的對(duì)象在一次會(huì)話期間或進(jìn)行applet選擇切換時(shí)會(huì)保存下來(lái)，但進(jìn)行復(fù)位操作時(shí)被復(fù)位為默認(rèn)值；而CLEAR_ON_DESELECT類型的對(duì)象無(wú)論是復(fù)位操作還是applet選擇切換，都無(wú)法保存。對(duì)暫態(tài)對(duì)象的操作不是原子的；

2）持久對(duì)象（Persistent Object）：由new操作符創(chuàng)建，并默認(rèn)存儲(chǔ)在EEPROM中，它在卡被拔出后依然存在。對(duì)持久對(duì)象數(shù)據(jù)的操作必須是原子的，即更新操作要么全部完成，要么中斷更新并回滾恢復(fù)到原來(lái)的狀態(tài)；

無(wú)論是暫態(tài)對(duì)象還是持久對(duì)象，當(dāng)沒(méi)有其他任何對(duì)象引用它時(shí)，該對(duì)象就不再可以訪問(wèn)，也就成為垃圾，但它們所占據(jù)的空間只有被回收后才能再次利用。

1.2.2 現(xiàn)有模型的性能問(wèn)題

在字節(jié)碼文件下載解析過(guò)程中，以及虛擬機(jī)執(zhí)行應(yīng)用的過(guò)程中都遭遇了性能問(wèn)題，而其中消耗絕大部分執(zhí)行時(shí)間的是EEPROM寫(xiě)操作，原因總結(jié)如下：

1）為了支持持久對(duì)象的原子性操作，保證數(shù)據(jù)的完整性，Java卡在EEPROM中開(kāi)辟了一塊特殊的存儲(chǔ)區(qū)域來(lái)存儲(chǔ)原有的數(shù)據(jù)，以執(zhí)行數(shù)據(jù)的回滾。將舊有數(shù)據(jù)寫(xiě)入Transaction-Buffer的次數(shù)占據(jù)了所有EEPROM寫(xiě)操作的75%～80%，而寫(xiě)EEPROM的時(shí)間為3ms～10ms，比RAM慢1 000倍；

2）寫(xiě)EEPROM操作采用了機(jī)制，即先將數(shù)據(jù)寫(xiě)入Page-Buffer，然后再寫(xiě)入EEPROM，清除Page-Buffer后再重復(fù)下一次的寫(xiě)過(guò)程。這種寫(xiě)入—?jiǎng)h除—再寫(xiě)入的機(jī)制在大量寫(xiě)操作時(shí)是十分緩慢的；

3）在下載CAP文件時(shí)，對(duì)常量池等組件的解析過(guò)程在EEPROM中完成。同樣的，虛擬機(jī)在執(zhí)行applet實(shí)例的時(shí)候，大部分對(duì)象的創(chuàng)建也是在EEPROM中完成，兩者都產(chǎn)生了大量的EEPROM寫(xiě)操作。

2 優(yōu)化技術(shù)的探討

2.1 已有的典型優(yōu)化技術(shù)

為了解決Java卡的性能問(wèn)題，研究人員提出了一些典型優(yōu)化方法，分析歸納如下：

1）在Java卡虛擬機(jī)分離模型的基礎(chǔ)上，采用分離模式的CAP文件解析優(yōu)化方案，即將靜態(tài)解析過(guò)程放在卡外執(zhí)行，該過(guò)程只訪問(wèn)CAP文件，而無(wú)需訪問(wèn)卡內(nèi)資源。將動(dòng)態(tài)解析過(guò)程留在卡內(nèi)進(jìn)行，該過(guò)程必須獲得卡內(nèi)資源才能完成解析。最后設(shè)計(jì)一種偽指令集來(lái)銜接優(yōu)化后的解析執(zhí)行過(guò)程 ；

2） 改 進(jìn)Java卡 已 有 的 事 務(wù)（transaction） 機(jī) 制，將Transaction-Buffer分配在RAM中，并將事務(wù)開(kāi)始后的新數(shù)據(jù)寫(xiě)入這個(gè)Buffer。如果事務(wù)順利完成，則將其中的數(shù)據(jù)寫(xiě)入EEPROM并替換舊數(shù)據(jù)；如果事務(wù)中斷，比如卡被拔出等，由于RAM的易失性，Buffer中的數(shù)據(jù)自然消失，而EEPROM中原始的數(shù)據(jù)也并沒(méi)有被更改，也就保證了數(shù)據(jù)的完整性。該方法大大減少了對(duì)EEPROM的寫(xiě)操作，很好的提高了應(yīng)用的執(zhí)行性能。不足之處是加大了對(duì)本就稀有的RAM資源的開(kāi)銷；

3）引入cache策略，改進(jìn)傳統(tǒng)的寫(xiě)EEPROM機(jī)制。這個(gè)方法的基礎(chǔ)是Java卡在執(zhí)行應(yīng)用期間，寫(xiě)操作的數(shù)據(jù)擁有高度的局部相似特性（即cache擁有較高的命中率），基于這個(gè)特性，在傳統(tǒng)的Page-buffer的基礎(chǔ)上在RAM中增加一個(gè)Object-buffer，并通過(guò)引入cache策略，從而在大量寫(xiě)操作發(fā)生的時(shí)候可以大幅度提高性能；

4）改進(jìn)對(duì)象模型，將applet實(shí)例和靜態(tài)數(shù)據(jù)成員之外的大部分對(duì)象都存儲(chǔ)在RAM中，而非傳統(tǒng)的EEPROM中。該方法需要在編寫(xiě)applet時(shí)考慮到數(shù)據(jù)的持久性要求，如事務(wù)平衡值，并將這些數(shù)據(jù)成員的類型設(shè)為static，從而將其保存在永久性的EEPROM中。需要指出的是該方法對(duì)RAM空間有較高的要求[5]；

5）采用壓縮算法對(duì)字節(jié)碼文件進(jìn)行優(yōu)化或?qū)ψ止?jié)碼文件中的Method組件的指令碼進(jìn)行折疊優(yōu)化。但這些方法對(duì)有標(biāo)準(zhǔn)格式要求的字節(jié)碼而言，優(yōu)化的空間有限且往往會(huì)產(chǎn)生優(yōu)化的負(fù)效應(yīng)[6]。

2.2 優(yōu)化方向的探索

2.2.1 優(yōu)化的目標(biāo)

1）提高應(yīng)用的下載、安裝速度：減少CAP解析過(guò)程對(duì)EEPROM的寫(xiě)操作次數(shù)，從而提高Java卡對(duì)CAP文件的下載解析速度；

2）提高應(yīng)用的執(zhí)行性能：減少applet生命周期過(guò)程中對(duì)EEPROM的寫(xiě)操作次數(shù)，提高applet的執(zhí)行性能；

3）提高內(nèi)存使用率：減少內(nèi)存碎片和提高空間回收效率，從而更加高效的利用寶貴的Java卡內(nèi)存資源。

2.2.2 可行的技術(shù)方案

1）實(shí)現(xiàn)新的對(duì)象模型和新的堆存儲(chǔ)區(qū)模型，保證有一種合理的算法實(shí)現(xiàn)對(duì)EEPROM（或Flash）和RAM堆空間的高效管理；

2）優(yōu)化傳統(tǒng)的事務(wù)機(jī)制，在保證持久對(duì)象的原子性和一部分敏感暫態(tài)數(shù)據(jù)的安全性的同時(shí)，減少事務(wù)機(jī)制帶來(lái)的性能負(fù)效應(yīng)；

3）探索一種能用于智能卡的合理高效的cache算法，配合寫(xiě)入策略（Normal Write & Tear-Proof Write）來(lái)優(yōu)化現(xiàn)有的EEPROM寫(xiě)入機(jī)制；

4）圍繞對(duì)象模型，對(duì)現(xiàn)有的Java卡堆棧操作指令，以及涉及對(duì)象管理和事務(wù)機(jī)制的API進(jìn)行分析，對(duì)其中實(shí)現(xiàn)效率不高的進(jìn)行優(yōu)化、合并或擴(kuò)展，或直接在底層用native代碼實(shí)現(xiàn)，從字節(jié)碼指令層提高應(yīng)用的執(zhí)行性能；

5）設(shè)計(jì)一種新的CAP文件解析策略，結(jié)合RAM空間的使用，減少在CAP文件下載和安裝過(guò)程中對(duì)EEPROM的寫(xiě)操作，提高下載和解析的速度。

2.2.3 技術(shù)方案的評(píng)估

在設(shè)計(jì)新的算法或方案對(duì)Java卡平臺(tái)進(jìn)行優(yōu)化之后，需要有一個(gè)合理的評(píng)估方案實(shí)現(xiàn)對(duì)優(yōu)化結(jié)果的測(cè)評(píng)以考察其有效性[7]。性能評(píng)估從兩個(gè)方面進(jìn)行：

1）Java卡正常使用（事務(wù)正常完成）的應(yīng)用執(zhí)行性能，需對(duì)如下幾個(gè)方面進(jìn)行測(cè)評(píng)：

（1）內(nèi)存管理：包括對(duì)象創(chuàng)建和數(shù)據(jù)更新時(shí)的堆棧讀寫(xiě)等；

（2）指令的派遣和執(zhí)行。

2）整個(gè)平臺(tái)的性能，包括平臺(tái)特性和在非正常情況下Java卡的性能表現(xiàn)（即事務(wù)中斷），可以細(xì)分為對(duì)如下幾個(gè)環(huán)節(jié)的測(cè)評(píng)：

（1）應(yīng)用的下載和安裝速度；

（2）內(nèi)存回收策略：包括對(duì)象刪除和垃圾回收等的效率；

（3）JCRE：事務(wù)中斷，即發(fā)生數(shù)據(jù)回滾時(shí)的性能表現(xiàn)；

（4）API：Java卡API方法的執(zhí)行效率。

3 結(jié)論

Java卡分離的虛擬機(jī)結(jié)構(gòu)和有限的內(nèi)存資源決定了Java卡應(yīng)用的執(zhí)行性能無(wú)法與Native卡相比。隨著Java卡應(yīng)用領(lǐng)域的不斷拓展（如在3.0規(guī)范中推出的基于Java卡的Web Server應(yīng)用），對(duì)Java卡的性能提出了更高的要求。隨著Java卡處理器性能的提升和內(nèi)存資源的豐富，在壓縮字節(jié)碼、優(yōu)化內(nèi)存管理算法等傳統(tǒng)優(yōu)化途徑之外，在卡中實(shí)現(xiàn)垃圾收集器和數(shù)據(jù)庫(kù)管理系統(tǒng)（DBMS）也都將成為合理的優(yōu)化手段，以不斷提高Java卡的性能。

[1]ZhiqunChen，JavaCardTechnologyforSmar tCards：ArchitectureandProgrammer’sGuide，Addison-Wesley，2000.

[2]M.Oest reicher，K.Ksheeradbhi，ObjectLi fetimesinJavaCard，Proc.UsenixWork-shopSmar tCardTechnology，UsenixAssoc.，Berkeley，Calif.，1999:129-137.

[3]常青，靳偉，李春龍，張其善.JCVM解析優(yōu)化設(shè)計(jì)與實(shí)現(xiàn)[N].北京航空航天大學(xué)學(xué)報(bào)，2004,30(12).

[4]Min-SikJin，Won-HoChoi，Yoon-SimYang，Min-SooJung，AStudyonFastJCVMwithNewTransactionMechanismandCaching-BufferBasedonJavaCardObjectswithaHighLocality，InternationalFederationforInformationProcess（IFIP），2005.

[5]Min-SikJin，Min-SooJung，AStudyonFastJCVMbymovingobjectfromEEPROMtoRAM，Proceedingofthe11thIEEEInternationalConferenceonRTCSA，2005.

[6]ClausenL.R.，SchultzU.P.，ConselC.，JavaBytecodeCompressionLow-EndforEmbeddedSystem，InACMTransactionsonProgrammingLanguagesandSystems，2000，22(3).

[7]PierreParadinas，SamiaBouzefrane，JulienCordry，HowtomeasuretheperformanceofJavaCardPlatforms，CEDRICLab.CNAM(Paris)，2007.