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

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

0 引 言

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

1 問題分析

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

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

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

1.2 共享對象圖和共享類集

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

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

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

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

由此可見，共享對象圖是由對象之間的依賴關系連結在一起的一個樹形結構，更準確地說，是由若干棵樹構成的一個森林。在共享對象圖中，每一棵樹的根叫做這個共享對象圖的根對象。

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

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

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

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

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

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

1.3 目 標

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

2 解決方案

解決方案包括3個關鍵技術點，分別針對上文列舉的3個關鍵問題，在減少源代碼污染的原則基礎上，分析Java應用的class文件，并解決了面向接口的依賴推導和依賴擴散問題，自動完成了共享類集的構建。

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

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

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

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

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

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

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

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

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

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

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

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

利用DependencyExtractor模塊提供的服務，我們在依賴關系的基礎上進行共享類集的推導。

2.2 面向接口的依賴推導

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

2.2.1 共享對象的推導

因為根對象必然是以某個類的字段的形式給出的，所以下文中我們將不加區(qū)分地使用根對象和根字段兩個概念。由給定的系統(tǒng)的若干個根字段，根據(jù)以上的依賴類型，找出這些根字段所依賴的所有類，便構建出了共享類集。

基本步驟依次如下:

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

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

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

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

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

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

2.2.2 業(yè)務類的推導

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

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

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

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

2.3 依賴擴散的檢測與處理

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

圖4 依賴關系的擴散

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

圖5 依賴擴散的檢測處理主方法

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

圖6 依賴擴散的檢測處理子方法1

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

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

3 實現(xiàn)與應用案例

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

圖7 依賴擴散的檢測處理子方法2

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

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

圖8 OncePortal中共享類集的自動構建框架

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

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

4 結束語

本論文立足于JVM層集群框架，為了簡化集群配置流程、提高集群搭建效率，從依賴關系的檢測出發(fā)，提出了Java應用中共享類集的自動構建方法。共享類集是JVM層集群框架得以正確運行的關鍵保障。為了保證共享類集的完備性，以及避免對Java源代碼的污染，采取了針對Java的class文件的靜態(tài)代碼分析方法，在字節(jié)碼級別對依賴關系進行檢測。針對現(xiàn)在廣泛應用的面向接口的編程模式，解決了接口與具體業(yè)務類之間依賴關系的推導問題，在Java應用運行之前推導出可能存在依賴關系的共享類；并提供依賴擴散的檢測和處理機制，有效實現(xiàn)了間接依賴關系的推導。以OncePortal中間件系統(tǒng)為應用場景，實現(xiàn)并測試了該系統(tǒng)中共享類集的自動構建，實驗結果表明，本論文提出的方法有效解決了共享類集的自動構建問題，簡化了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層集群軟件的設計與實現(xiàn)[D].成都:電子科技大學，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.