張雄　陸路　石宣化

摘要：通過(guò)從程序語(yǔ)言的特性、垃圾回收機(jī)制、內(nèi)存對(duì)象的序列化機(jī)制到基于區(qū)域的內(nèi)存管理機(jī)制分析了內(nèi)存對(duì)象的管理存在的問(wèn)題，并分析了內(nèi)存對(duì)象的生命周期在內(nèi)存對(duì)象管理中能發(fā)揮的作用。提出了基于內(nèi)存對(duì)象的生命周期對(duì)內(nèi)存進(jìn)行區(qū)域化管理的思路，可以從根本上解決垃圾回收問(wèn)題。

關(guān)鍵詞：大數(shù)據(jù)；內(nèi)存對(duì)象管理；分布式數(shù)據(jù)處理系統(tǒng)

Abstract：Through analysis of the characteristics of program languages， mechanism of garbage collection， serialization of in-memory data-objects and region-based memory management， most existing problems with memory management are exposed. Whats more， the lifetime of in-memory data objects can be key factor in memory management. Thus a solution is region-based memory management combined with the lifetime of in-memory data objects， which can solve the garbage collection problem.

Key words：big data； in-memory data-object management； distributed data processing system

以MapReduce為代表的分布式數(shù)據(jù)處理系統(tǒng)使得人們可以以增加硬件資源的方法來(lái)處理海量數(shù)據(jù)。已有的大量研究集中在多核或分布式環(huán)境下的可擴(kuò)展性和容錯(cuò)性。最新的研究工作表明：這類系統(tǒng)計(jì)算執(zhí)行效率是一個(gè)被忽視的重要問(wèn)題。導(dǎo)致執(zhí)行效率低下的一個(gè)重要原因是代表性的開源系統(tǒng)，如Hadoop和Spark，都使用帶有托管執(zhí)行環(huán)境的高級(jí)語(yǔ)言開發(fā)，從而降低分布式環(huán)境下的部署和調(diào)試的難度。托管環(huán)境提供內(nèi)建的高級(jí)功能，比如自動(dòng)內(nèi)存管理和并發(fā)模型，使得其對(duì)象模型的底層實(shí)現(xiàn)非常復(fù)雜，帶來(lái)額外的內(nèi)存和中央處理器（CPU）開銷。工業(yè)級(jí)托管環(huán)境的現(xiàn)代即時(shí)編譯優(yōu)化很大程度上解決了中間代碼（IR）的解釋執(zhí)行效率問(wèn)題，但是難以解決復(fù)雜對(duì)象模型實(shí)現(xiàn)帶來(lái)的對(duì)象管理開銷問(wèn)題。以Java虛擬機(jī)（JVM）為例：（1）每個(gè)對(duì)象在JVM中會(huì)有一個(gè)頭結(jié)構(gòu)保存元數(shù)據(jù)，頭結(jié)構(gòu)除了記錄對(duì)象類型，還要支持垃圾收集和并發(fā)加鎖優(yōu)化；（2）所有（非原生類型）對(duì)象都在堆中創(chuàng)建，因此每個(gè)存活對(duì)象至少要有一個(gè)額外變量保存其引用；（3）泛型容器的元素如果是基本類型，必須首先被裝箱為對(duì)象類型；（4）主流垃圾收集算法都是基于對(duì)象追蹤的，因此堆中有大量的存活對(duì)象時(shí)，垃圾收集器需要耗費(fèi)大量CPU周期來(lái)標(biāo)記存活對(duì)象[1]。隨著處理數(shù)據(jù)量的增大，內(nèi)存對(duì)象越來(lái)越多，尤其是長(zhǎng)駐內(nèi)存對(duì)象的存在[2]，內(nèi)存對(duì)象管理會(huì)帶來(lái)嚴(yán)重的內(nèi)存膨脹和CPU開銷問(wèn)題。內(nèi)存膨脹會(huì)間接影響執(zhí)行性能：如果內(nèi)存足夠，更大的內(nèi)存占用會(huì)導(dǎo)致更頻繁的垃圾回收；如果內(nèi)存不足，緩存的數(shù)據(jù)需要部分丟棄或者換出到磁盤，導(dǎo)致額外的重計(jì)算或輸入輸出（IO）開銷。

最初用來(lái)解決這類問(wèn)題的方法是垃圾收集優(yōu)化。垃圾收集優(yōu)化分為兩個(gè)方面：一方面是通過(guò)參數(shù)[3]調(diào)優(yōu)，避免頻繁垃圾收集；另一方面是通過(guò)優(yōu)化垃圾收集算法實(shí)現(xiàn)來(lái)提高垃圾收集的性能[4]。垃圾收集優(yōu)化的方法只是減緩了垃圾收集操作的影響，實(shí)際上內(nèi)存對(duì)象管理所存在的問(wèn)題仍然存在。后續(xù)的性能優(yōu)化方案逐漸從垃圾收集的優(yōu)化深入到內(nèi)存對(duì)象管理本身，針對(duì)數(shù)據(jù)對(duì)象在內(nèi)存中的存儲(chǔ)進(jìn)行優(yōu)化，主要包括序列化存儲(chǔ)[5]，基于區(qū)域的內(nèi)存管理[6]。這種解決方案從根本上解決了對(duì)象對(duì)內(nèi)存資源的占用，但是仍然無(wú)法避免對(duì)象的存在。在對(duì)象存儲(chǔ)優(yōu)化的基礎(chǔ)上，目前分布式系統(tǒng)的一些上層特定應(yīng)用，例如Spark 結(jié)構(gòu)化查詢語(yǔ)言（SQL），利用特定的數(shù)據(jù)結(jié)構(gòu)解決了對(duì)象存儲(chǔ)優(yōu)化的不足，從根本上消除對(duì)象。當(dāng)然，由于是特定的應(yīng)用系統(tǒng)，使用范圍窄。

1 垃圾收集優(yōu)化

垃圾收集問(wèn)題是內(nèi)存對(duì)象管理中最重要的問(wèn)題之一，也是影響系統(tǒng)性能的關(guān)鍵因素。因此，最初針對(duì)內(nèi)存對(duì)象管理問(wèn)題的解決方法都是從垃圾收集入手。

1.1 垃圾收集調(diào)優(yōu)

垃圾收集調(diào)優(yōu)是最傳統(tǒng)的垃圾收集優(yōu)化技術(shù)，也是一些長(zhǎng)時(shí)間運(yùn)行的低延遲Web服務(wù)所推薦的方法。一些開源分布式數(shù)據(jù)處理系統(tǒng)，例如Cassandra和HBase都使用以延遲為中心的方法來(lái)避免長(zhǎng)時(shí)間垃圾收集開銷[7]。以上所述垃圾收集調(diào)優(yōu)方法的關(guān)鍵在于：用標(biāo)記清除算法（CMS）的垃圾收集控制器代替原有以吞吐量為中心的垃圾收集；調(diào)整標(biāo)記清除算法的垃圾收集控制器參數(shù)以降低垃圾收集開銷。

1.2 垃圾收集算法優(yōu)化

目前的垃圾收集算法有引用計(jì)數(shù)法、標(biāo)記清除算法、拷貝收集算法等，不同的垃圾收集算法讓內(nèi)存對(duì)象管理有更多的選擇來(lái)處理對(duì)象的回收。垃圾收集算法的優(yōu)化性能要到達(dá)最優(yōu)一般有特定場(chǎng)景，例如非統(tǒng)一內(nèi)存訪問(wèn)（NUMA）感知的垃圾回收器[8]。并且，垃圾收集算法的優(yōu)化只是掩蓋了內(nèi)存對(duì)象管理的問(wèn)題，內(nèi)存對(duì)象的自動(dòng)化管理存在的問(wèn)題仍然存在，頻繁調(diào)用垃圾收集的本質(zhì)因素沒(méi)有解決。

1.3 程序語(yǔ)言優(yōu)化

分布式數(shù)據(jù)處理系統(tǒng)使用高級(jí)面向?qū)ο笳Z(yǔ)言進(jìn)行開發(fā)會(huì)導(dǎo)致內(nèi)存對(duì)象管理的問(wèn)題，而傳統(tǒng)的面向機(jī)器的語(yǔ)言，如C、C++，則不存在內(nèi)存對(duì)象管理存在的問(wèn)題。為了追求性能上的優(yōu)勢(shì)，一部分企業(yè)機(jī)構(gòu)會(huì)選擇用這些傳統(tǒng)的語(yǔ)言來(lái)改寫目前的分布式數(shù)據(jù)處理系統(tǒng)，但是失去了高級(jí)語(yǔ)言特性的系統(tǒng)開發(fā)難度非常之大，并且不利于系統(tǒng)的更新。

2 對(duì)象存儲(chǔ)的優(yōu)化策略

垃圾收集的優(yōu)化并沒(méi)有考慮內(nèi)存對(duì)象管理所存在的問(wèn)題的本質(zhì)，即內(nèi)存中的對(duì)象仍然是自動(dòng)化管理的。所以一些系統(tǒng)將對(duì)象用序列化的方式存放到內(nèi)存以減少內(nèi)存的占用來(lái)防止頻繁垃圾收集，或者將常規(guī)的內(nèi)存對(duì)象管理方法替換為針對(duì)對(duì)象標(biāo)記回收的區(qū)域內(nèi)存管理方法來(lái)消除垃圾收集。這一類方法從內(nèi)存對(duì)象管理的本質(zhì)上考慮了性能問(wèn)題。

2.1 序列化存儲(chǔ)

目前的分布式數(shù)據(jù)處理系統(tǒng)，如Hadoop和Spark，都支持將中間數(shù)據(jù)對(duì)象序列化為byte數(shù)組，從而減少對(duì)象在內(nèi)存中存儲(chǔ)的占用。Hadoop系統(tǒng)中的對(duì)象大部分都是臨時(shí)的數(shù)據(jù)對(duì)象，因此Hadoop僅將Map的輸出數(shù)據(jù)序列化成byte數(shù)據(jù)，存放到磁盤，然后通過(guò)Shuffle傳輸給reduce task。盡管不存在內(nèi)存對(duì)象管理的問(wèn)題，但是序列化機(jī)制確實(shí)對(duì)分布式數(shù)據(jù)處理系統(tǒng)有重要作用。Spark系統(tǒng)不僅在Shuffle階段提供序列化機(jī)制，還在Cache時(shí)提供了序列化選擇，Cache時(shí)Spark會(huì)將彈性分布式數(shù)據(jù)集（RDD）中的數(shù)據(jù)保存到內(nèi)存，用戶可以選擇是否采用序列化保存數(shù)據(jù)。Spark之所以支持非序列化保存，是因?yàn)樾蛄谢瘷C(jī)制存在序列化和反序列化的開銷。一般來(lái)說(shuō)，序列化機(jī)制能夠有效降低內(nèi)存對(duì)象的占用，但是要在Cache數(shù)據(jù)對(duì)象時(shí)執(zhí)行序列化操作，而在使用對(duì)象時(shí)執(zhí)行反序列化操作。

序列化存儲(chǔ)降低了內(nèi)存對(duì)象的占用，但是應(yīng)用仍然基于對(duì)象執(zhí)行的。因此在序列化和反序列化的基礎(chǔ)上，內(nèi)存對(duì)象管理仍然需要考慮中間對(duì)象的管理，當(dāng)數(shù)據(jù)量大時(shí)，對(duì)象的回收仍然會(huì)影響系統(tǒng)的性能[9]。

2.2 基于區(qū)域的內(nèi)存管理

無(wú)論是基于垃圾收集調(diào)優(yōu)還是序列化存儲(chǔ)，都是由內(nèi)存管理機(jī)制自動(dòng)標(biāo)注對(duì)象的生命周期，始終存在對(duì)象的操作，就必然會(huì)需要內(nèi)存管理機(jī)制根據(jù)標(biāo)注回收無(wú)需再使用的對(duì)象，也就必然會(huì)導(dǎo)致垃圾收集。從內(nèi)存對(duì)象相反的一個(gè)方向分析，C、C++等語(yǔ)言完全手動(dòng)的標(biāo)注內(nèi)存中使用的對(duì)象，手動(dòng)的回收對(duì)象?；趨^(qū)域的內(nèi)存管理綜合了自動(dòng)化和完全手動(dòng)標(biāo)注內(nèi)存對(duì)象的兩種策略，采取了繞過(guò)垃圾收集的策略，將一部分對(duì)象統(tǒng)一標(biāo)記后直接存儲(chǔ)到堆外區(qū)域，整塊回收區(qū)域內(nèi)的對(duì)象，從而消除頻繁垃圾收集，解決內(nèi)存對(duì)象管理的問(wèn)題。

FACADE[10]系統(tǒng)是基于區(qū)域的內(nèi)存管理的典型實(shí)例。FACADE以程序分析為基礎(chǔ)，在程序代碼中由用戶標(biāo)識(shí)需要轉(zhuǎn)換的Java對(duì)象。FACADE會(huì)首先識(shí)別用戶標(biāo)注的Java對(duì)象，將其轉(zhuǎn)換為輕量級(jí)的FACADE對(duì)象并通過(guò)byte形式保存FACADE到堆外內(nèi)存，極大地減少了對(duì)象對(duì)內(nèi)存的占用，而FACADE相比序列化更加進(jìn)一步消除對(duì)象之處在于它同時(shí)轉(zhuǎn)換了Java對(duì)象的操作代碼。用戶自定義的操作函數(shù)是基于Java對(duì)象的，F(xiàn)ACADE轉(zhuǎn)換Java對(duì)象為FACADE對(duì)象后，同時(shí)將操作函數(shù)轉(zhuǎn)換為基于FACADE對(duì)象的操作函數(shù)，完全實(shí)現(xiàn)了對(duì)象的消除。FACADE的內(nèi)存對(duì)象管理采取了整塊分配和整塊回收的原則，一方面配合FACADE對(duì)象的存儲(chǔ)方式；一方面減少了垃圾收集開銷，相比傳統(tǒng)的內(nèi)存對(duì)象管理取得了非常好的效果。

盡管FACADE的內(nèi)存對(duì)象管理已經(jīng)從很大程度上解決了對(duì)象管理的垃圾收集問(wèn)題，但是它基于一個(gè)很強(qiáng)烈的假設(shè)：在整塊分配和整塊回收的操作間隔內(nèi)的所有對(duì)象在內(nèi)存中的存活時(shí)間都是相同的。在一些分布式數(shù)據(jù)處理系統(tǒng)中，例如Spark和Flink，將作業(yè)劃分為有向無(wú)環(huán)圖，按照每個(gè)階段執(zhí)行。這類系統(tǒng)中的數(shù)據(jù)對(duì)象在內(nèi)存中的存活時(shí)間就非常復(fù)雜，如果有用戶將數(shù)據(jù)Cache到內(nèi)存，數(shù)據(jù)對(duì)象的存活時(shí)間持續(xù)整個(gè)作業(yè)執(zhí)行期；如果是Shuffle階段的數(shù)據(jù)對(duì)象，數(shù)據(jù)對(duì)象可能會(huì)在多個(gè)階段的執(zhí)行期內(nèi)都存活在內(nèi)存中。所以，F(xiàn)ACADE在內(nèi)存對(duì)象的管理上忽略了內(nèi)存對(duì)象的生命周期。

Broom[11]綜合考慮了基于區(qū)域的內(nèi)存管理的特點(diǎn)以及內(nèi)存對(duì)象的生命周期的特點(diǎn)，Broom以NET CLR平臺(tái)為研究對(duì)象，將內(nèi)存對(duì)象的存放區(qū)域進(jìn)一步區(qū)分為：可轉(zhuǎn)移區(qū)域，用來(lái)存放操作的傳遞消息，同一時(shí)間只有一個(gè)操作可以訪問(wèn)該區(qū)域；操作所需區(qū)域，針對(duì)某個(gè)操作私有的對(duì)象存儲(chǔ)區(qū)域，該區(qū)域內(nèi)的對(duì)象的生命周期與相應(yīng)的操作生命周期相同；臨時(shí)區(qū)域，存放一些臨時(shí)的數(shù)據(jù)對(duì)象。由于Broom基于閉源的系統(tǒng)實(shí)現(xiàn)而且作為short paper對(duì)系統(tǒng)實(shí)現(xiàn)提及較少，所以能夠獲取的信息只在于基于區(qū)域的內(nèi)存管理與內(nèi)存對(duì)象生命周期特點(diǎn)的結(jié)合是消除垃圾收集所必須考慮的兩個(gè)因素。

3 特定應(yīng)用領(lǐng)域的優(yōu)化

大多優(yōu)秀的開源分布式數(shù)據(jù)處理系統(tǒng)，如Hadoop和Spark，都基于底層的系統(tǒng)實(shí)現(xiàn)了上層應(yīng)用領(lǐng)域的生態(tài)系統(tǒng)[12]，例如Spark生態(tài)系統(tǒng)包括Spark SQL、Spark Streaming、Spark GraphX和Spark MLlib。特定應(yīng)用領(lǐng)域的分布式數(shù)據(jù)處理系統(tǒng)在底層數(shù)據(jù)系統(tǒng)的基礎(chǔ)上定義了特定的計(jì)算結(jié)構(gòu)，從而可以實(shí)現(xiàn)更加復(fù)雜的內(nèi)存對(duì)象管理機(jī)制。在最初Java等高級(jí)語(yǔ)言被應(yīng)用在數(shù)據(jù)分析系統(tǒng)時(shí)，除了受益于高級(jí)語(yǔ)言的特性，一些系統(tǒng)也意識(shí)到其在內(nèi)存對(duì)象管理上的不足，因此結(jié)合特定的結(jié)構(gòu)進(jìn)行優(yōu)化[13]，例如SQL。Shark等針對(duì)data-intensive的數(shù)據(jù)庫(kù)管理系統(tǒng)，將Java對(duì)象轉(zhuǎn)化為Telegraph數(shù)據(jù)流，在內(nèi)存分配上整存整取，繞過(guò)Java的內(nèi)存管理方法[14]。Shark使用基于列的內(nèi)存存儲(chǔ)和動(dòng)態(tài)查詢優(yōu)化來(lái)提高SQL查詢的性能。Apache項(xiàng)目Tungsten基于Spark SQL實(shí)現(xiàn)，將傳統(tǒng)的關(guān)系表結(jié)果轉(zhuǎn)換為以列為結(jié)構(gòu)的字節(jié)序列，同時(shí)將SQL操作全部轉(zhuǎn)換為基于字節(jié)序列的操作。

分布式數(shù)據(jù)處理系統(tǒng)內(nèi)存對(duì)象管理的解決方案各具優(yōu)點(diǎn)和缺點(diǎn)，具體見表1。

4 結(jié)束語(yǔ)

分布式數(shù)據(jù)處理系統(tǒng)按照數(shù)據(jù)流的路徑可以分為控制路徑和數(shù)據(jù)路徑，控制路徑由系統(tǒng)框架支持和實(shí)現(xiàn)，數(shù)據(jù)路徑由用戶定義和實(shí)現(xiàn)。我們發(fā)現(xiàn)：控制路徑的編程實(shí)現(xiàn)更多的從對(duì)象模型的高級(jí)特性中獲益，包括類型的運(yùn)行時(shí)動(dòng)態(tài)識(shí)別、并發(fā)同步操作的偏向鎖優(yōu)化和自動(dòng)對(duì)象內(nèi)存管理等。數(shù)據(jù)路徑的編程實(shí)現(xiàn)很少使用語(yǔ)言的高級(jí)特性。數(shù)據(jù)路徑的實(shí)現(xiàn)由用戶自定義，具體包括用戶自定義類型（UDT）和用戶自定義方法（UDF）。UDT定義的是數(shù)據(jù)路徑中實(shí)際操作的對(duì)象類型，而UDF定義了對(duì)這些數(shù)據(jù)類型執(zhí)行的操作。UDT通常是基本類型的淺層組合和常用方法的實(shí)現(xiàn)封裝，很少會(huì)使用復(fù)雜的繼承層次和多態(tài)。

比如，通過(guò)定義接口來(lái)抽象化模塊之間的交互，進(jìn)而通過(guò)工廠模式，依賴注入來(lái)支持靈活的模塊和插件加載，而這些設(shè)計(jì)模式依賴于多態(tài)和反射等語(yǔ)言特性?？蚣茇?fù)責(zé)任務(wù)的并行化執(zhí)行和同步機(jī)制，因此依賴于托管環(huán)境的并發(fā)執(zhí)行模型，比如線程創(chuàng)建和加鎖操作。由于并發(fā)執(zhí)行由框架負(fù)責(zé)，UDF本身都是串行代碼，在UDF內(nèi)部使用加鎖操作通常沒(méi)有意義，更不可能會(huì)在UDT數(shù)據(jù)對(duì)象上加鎖。因此，UDT并不依賴于一個(gè)復(fù)雜的對(duì)象模型實(shí)現(xiàn)。比如：（1）當(dāng)沒(méi)有多態(tài)導(dǎo)致的虛方法派發(fā)時(shí)，也沒(méi)有使用反射時(shí)，不需要在對(duì)象頭部記錄對(duì)象的運(yùn)行時(shí)類型；（2）當(dāng)對(duì)象沒(méi)有加鎖操作時(shí)，也不需要在頭部存儲(chǔ)偏向鎖狀態(tài)；（3）UDT數(shù)據(jù)對(duì)象的生命周期具有很強(qiáng)的規(guī)律性，如果能夠跳過(guò)JVM的內(nèi)存管理，不僅消除了垃圾收集的CPU開銷，也不需要在對(duì)象頭部存儲(chǔ)垃圾收集所需的狀態(tài)信息。

最重要的一點(diǎn)是：數(shù)據(jù)對(duì)象的生命周期具有很強(qiáng)的規(guī)律性。我們發(fā)現(xiàn)：在以Spark為代表的新一代通用數(shù)據(jù)并行系統(tǒng)中，作業(yè)執(zhí)行時(shí)通常有幾類數(shù)據(jù)容器會(huì)持有數(shù)據(jù)對(duì)象，而數(shù)據(jù)對(duì)象的生命周期和持有它的數(shù)據(jù)容器的生命周期有很強(qiáng)的關(guān)聯(lián)性：

（1）UDF變量。包括UDF對(duì)象的字段和UDF局部變量，前者的生命周期剛好為一個(gè)任務(wù)的執(zhí)行時(shí)間，其存活時(shí)間內(nèi)時(shí)所持有的對(duì)象生命周期由該字段的賦值操作決定，但最長(zhǎng)不超過(guò)任務(wù)的執(zhí)行時(shí)間；后者的生命周期為一次UDF方法的調(diào)用，因此其持有的數(shù)據(jù)對(duì)象最多存活一次方法調(diào)用，可以視為臨時(shí)對(duì)象。

（2）緩存數(shù)據(jù)集。緩存數(shù)據(jù)集的生命周期由應(yīng)用程序顯示決定，其持有的數(shù)據(jù)對(duì)象的生命周期具有與該RDD等同的生命周期。

（3）Shuffle緩沖區(qū)。不考慮溢出到磁盤的情況，Shuffle緩沖區(qū)的生命周期也剛好為一個(gè)任務(wù)的執(zhí)行時(shí)間。其持有的數(shù)據(jù)對(duì)象的生命周期較為復(fù)雜，在聚合計(jì)算的過(guò)程中，Shuffle buffer僅為一個(gè)Key數(shù)據(jù)對(duì)象保存一個(gè)數(shù)據(jù)對(duì)象作為當(dāng)前聚合的結(jié)果。

一種可行的方法是通過(guò)自動(dòng)轉(zhuǎn)換數(shù)據(jù)處理應(yīng)用程序來(lái)減少程序運(yùn)行時(shí)創(chuàng)建的UDT數(shù)據(jù)對(duì)象的數(shù)量。轉(zhuǎn)換工作對(duì)應(yīng)用開發(fā)人員完全透明，不會(huì)限制數(shù)據(jù)并行編程模型的表達(dá)能力和靈活性。

致謝

本研究得到華中科技大學(xué)金海教授的指導(dǎo)，謹(jǐn)致謝意！

參考文獻(xiàn)

[1] JONES R， HOSKING A， MOSS E. The Garbage Collection Handbook ： the Art of Automatic Memory Management [M]. USA： CRC Press， 2012

[2] ZAHARIA M， CHOWDHURY M， DAS T， et al. Resilient Distributed Datasets： a Fault-Tolerant Abstraction for in-Memory Cluster Computing [C]//Proceeding in 9th USENIX Conference on Networked Systems Design and Implementation （NSDI）. USA： USENIX Association， 2012： 141-146

[3] Cassandra Garbage Collection Tuning， Find and Fix Long GC Pauses [EB/OL]. [2013-11-14]. http：//aryanet.com/blog/cassandra-garbage-collector-tuning

[4] Laboratory for Web Algorithmic [EB/OL]. [2014-10-12].http：//law.di.unimi.it/datasets.php

[5] CARPENTER B， FOX G， KO S H， et al. Object Serialization for Marshalling Data in a Java Interface to MPI[C]//ACM Java Grande Conference. USA： ASM， 1970： 66-67

[6] MADS T， JEAN-PIERRE T. Region-Based Memory Management [J]. Information & Computation， 1997， 132（2）：109-176

[7] The Garbage Collector and Apache Hbase [EB/OL]. （2016-02-18）[2014-03-22].http：//hbase.apache.org/book.html#gc

[8] 浦云明. JAVA垃圾收集器算法分析及垃圾收集器的運(yùn)行透視[J]. 計(jì)算機(jī)系統(tǒng)應(yīng)用， 2003 （11）： 39-41

[9] MILLER H， HALLER P， BURMAKO E， et al. Instant Pickles： Generating Object-Oriented Pickler Combinators for Fast and Extensible Serialization [J]. ACM Sigplan Notices， 2013， 48（10）：183-202

[10] NGUYEN K， WANG K， BU Y， et al. FACADE： A Compiler and Runtime for （Almost） Object-Bounded Big Data Applications [J]. ACM Sigplan Notices， 2015， 50（4）：675-690. DOI： 10.1145/2775054.2694345

[11] GOH I， GICEVA J， SCHWARZKOPF M， et al. Broom： Sweeping Out Garbage Collection from Big Data Systems [C]//15th Workshop on Hot Topics in Operating Systems （HotOS XV）. USA： ACM， 2015

[12] 胡俊， 胡賢德， 程家興. 基于Spark的大數(shù)據(jù)混合計(jì)算模型[J]. 計(jì)算機(jī)系統(tǒng)應(yīng)用， 2015（4）： 214-218

[13] SHAH M A， FRANKLIN M J， MADDEN S， et al. Java Support for Data-Intensive Systems： Experiences Building the Telegraph Dataflow System [J]. Sigmod Record， 2001， 30（4）：103-114

[14] XIN R. S， ROSEN J， ZAHARIA M， et al. Shark： SQL and Rich Analytics at Scale[C]// Proceedings of the 2013 ACM SIGMOD International Conference on Management of Data. USA： ASM， 2013：13-24. DOI： 10.1145/2463676.2465288