JVM層集群框架下共享類集的自動構(gòu)建方法

唐國靖，王 帥＋，鐘 華，石 穎

（1.中國科學(xué)院軟件研究所 軟件工程技術(shù)中心，北京100190；2.中國空間技術(shù)研究院，北京100000）

0 引 言

JVM （Java virtual machine，Java虛擬機(jī)）層集群框架在Java虛擬機(jī)級別搭建計(jì)算機(jī)集群，可將多臺Java虛擬機(jī)聯(lián)合在一起，搭建具備伸縮性、高可用性的集群系統(tǒng)。共享類集是集群配置的關(guān)鍵組成部分，它的構(gòu)建需要將系統(tǒng)所依賴的所有共享對象的類名包含進(jìn)來，手動構(gòu)建十分繁瑣而復(fù)雜，同時(shí)會帶來一定的效率與操作性上的問題。首先，愈趨龐大的軟件規(guī)模帶來了愈趨復(fù)雜的類圖設(shè)計(jì)，類與類之間繁雜的依賴關(guān)系，使得逐個(gè)類去手動構(gòu)建共享類集變得效率低下且不太現(xiàn)實(shí)。再者，現(xiàn)代的軟件設(shè)計(jì)中越來越廣泛地運(yùn)用了面向接口的編程模式，模塊與模塊之間傳遞的不是具體的對象，而只是一個(gè)接口或者基類型，對象與對象之間的依賴關(guān)系變成了接口與接口之間的依賴關(guān)系，如何從接口中去準(zhǔn)確找到系統(tǒng)所依賴的具體對象是一個(gè)必須考慮的問題，否則便會丟失某些共享類的依賴關(guān)系?，F(xiàn)有的JVM層集群產(chǎn)品都還沒有很成熟的解決方案。針對以上問題，本文提出一種JVM層集群框架下共享類集的自動構(gòu)建方法，用以簡化共享類集的配置過程，降低JVM集群的配置成本，提高集群的部署效率。

1 問題分析

1.1 JVM層集群框架的基本原理

JVM層集群框架最大的優(yōu)勢在于，它是在類的字段級別進(jìn)行數(shù)據(jù)復(fù)制，而不用進(jìn)行傳統(tǒng)的Java序列化，大大減少了CPU、內(nèi)存、網(wǎng)絡(luò)傳輸?shù)荣Y源消耗；而且它可以將單機(jī)模式的系統(tǒng)直接地移植到集群模式下，基本不需要對源代碼進(jìn)行修改。其典型的代表產(chǎn)品包括Terracotta[1]、Co－JVM等。

JVM層集群框架支持在不同的Java虛擬機(jī)之間共享分布式對象，利用多臺Java虛擬機(jī)的協(xié)同合作來構(gòu)建集群系統(tǒng)[2]。由于該框架是在虛擬機(jī)級別對Java字節(jié)碼進(jìn)行增強(qiáng)，在Java類加載時(shí)更改字節(jié)碼的一些行為，以此來獲得集群的行為，所以開發(fā)人員不需要對Java源代碼進(jìn)行修改就能搭建起集群[3]。實(shí)際運(yùn)行時(shí)，被共享的分布式對象有可能存活于多臺不同的機(jī)器上，為了維護(hù)這些對象的一致性，JVM層集群框架會對所有共享對象所屬的類 （即共享類集）進(jìn)行字節(jié)碼增強(qiáng)。共享類集通常以配置文件的形式輸入，JVM層集群框架讀取共享類集之后，使用特定的類加載器對這些類進(jìn)行加載，賦予這些類以集群行為，保證了分布式對象的狀態(tài)一致性。因此，共享類集是搭建JVM層集群的關(guān)鍵。

1.2 共享對象圖和共享類集

在單機(jī)模式下，共享對象是指作用域?yàn)檎麄€(gè)系統(tǒng)，并且被系統(tǒng)的各個(gè)不同模塊所共同使用的那些對象，通常使用靜態(tài)的單例模式來定義。而在計(jì)算機(jī)集群中，共享對象是指在邏輯上唯一存在于整個(gè)集群環(huán)境中，供集群的不同模塊所共同使用的那些對象。集群中的共享對象是一個(gè)邏輯上的概念，實(shí)際上它不一定只是單個(gè)對象，有可能是集群的不同機(jī)器上的不同對象，但這些對象之間的狀態(tài)是保持一致的，在整個(gè)集群看來，它們表現(xiàn)出來的就像是一個(gè)對象的行為[4]。

共享對象有如下的性質(zhì):如果a是共享對象，且a中的字段在系統(tǒng)運(yùn)行過程中指向了另一個(gè)對象b，則b也是共享對象。

定義1 共享對象圖:系統(tǒng)中所有的共享對象的集合以及它們之間的依賴關(guān)系形成的結(jié)構(gòu)稱為共享對象圖。

定義2 共享類集:共享對象圖中的每一個(gè)對象所屬于的類的集合稱為共享類集。

由此可見，共享對象圖是由對象之間的依賴關(guān)系連結(jié)在一起的一個(gè)樹形結(jié)構(gòu)，更準(zhǔn)確地說，是由若干棵樹構(gòu)成的一個(gè)森林。在共享對象圖中，每一棵樹的根叫做這個(gè)共享對象圖的根對象。

在JVM層集群框架中，需要輸入根對象和共享類集，來完成集群的配置。根對象指示出了哪些分布式對象需要共享，共享類集指示出了哪些類需要由JVM層集群框架進(jìn)行加載以獲得集群行為[5]。如圖1所示。

圖1 共享對象圖和共享類集

由共享類集的定義可知，只要給定若干根對象，就可以根據(jù)對象與對象之間的依賴關(guān)系，逐步地構(gòu)建出共享對象圖，進(jìn)而得到共享類集，從而完成共享類集的自動構(gòu)建。需要解決的關(guān)鍵問題包括:

（1）依賴關(guān)系的檢測。最直接的方法是，運(yùn)行一遍整個(gè)Java應(yīng)用，通過運(yùn)行時(shí)的反射機(jī)制獲取對象之間的依賴關(guān)系，但是這卻不現(xiàn)實(shí):首先，有些依賴關(guān)系不是一開始就存在的，而是在某種特定條件觸發(fā)下才會出現(xiàn)的，企圖運(yùn)行一遍Java應(yīng)用來獲取完整的共享對象圖，意味著要進(jìn)行一次完整、完備的軟件測試，包括所有正常和異常的情況都要覆蓋到，這樣問題就變得非常復(fù)雜；再者，要想通過反射操作根對象，需要在系統(tǒng)的源代碼中插入一些處理代碼，這樣便對原始代碼造成了污染。另一個(gè)方法是靜態(tài)分析，即，在不運(yùn)行Java應(yīng)用的情況下，靜態(tài)地分析Java源碼或class文件來獲取共享類集。但這樣就必然會深入到Java字節(jié)碼級別來檢測元素之間的依賴關(guān)系，必然需要專門針對字節(jié)碼的機(jī)制來完成這項(xiàng)工作。

（2）面向接口的依賴推導(dǎo)。面向接口編程是現(xiàn)代軟件的一個(gè)廣泛應(yīng)用的模式，為了提高擴(kuò)展性和靈活性，模塊與模塊之間傳遞的不再是具體的業(yè)務(wù)類，而只是一個(gè)接口或者基類型。因此利用反射從class文件中得到的也只是該類所依賴的一個(gè)接口，至于這個(gè)接口指向的具體是哪個(gè)業(yè)務(wù)類，卻不得而知。為了從class文件中檢測出該類所依賴的具體業(yè)務(wù)類，必須要依靠反射之外的手段。

（3）依賴關(guān)系的擴(kuò)散。一個(gè)類對另外一個(gè)類的依賴關(guān)系，不一定體現(xiàn)在這兩個(gè)類的代碼中，這種依賴關(guān)系完全有可能是在第三個(gè)類中實(shí)現(xiàn)的，甚至是第四、第五個(gè)類等，這稱為依賴關(guān)系的擴(kuò)散。這種依賴關(guān)系的擴(kuò)散增加了共享類集構(gòu)建的復(fù)雜性，因此必須提供一種機(jī)制來檢測這種擴(kuò)散，并且保證共享類集的完備性。

1.3 目 標(biāo)

我們的目標(biāo)是，根據(jù)給定的根對象，自動構(gòu)建出對應(yīng)的共享類集，從而完成JVM層集群框架的配置。Java應(yīng)用的開發(fā)者只需要指定集群中共享的根對象，而不需要手動地去輸入共享類集，共享類集可以由根對象推導(dǎo)而出，這樣便大大減少了集群配置的工作量，提高了集群搭建的效率。

2 解決方案

解決方案包括3個(gè)關(guān)鍵技術(shù)點(diǎn)，分別針對上文列舉的3個(gè)關(guān)鍵問題，在減少源代碼污染的原則基礎(chǔ)上，分析Java應(yīng)用的class文件，并解決了面向接口的依賴推導(dǎo)和依賴擴(kuò)散問題，自動完成了共享類集的構(gòu)建。

2.1 靜態(tài)代碼分析

運(yùn)行時(shí)分析使得構(gòu)建出完備的共享類集十分困難，并且可能對Java源代碼造成污染，所以我們使用靜態(tài)代碼分析的方法，分析與處理class文件，在Java應(yīng)用運(yùn)行之前便構(gòu)建出共享類集。Java的class文件由編譯好的字節(jié)碼構(gòu)成，經(jīng)過編譯后，Java源代碼被解析成更基礎(chǔ)更原子化的指令，也消除了代碼注釋等可能的干擾，所以字節(jié)碼比Java源代碼更加結(jié)構(gòu)化，也更加便于靜態(tài)分析[6，7]。

根據(jù)根對象來構(gòu)建共享類集，實(shí)質(zhì)上是對象之間依賴關(guān)系的檢測問題。在本文的靜態(tài)代碼分析方法中，核心模塊是DependencyExtractor，它以Java的class文件作為輸入，抽取出Java字節(jié)碼中滿足給定條件的依賴關(guān)系，并根據(jù)需要處理這些依賴關(guān)系。

定義3 依賴:如果一個(gè)元素A的運(yùn)行需要另一個(gè)元素B的參與，則稱元素A依賴于元素B，或元素B被元素A所依賴，寫作A－＞B[8]。

Java應(yīng)用中包含3種類型的元素，即Java類、類的方法和類的字段。在DependencyExtractor模塊中，我們定義了5種可能的依賴類型，分別是:

（1）類對類的依賴:如果類C1使用了類C2的服務(wù)，即類C1繼承自類C2，或者類C1中存在一個(gè)字段是C2類型，或者類C1的一個(gè)方法使用了類C2的一個(gè)對象，我們稱類C1依賴于類C2；

（2）方法對類的依賴:如果一個(gè)方法m中使用了類C的一個(gè)對象，我們稱方法m依賴于類C；

（3）字段對類的依賴:如果一個(gè)字段f被聲明為類C的一個(gè)對象，我們稱字段f依賴于類C；

（4）方法對方法的依賴:如果一個(gè)方法m1中調(diào)用了另外一個(gè)方法m2，我們稱方法m1依賴于方法m2；

（5）方法對字段的依賴:如果一個(gè)方法m中使用了一個(gè)字段f，我們稱方法m依賴于字段f。

以上5種類型的依賴關(guān)系是構(gòu)建共享類集的基本要素，并且都可以由對代碼的靜態(tài)分析得出。靜態(tài)代碼分析的基本框架如圖2所示。class文件被讀取以解析成字節(jié)碼指令，在所有的字節(jié)碼指令中，只有一部分指令對依賴的檢測提供幫助，通過指令過濾，與依賴相關(guān)的這些指令被分離出來。根據(jù)指令調(diào)用的作用目標(biāo)，抽取出與給定根元素相關(guān)的依賴關(guān)系，并將依賴元素和被依賴元素作為輸出。

圖2 靜態(tài)代碼分析框架

利用DependencyExtractor模塊提供的服務(wù)，我們在依賴關(guān)系的基礎(chǔ)上進(jìn)行共享類集的推導(dǎo)。

2.2 面向接口的依賴推導(dǎo)

根據(jù)根對象來推導(dǎo)出共享類集，關(guān)鍵就在于:共享對象的推導(dǎo)，即如何能夠完備地找出根對象所依賴的其他對象；業(yè)務(wù)類的推導(dǎo)，即如何能夠完備地找出某個(gè)對象所依賴的具體業(yè)務(wù)類。

2.2.1 共享對象的推導(dǎo)

因?yàn)楦鶎ο蟊厝皇且阅硞€(gè)類的字段的形式給出的，所以下文中我們將不加區(qū)分地使用根對象和根字段兩個(gè)概念。由給定的系統(tǒng)的若干個(gè)根字段，根據(jù)以上的依賴類型，找出這些根字段所依賴的所有類，便構(gòu)建出了共享類集。

基本步驟依次如下:

（1）共享類集ClassSet初始化為空。

（2）給定根字段root，先初始化字段圖FieldGraph。字段圖描述的是一個(gè)字段和它可能會引用到的其他字段的關(guān)聯(lián)關(guān)系。FieldGraph被初始化為根字段的靜態(tài)引用關(guān)系。因?yàn)槭庆o態(tài)信息，所以可以根據(jù)class文件，利用反射機(jī)制獲取。字段圖的初始化是一個(gè)遞歸的過程，基本步驟如下。

（3）推導(dǎo)出字段root指向的具體業(yè)務(wù)類R，將類R加入到ClassSet中。

（4）若類R的聲明中存在一個(gè)字段field，且該字段field不在當(dāng)前的字段圖FieldGraph中，那么將字段field插入到字段圖的相應(yīng)位置。

（5）對字段圖FieldGraph中root的每個(gè)孩子節(jié)點(diǎn)，以該孩子節(jié)點(diǎn)為新的根字段，遞歸地回到步驟3。

最后得到的ClassSet就是我們需要的共享類集。其中最關(guān)鍵的步驟是第3步，即如何推導(dǎo)出一個(gè)字段指向的具體業(yè)務(wù)類。

2.2.2 業(yè)務(wù)類的推導(dǎo)

最簡單的情況下，字段指向的具體類型和其聲明類型是一致的，如圖3中a所示。類A的字段變量field的聲明類型和指向的具體類型都是Field類，這時(shí)DependencyExtractor通過檢測該字段所依賴的類，便能獲取到Field類的信息。

圖3 業(yè)務(wù)類3種依賴方式

然而在面向接口的編程模式中，字段的聲明類型往往只是一個(gè)接口或者基類型，如圖3中b所示。類A的字段變量field的聲明類型是接口IField，如果利用字段對類的依賴關(guān)系我們只能獲取到IField的信息，而事實(shí)上field在運(yùn)行時(shí)可能會指向具體的業(yè)務(wù)類Field。DependencyExtractor對字節(jié)碼指令進(jìn)行分析，解析出為字段field賦值的是一個(gè)類構(gòu)造器調(diào)用，進(jìn)而找出該類構(gòu)造器對應(yīng)的真正具體類型Field。

字段變量還有可能指向普通方法調(diào)用的返回值類型，如圖3中c所示。這種情況下，推導(dǎo)過程大致分成三步:第一步，在類A中找出依賴于字段field的所有方法，即方法A.set（）；第二步，在上述方法A.set（）中，檢測出了字段field被賦值為另一個(gè)方法的調(diào)用，找出這些被調(diào)用的方法，即方法getNewField（）；第三步，在方法getNew－Field（）中解析出返回值類型，即得到具體業(yè)務(wù)類Field。

2.3 依賴擴(kuò)散的檢測與處理

在更一般的情況下，字段和具體業(yè)務(wù)類之間的依賴關(guān)系并不在本類中直接體現(xiàn)，而是體現(xiàn)在其他類中，這種情況稱為依賴關(guān)系的擴(kuò)散。如圖4所示，此時(shí)在類A中根本無法檢測到具體的業(yè)務(wù)類Field，F(xiàn)ield類的對象通過方法set（IField）在運(yùn)行時(shí)傳入。

圖4 依賴關(guān)系的擴(kuò)散

GetFromField方法負(fù)責(zé)讀取給定的字段名稱，最終返回該字段可能指向的所有具體業(yè)務(wù)類的集合。GetFrom－Field首先構(gòu)造出依賴于給定字段field的所有方法集合MethodSet，則對于MethodSet中的任意一個(gè)方法method（arg[1]，arg[2]，…，arg[n]），其方法體中必定存在對字段field的引用，而我們只關(guān)注對field的賦值操作指令。如果字段field被賦值為new A（）形式的構(gòu)造方法，則直接將類A加入到業(yè)務(wù)類集合中；如果字段field被賦值為一個(gè)方法method2的返回值，則我們所求的集合轉(zhuǎn)換為 “方法method2的返回值所指向的具體業(yè)務(wù)類集合”，而這個(gè)集合可以由GetFromReturn（method2）調(diào)用得到；如果字段field被賦值為method方法的某個(gè)傳入?yún)?shù)arg[k]，則我們所求的集合轉(zhuǎn)換為 “方法mehod的第k個(gè)傳入?yún)?shù)所指向的具體業(yè)務(wù)類集合”，而這個(gè)集合可以由GetFromArgument（method，k）調(diào)用得到。基本代碼框架如圖5所示。

圖5 依賴擴(kuò)散的檢測處理主方法

子方法GetFromReturn負(fù)責(zé)讀取給定的方法名稱，最終返回該方法的返回值可能指向的所有具體業(yè)務(wù)類的集合。對于給定的方法 method（arg[1]，arg[2]，…，arg[n]），分析方法體，如果返回值被賦值為new A（）形式的構(gòu)造方法，則直接將類A加入到業(yè)務(wù)類集合中；如果返回值被賦值為一個(gè)方法method2調(diào)用的返回值，便遞歸地調(diào)用GetFromReturn（method2）；如果返回值被賦值為method的第k個(gè)傳入?yún)?shù)arg[k]，與上文同理，可調(diào)用GetFromArgument（method，k）?；敬a框架如圖6所示。

圖6 依賴擴(kuò)散的檢測處理子方法1

子方法GetFromArgument負(fù)責(zé)讀取給定的方法名稱和一個(gè)下標(biāo)整數(shù)值k，該整數(shù)值表示了給定方法的參數(shù)列表中的第k個(gè)參數(shù)，最終返回的是該方法的第k個(gè)傳入?yún)?shù)可能指向的所有具體業(yè)務(wù)類的集合。GetFromArgument首先構(gòu)造出依賴于給定方法 method（arg[1]，arg[2]，…，arg[n]）的所有方法集合MethodSet，則對于MethodSet中的任意一個(gè)方法method2（arg2[1]，arg2[2]，…，arg2[n]），其方法體中必定存在對方法 method（arg[1]，arg[2]，…，arg[n]）的調(diào)用，而我們只關(guān)注對arg[k]的賦值操作指令。具體情況分析與上文類似?；敬a框架如圖7所示。

GetFromField、GetFromReturn和 GetFromArgument這3個(gè)方法構(gòu)成了一種間接遞歸的調(diào)用關(guān)系，從中我們可以檢測出依賴擴(kuò)散的出現(xiàn)并處理它，從而得到所有可能存在的具體業(yè)務(wù)類，使共享類集更加完備。

3 實(shí)現(xiàn)與應(yīng)用案例

本文以O(shè)ncePortal和Terracotta為應(yīng)用案例，說明共享類集的自動構(gòu)建方法的有效性。OncePortal是由中科院軟件所軟件工程中心研發(fā)，基于J2EE平臺的企業(yè)門戶中間件，是典型的單機(jī)模式下的Java Web應(yīng)用[9]。Terracotta是一個(gè)優(yōu)秀的JVM層集群框架產(chǎn)品，以xml配置文件的形式讀取系統(tǒng)的共享類集，實(shí)現(xiàn)多JVM之間分布式對象的共享，搭建JVM 集群[10]。

圖7 依賴擴(kuò)散的檢測處理子方法2

OncePortal是一個(gè)總代碼量大約是16萬行的中小型Web應(yīng)用，總共包含34個(gè)單例模式的服務(wù)類，它們會在整個(gè)系統(tǒng)中被共享。將OncePortal移植到集群環(huán)境中，首先需要考慮構(gòu)建系統(tǒng)的共享類集，其中上述34個(gè)單例的對象便構(gòu)成共享的根對象。

在具體實(shí)現(xiàn)中，主要的構(gòu)建模塊包含了三大部分:首先，以O(shè)ncePortal的所有class文件作為輸入，讀取到DependencyExtractor中開始靜態(tài)分析；然后，從Dependency－Extractor的分析結(jié)果中推導(dǎo)出我們需要的依賴關(guān)系，包括共享對象圖和具體業(yè)務(wù)類的推導(dǎo)；依賴擴(kuò)散的檢測處理模塊會在依賴關(guān)系的推導(dǎo)過程中被調(diào)用，負(fù)責(zé)處理那些間接產(chǎn)生的依賴模式。共享對象圖和相應(yīng)的共享類集是整個(gè)構(gòu)建模塊最終的輸出。共享類集自動構(gòu)建的框架如圖8所示。

圖8 OncePortal中共享類集的自動構(gòu)建框架

共享類集構(gòu)建完畢之后，寫入xml配置文件供JVM層集群框架 （terracotta）讀取。以PortletEntityRegistryServiceFileImpl.registry根字段的共享為例，分別在兩臺不同的機(jī)器上啟動OncePortal系統(tǒng)，配置完畢Terracotta之后，根字段對應(yīng)的PortletApplicationEntityListImpl類以及推導(dǎo)出的共享類被自動共享，并且保證不同機(jī)器之間的狀態(tài)一致性，運(yùn)行效果如圖9所示。

圖9 OncePortal上分布式對象的共享

4 結(jié)束語

本論文立足于JVM層集群框架，為了簡化集群配置流程、提高集群搭建效率，從依賴關(guān)系的檢測出發(fā)，提出了Java應(yīng)用中共享類集的自動構(gòu)建方法。共享類集是JVM層集群框架得以正確運(yùn)行的關(guān)鍵保障。為了保證共享類集的完備性，以及避免對Java源代碼的污染，采取了針對Java的class文件的靜態(tài)代碼分析方法，在字節(jié)碼級別對依賴關(guān)系進(jìn)行檢測。針對現(xiàn)在廣泛應(yīng)用的面向接口的編程模式，解決了接口與具體業(yè)務(wù)類之間依賴關(guān)系的推導(dǎo)問題，在Java應(yīng)用運(yùn)行之前推導(dǎo)出可能存在依賴關(guān)系的共享類；并提供依賴擴(kuò)散的檢測和處理機(jī)制，有效實(shí)現(xiàn)了間接依賴關(guān)系的推導(dǎo)。以O(shè)ncePortal中間件系統(tǒng)為應(yīng)用場景，實(shí)現(xiàn)并測試了該系統(tǒng)中共享類集的自動構(gòu)建，實(shí)驗(yàn)結(jié)果表明，本論文提出的方法有效解決了共享類集的自動構(gòu)建問題，簡化了JVM層集群框架的配置。

[1]Hartley Jeff.The definitive guide to terracotta[M].New York:Apress，2008.

[2]Sim o J，Lemos J，Veiga L.A 2－VM:A cooperative Java VM with support for resource－awareness and cluster－wide thread scheduling[G].LNCS 7044:On the Move to Meaningful Internet Systems.Berlin:Springer Berlin Heidelberg，2011:302－320.

[3]QIU Rui.Design and implementation of a JVM cluster based on AspectWerkz[D].Chengdu:University of Electronic Science and Technology of China，2008 （in Chinese）.[邱睿.基于AspectWerkz的JVM層集群軟件的設(shè)計(jì)與實(shí)現(xiàn)[D].成都:電子科技大學(xué)，2008.]

[4]Werner Vogels.Eventually consistent[J].Communications of the ACM－Rural Engineering Development，2009，52 （1）:40－44.

[5]Perelmutov T，Crawford M，Moibenko A，et al.Horizontally scaling dCache SRM with the terracotta platform[J].Journal of Physics:Conference Series.IOP Publishing，2011，331（6）:062020.

[6]Logozzo F，F(xiàn) hndrich M.On the relative completeness of bytecode analysis versus source code analysis[C]／／Compiler Construction，2008:197－212.

[7]Vallee－Rai R，Co P，Gagnon E，et al.Soot:A Java bytecode optimization framework[C]／／CASCON First Decade High Impact Papers，2010:214－224.

[8]DependencyFinder[EB／OL].http:／／depfind.sourceforge.net／.

[9]Institute of Software，Chinese Academy of Sciences.OncePortal middleware system[EB／OL].http:／／www.once.org.cn，2007（in Chinese）.[中科院軟件所.網(wǎng)馳平臺門戶中間件（OncePortal）[EB／OL].http:／／www.once.org.cn，2007.

[10]Terracotta[EB／OL].http:／／www.terracotta.org，2009.