近年以來，大數(shù)據(jù)應(yīng)用取得了長足的進(jìn)展，各種大數(shù)據(jù)處理框架也應(yīng)運(yùn)而生，并得到了業(yè)界的高度認(rèn)可，如Hadoop生態(tài)、Spark系列、Flink、Cassandra、Hive等等。這類編程模型通常采用分治的思想，將大的數(shù)據(jù)處理作業(yè)拆分為多個小的計算任務(wù)，分配到分布式集群中的不同節(jié)點中運(yùn)行，然后將結(jié)果匯聚起來，得出最終結(jié)果。

由于使用習(xí)慣等關(guān)系，業(yè)內(nèi)主流的大數(shù)據(jù)處理框架都采用Java語言進(jìn)行編寫。原因在于以下幾點：

1、很多程序開發(fā)人員對于Java語言比較熟悉，使用起來輕車熟路；

2、Java提供了便捷的自動內(nèi)存管理機(jī)制，避免了用戶在處理內(nèi)存過程中可能出現(xiàn)的問題；

3、Java基于JVM運(yùn)行的特性使得Java程序可以一次編寫，多處運(yùn)行，擺脫分布式集群中不同操作系統(tǒng)和硬件處理框架帶來的束縛，使得開發(fā)者可以更加專注于代碼邏輯的開發(fā)；

4、Java語言擁有成熟的社區(qū)和豐富的編程資源，可以實現(xiàn)快速開發(fā)，出現(xiàn)問題也可以快速尋求幫助。

正是基于這些優(yōu)點，Java語言成為了目前最主流大數(shù)據(jù)編程技術(shù)。但是，在實際使用的過程中，開發(fā)者們發(fā)現(xiàn)了一系列JVM相關(guān)的性能瓶頸，主要包括以下幾個方面：

1、垃圾回收（GC）占用時間長，在一些大數(shù)據(jù)應(yīng)用中，GC時間甚至可以達(dá)到總執(zhí)行時間的50%；

2、GC頻率高，造成任務(wù)執(zhí)行頻繁暫停，應(yīng)用吞吐率降低，響應(yīng)延遲升高；

3、GC算法擠占應(yīng)用線程CPU資源，存在GC線程競爭時，大數(shù)據(jù)應(yīng)用執(zhí)行時間增長可達(dá)60%；

4、數(shù)據(jù)對象在分布式節(jié)點間傳輸時需要序列化和反序列化，在某些大數(shù)據(jù)應(yīng)用中，用時占比可達(dá)30%；

5、JVM冷啟動時需要大量的類加載和代碼即時編譯工作，在應(yīng)用執(zhí)行中的用時可達(dá)數(shù)十秒；

6、JVM運(yùn)行和維護(hù)需要內(nèi)存消耗，在內(nèi)存緊張的情況下，可能因為內(nèi)存耗盡或內(nèi)存碎片觸發(fā)OOM錯誤。

總的來說，這些問題的產(chǎn)生，可以歸納為以下一些原因：

1、內(nèi)存使用壓力增大

與普通的Java應(yīng)用不同，大數(shù)據(jù)應(yīng)用是“內(nèi)存密集”型的，應(yīng)用的內(nèi)存使用量更大，在大數(shù)據(jù)處理框架下，JVM的內(nèi)存使用壓力具體來源于：

（1）大數(shù)據(jù)應(yīng)用數(shù)據(jù)計算和存儲產(chǎn)生的大量內(nèi)存消耗，大量數(shù)據(jù)在計算過程中需要同時被讀取到內(nèi)存中，而一些應(yīng)用為了更進(jìn)一步加快處理速度，將中間數(shù)據(jù)的聚合和可重用數(shù)據(jù)也緩存在內(nèi)存當(dāng)中，這決定了JVM在執(zhí)行大數(shù)據(jù)應(yīng)用時將面對更大的內(nèi)存使用量；

（2）數(shù)據(jù)在JVM堆內(nèi)存當(dāng)中以對象的形式存儲需要額外的內(nèi)存占用，對象在JVM當(dāng)中的數(shù)據(jù)結(jié)構(gòu)包含了對象頭以及對其它對象的引用，而數(shù)據(jù)本身在對象中的空間占比往往不超過一半。這些對象的外殼伴隨著數(shù)據(jù)緩存在內(nèi)存當(dāng)中，也需要占用相當(dāng)數(shù)量的空間；

由于JVM垃圾回收機(jī)制的原因，會經(jīng)常觸發(fā)全局暫停，而這個問題很難通過簡單的增減內(nèi)存大小來解決，如果降低內(nèi)存大小，GC的觸發(fā)頻率會增加，對象被掃描和的去的次數(shù)增加，應(yīng)用程序的吞吐量相應(yīng)降低。可用內(nèi)存不足還會影響到應(yīng)用的正常緩存和處理機(jī)制，甚至引發(fā)內(nèi)存溢出。而如果提升內(nèi)存大小，單次GC則需要處理更多的數(shù)據(jù)對象，平均的暫停時間加長，應(yīng)用程序的最大延遲相應(yīng)增加。對于周期性標(biāo)記掃描的GC算法而言，還會在最終觸發(fā)GC之前消耗更多CPU時序進(jìn)行不必要的標(biāo)記。

2、內(nèi)存使用模式變化

大數(shù)據(jù)應(yīng)用中數(shù)據(jù)在內(nèi)存當(dāng)中保留的時間周期與普通應(yīng)用不盡相同。在傳統(tǒng)應(yīng)用中，堆內(nèi)存中創(chuàng)建的絕大部分對象在產(chǎn)生之后不久就不再被使用，經(jīng)典的GC算法正是基于這種內(nèi)存使用模式，將堆內(nèi)存進(jìn)行粗粒度的年代劃分，絕大部分瞬時對象會在針對年輕代的Minor GC當(dāng)中很快被清理。而大數(shù)據(jù)應(yīng)用產(chǎn)生的對象有兩種，一種是由控制大數(shù)據(jù)處理框架運(yùn)行邏輯的代碼產(chǎn)生的，即控制路徑對象，它們的內(nèi)存使用模式一般依舊符合弱世代假設(shè)。另一種是輸入數(shù)據(jù)和計算中間數(shù)據(jù)在大數(shù)據(jù)處理框架中封裝生產(chǎn)的，統(tǒng)稱為數(shù)據(jù)路徑對象。這種對象的內(nèi)存使用模式要更加復(fù)雜，它們可能在內(nèi)存中長時間累積或緩存，也可能在一個迭代輪次后被清理和輸出。通常來說，數(shù)據(jù)路徑所創(chuàng)建的對象數(shù)量遠(yuǎn)超控制路徑。傳統(tǒng)GC算法并不能適應(yīng)大數(shù)據(jù)環(huán)境下內(nèi)存使用模式的這種變化，原因在于：

（1）當(dāng)前GC算法下，長時間存活的數(shù)據(jù)路徑對象最終都會晉升到老年代中，它們在數(shù)次Minor GC當(dāng)中幸存并最終晉升的過程中，需要在內(nèi)存中多次移動。而對象移動是GC循環(huán)當(dāng)中最耗時的部分，每一次移動都意味著內(nèi)存讀寫，而內(nèi)存位置的改變也需要對相關(guān)引用的指針進(jìn)行更新。考慮到數(shù)據(jù)路徑對象的數(shù)量極為龐大，整個晉升過程會消耗大量CPU時間，觸發(fā)多次GC暫停；

（2）數(shù)據(jù)路徑對象在晉升到老年代之后，在作業(yè)執(zhí)行的時間尺度上，短時間內(nèi)也不會被回收。傳統(tǒng)的GC算法不會考慮這些對象的存活時間，在涉及到老年代空間的MajorGC或者M(jìn)ixed GC之前還是會整個堆內(nèi)存空間進(jìn)行標(biāo)記掃描，這些標(biāo)記掃描過程對于長時間存活的數(shù)據(jù)對象來說是不必要的。當(dāng)長時間存活對象占用老年代的比例過高，每次傳出較大代價的Major GC就只能回收有限大小的空間，可能造成GC頻繁觸發(fā)，部分緩存數(shù)據(jù)被迫轉(zhuǎn)移到磁盤，甚至出現(xiàn)OOM錯誤，浪費大量的CPU時間和全局暫停時間，影響到應(yīng)用執(zhí)行效率。

3、JVM與上層框架存在隔閡

大數(shù)據(jù)處理框架將計算任務(wù)分配到各個執(zhí)行器JVM節(jié)點之后，并不會干預(yù)JVM的具體執(zhí)行過程，每個執(zhí)行器JVM獨立運(yùn)行，并不感知分布式集群中其它執(zhí)行器JVM的執(zhí)行情況，作業(yè)的整體進(jìn)度，以及集群和節(jié)點的內(nèi)存資源使用情況，只是根據(jù)自身的運(yùn)行狀態(tài)作出觸發(fā)GC，調(diào)整堆內(nèi)存，進(jìn)行代碼即時編譯等決策，而這些決策從歷史和全局的角度上觀察可能并不是最優(yōu)的。原因在于：

（1）JVM不清楚任務(wù)執(zhí)行產(chǎn)生的數(shù)據(jù)對象特征，例如對象數(shù)量、內(nèi)存占用大小、生命周期等，只能根據(jù)弱世代假說，對所有對象進(jìn)行統(tǒng)一的管理。由于大數(shù)據(jù)應(yīng)用產(chǎn)生的大量對象長時間存活，JVM的內(nèi)存管理效率會受到嚴(yán)重影響，而這些對象本可以通過大數(shù)據(jù)框架對用戶代碼和數(shù)據(jù)流的全局靜態(tài)分析進(jìn)行甄別。

（2）大數(shù)據(jù)處理框架并不考慮JVM具體的內(nèi)存管理機(jī)制，將所有JVM節(jié)點的內(nèi)存當(dāng)做連續(xù)的全局地址空間，但是實際上JVM在GC算法下對堆內(nèi)存采取分代管理，存在非連續(xù)區(qū)域，對象在內(nèi)存中離散分布，另外大數(shù)據(jù)處理框架在采用全局地址空間的物理架構(gòu)下，可能產(chǎn)生大量跨節(jié)點對對象引用，給JVM的GC任務(wù)帶來了遠(yuǎn)程內(nèi)存訪問的負(fù)擔(dān)。

（3）大數(shù)據(jù)處理框架下的JVM之間不清楚彼此的運(yùn)行情況，如果大數(shù)據(jù)操作需要在各個JVM之間同步，由于JVM獨立進(jìn)行GC決策，大數(shù)據(jù)操作的執(zhí)行就可能被不同的JVM的GC連續(xù)打斷，另外由于互相不感知，處于同一物理節(jié)點的JVM之間可能內(nèi)存資源分配不合理，而大數(shù)據(jù)框架在相關(guān)問題上缺少統(tǒng)籌協(xié)調(diào)。

因此，開發(fā)者們需要針對這些問題產(chǎn)生的原因，進(jìn)行針對性優(yōu)化。我們下次文章將會繼續(xù)討論這個問題。