Java中一種字符串的內(nèi)存管理方法
Java[1]語言為字符串操作提供了豐富的支持,它將字符串封裝在三個(gè)類中并提供多種字符串操作接口。在Java應(yīng)用程序中,由于對(duì)字符串的使用量比較高,從而使得其需要消耗較大的堆空間。例如在J2EE應(yīng)用服務(wù)器運(yùn)行過程中,約40%的活躍堆空間被用來保存字符串?dāng)?shù)據(jù)[2]。
通過對(duì)Java中字符串操作接口的分析可以發(fā)現(xiàn),隨著這些操作的運(yùn)行會(huì)產(chǎn)生較多的無用字符串,它們不再被Java類封裝并且也不被任何變量引用。這些無用字符串?dāng)?shù)據(jù)將一直停留在活躍堆中,直到Java虛擬機(jī)啟動(dòng)垃圾收集將其回收。而由于字符串?dāng)?shù)據(jù)具有單個(gè)對(duì)象占用空間較小但總體數(shù)量很大的特征,大量的無用字符串?dāng)?shù)據(jù)不僅會(huì)影響堆空間的利用率,并且對(duì)Java虛擬機(jī)垃圾收集的性能有較大影響。
當(dāng)前對(duì)Java中字符串的內(nèi)存管理優(yōu)化方案主要關(guān)注于字符串的使用效率上,如消除常量重復(fù)、延遲分配等技術(shù)[2],通過修改Java虛擬機(jī)對(duì)字符串分配回收的支持來提高堆中字符串的使用效率。然而這些方案無法處理堆中已經(jīng)成為無用字符串的數(shù)據(jù),只能等待垃圾收集來處理。
近期編譯時(shí)的獨(dú)立對(duì)象回收策略[3]則專注于在編譯階段對(duì)應(yīng)用程序做分析并插入回收指令以回收無用對(duì)象空間,但是該方案對(duì)Java庫函數(shù)只做保守分析從而無法回收這些無用字符串。為此,本文從對(duì)字符串操作接口的分析出發(fā),識(shí)別各類操作對(duì)字符串的改變情況以利用獨(dú)立對(duì)象回收策略中的指令插樁技術(shù)來主動(dòng)回收無用字符串對(duì)象,以提高堆空間的利用率、減低垃圾回收的負(fù)擔(dān)、改善Java虛擬機(jī)的性能。
1 Java中字符串的支持與分析
1.1 Java中字符串的支持
Java語言將字符串的表示和操作都封裝在StringBuilder、StringBuffer和String三個(gè)類中。其中前兩個(gè)類指向的字符串是可變的,String類指向的字符串是不變的。這三個(gè)類的內(nèi)部結(jié)構(gòu)基本上一致,以StringBuilder為例,StringBuilder在Java中的結(jié)構(gòu)如圖1所示。
從圖1可以看出,字符串?dāng)?shù)據(jù)由StringBuilder對(duì)象指向的value域保存,在內(nèi)存空間上反映為兩個(gè)對(duì)象:StringBuilder對(duì)象通過value域指向字符串對(duì)象。由于該類提供常用的可變字符串操作接口且相對(duì)另一個(gè)類StringBuffer具有較高的執(zhí)行效率,對(duì)字符串?dāng)?shù)據(jù)的操作在Java虛擬機(jī)中一般會(huì)將其轉(zhuǎn)換為StringBuilder對(duì)象再做處理。下面以一個(gè)語句示例來說明這一點(diǎn):
String s=new String(‘aa’+’bb’+’cc’);
該語句的語義是將三個(gè)字符串連接在一起并生成一個(gè)String對(duì)象,在Java語言的源程序級(jí)別上不會(huì)出現(xiàn)StringBuilder對(duì)象,但是經(jīng)過編譯器優(yōu)化之后,這條語句實(shí)際被翻譯為下面的字節(jié)碼形式(為簡化描述,本文以源語言來表示字節(jié)碼的操作):
StringBuilder t=new StringBuilder(‘aa’);
t.append(‘bb’);
t.append(‘cc’);
String s=t.toString();
即Java編譯器會(huì)首先創(chuàng)建一個(gè)StringBuilder對(duì)象,完成字符串的連接工作之后再將其轉(zhuǎn)變?yōu)镾tring對(duì)象。由于類似于這種情況的字符串操作較多地出現(xiàn)在輸出方法和字符串創(chuàng)建方法中,所以可推斷出StringBuilder有著較大的使用頻率,故將以其為代表分析其提供的接口對(duì)字符串的影響。
1.2 無用字符串的產(chǎn)生
在上節(jié)的示例中,StringBuilder類提供的append()接口將會(huì)改變value域所指向的字符串,其做法是:新建長度為連接后字符串長度之和的字符數(shù)組,分段復(fù)制之后使其成為value域指向的新數(shù)組,而value域指向的原數(shù)組將被丟棄成為無用字符串。
圖2為示例語句中append()接口引起的value域指向字符串變化圖。
從圖2可以看出,在append()接口執(zhí)行過后,對(duì)象的字符數(shù)組將指向新建的字符串’aabb’,原有字符串’aa’將不被任何變量指向而成為無用字符串。
由于StringBuilder類的value域指向的字符串是可變的,在其提供的接口中存在大量類似append()可能對(duì)value域做出改變的接口,如insert()、replace()等。而在Java虛擬機(jī)對(duì)這些接口的調(diào)用頻率較多,表1是基準(zhǔn)測(cè)試程序Jolden[4]的4個(gè)子程序中字符串操作接口調(diào)用次數(shù)以及可能對(duì)value域做出改變的接口調(diào)用次數(shù)對(duì)比。
由表1可以看出,可能對(duì)value域做出改變的調(diào)用次數(shù)占字符串操作接口調(diào)用次數(shù)的22.6%~45.7%,占有不可忽視的比例。下面將深入分析這些可能改變value域的操作接口的具體實(shí)現(xiàn)。
1.3 字符串操作接口分析
可能對(duì)value域做出改變的操作接口有一個(gè)共同點(diǎn),即this對(duì)象不會(huì)發(fā)生變化,只是其value域指向一個(gè)新建的字符串。對(duì)字符串的操作接口做深入分析后可知,在append()等可能改變value域指向的操作接口的實(shí)現(xiàn)中,存在兩條改變分支:例如在接口append(s)中,如果s為null或者s的value域指向一個(gè)空字符串,則該接口不會(huì)改變this對(duì)象的value域指向;否則才會(huì)新建一個(gè)字符串以被this對(duì)象的value域指向。
可以將這兩條改變分支表現(xiàn)為下面的形式:
分支1:不做任何改變。
分支2:新建字符串,使其被this對(duì)象的value域指向,原有字符串成為無用字符串。
下面將給出根據(jù)本節(jié)的分析給出的無用字符串回收方案。
2 字符串的回收方案
對(duì)無用字符串的回收存在兩個(gè)難點(diǎn):(1)不可深入改變Java的庫函數(shù)實(shí)現(xiàn)。因?yàn)榛厥辗桨感枰哂休^強(qiáng)的通用性和靈活性;(2)由于操作接口具體實(shí)現(xiàn)中對(duì)value域的改變存在分支,并且只能在應(yīng)用程序的運(yùn)行階段判斷究竟執(zhí)行的是哪個(gè)分支。
本文采用獨(dú)立對(duì)象顯式回收策略中的指令插樁技術(shù)來解決上述兩個(gè)難題:在可能發(fā)生改變的字符串操作接口調(diào)用點(diǎn)處插入判定語句來對(duì)操作接口執(zhí)行的分支做判斷,然后根據(jù)結(jié)果來實(shí)施字符串的回收方案。由于這些語句都插樁在用戶程序中,不會(huì)改變Java庫函數(shù)的實(shí)現(xiàn),而且這些語句會(huì)隨著字符串操作接口的執(zhí)行而執(zhí)行,所收集的信息屬于運(yùn)行時(shí)信息,故可以很好地判斷運(yùn)行時(shí)分支的情況。
由于兩條分支的不同之處表現(xiàn)為操作接口執(zhí)行完畢之后,this對(duì)象的value域指向是否發(fā)生了變化,故可以采取接口調(diào)用前后value域比較的方式來判斷具體執(zhí)行的分支。本文使用指令插樁技術(shù),在Java虛擬機(jī)重編譯Java字節(jié)碼時(shí)對(duì)其做指令插樁工作,其處理流程為:
(1)在Java虛擬機(jī)處理應(yīng)用程序指令時(shí)判斷其是否為可能引起字符串變化的操作接口調(diào)用指令。
(2)如果是則實(shí)施步驟(3)~(5)的指令插樁工作。
(3)在調(diào)用指令之前插入this對(duì)象的value域引用保存指令。
(4)在調(diào)用指令之后插入this對(duì)象的value域引用保存指令。
(5)安插兩個(gè)引用的對(duì)比指令,如果不同,則插入回收指令以回收調(diào)用之前保存的引用;否則將不做處理。
本方案用到了獨(dú)立對(duì)象回收技術(shù)中的回收指令,需要在Java虛擬機(jī)的內(nèi)存管理模塊支持這個(gè)回收指令。由于對(duì)回收指令的支持對(duì)原有的分配和回收方案影響很小,故其實(shí)現(xiàn)較簡單并且具有一定的通用性。
以圖3為例來說明本文的字符串回收方案。由于該方案處理的為Java字節(jié)碼,為了方便理解,將以實(shí)際代碼的形式體現(xiàn):由圖3可看出,在調(diào)用點(diǎn)前后加入了value域引用保存指令記錄了調(diào)用點(diǎn)執(zhí)行前后的value域的引用信息,然后將兩者做對(duì)比處理來判斷調(diào)用點(diǎn)是否對(duì)value域的引用做出了改變,如果引用信息有了變化,則之前的value域引用成為了無用字符串,可以插入回收指令將其回收。
可以將該無用字符串回收方案應(yīng)用到其他可能對(duì)對(duì)象內(nèi)部value域指向的字符串做出改變的接口調(diào)用點(diǎn),即可以在運(yùn)行時(shí)回收由這些接口運(yùn)行而出現(xiàn)的無用字符串?dāng)?shù)據(jù)。
3 實(shí)驗(yàn)結(jié)果及分析
在Apache的開源Java SE(Standard Edition)平臺(tái)Harmony[5]上實(shí)現(xiàn)了針對(duì)字符串的回收方案,并做了相關(guān)的實(shí)驗(yàn)測(cè)試。測(cè)試平臺(tái)的操作系統(tǒng)是Windows 7 Ultimate,CPU為Intel Pentium Dual E2200,主頻為2.2 GHz,內(nèi)存為2 GB。測(cè)試用例為Jolden中的4個(gè)基準(zhǔn)程序。
在實(shí)現(xiàn)了無用字符串的顯式回收之后,可以在運(yùn)行中主動(dòng)回收一些無用字符串以提高活躍堆空間的利用率和降低Java虛擬機(jī)垃圾回收的開銷。表2給出了主動(dòng)回收的無用字符串大小和總分配大小的比較情況。
由表2可以看出,本文的回收方案主動(dòng)回收的無用字符串占應(yīng)用程序總分配空間的5%~18%,對(duì)堆空間的利用率有較大的提升。對(duì)無用字符串的主動(dòng)回收也帶來了Java虛擬機(jī)的性能提升,因?yàn)榭梢詼p輕垃圾收集的負(fù)擔(dān)。表3給出了實(shí)現(xiàn)無用字符串回收方案前后測(cè)試程序在Java虛擬機(jī)中的執(zhí)行時(shí)間對(duì)比。
由表3可以看出,經(jīng)過對(duì)無用字符串的主動(dòng)回收處理,Java虛擬機(jī)對(duì)應(yīng)用程序的執(zhí)行效率也有了改善,分別減少了1%~5%。這說明無用字符串的回收可以提升Java虛擬機(jī)的性能。
本文提出一種對(duì)Java應(yīng)用程序中無用字符串進(jìn)行顯式回收的方案,以指令插樁的形式收集應(yīng)用程序運(yùn)行時(shí)信息并主動(dòng)回收堆中無用字符串,以提高堆空間的利用率。實(shí)驗(yàn)結(jié)果表明,該方案可以有效提高Java虛擬機(jī)的性能和Java應(yīng)用程序的執(zhí)行效率。
評(píng)論