作者簡介

NekoMatryoshka，攜程酒店資深后端開發(fā)工程師，主要工作是緩存類組件的開發(fā)維護，并對業(yè)務(wù)應(yīng)用的排障和優(yōu)化有所關(guān)注。

(相關(guān)資料圖)

一、背景和目標

在容器化部署成為主流的現(xiàn)在，降低集群中單個容器的資源需求的意義已經(jīng)不只限于更少的硬件成本，同時也意味著整個集群更加輕量化，這通常會帶來一系列其他優(yōu)勢：例如更短的恢復(fù)時間，更精確的資源控制和調(diào)度，和更快速的伸縮和部署等。但在另一方面，一味的追求壓縮容器配置必然會嚴重影響應(yīng)用在穩(wěn)定性、響應(yīng)耗時和吞吐量等方面的表現(xiàn)，所以輕量化的措施需要在多個性能維度上進行仔細的權(quán)衡取舍，以達到一個總體更優(yōu)的結(jié)果。

作為攜程計算量最大的接口之一，酒店查詢服務(wù)一直承擔(dān)著沉重的硬件成本壓力，僅僅詳情頁集群就包含了千余臺服務(wù)器實例和數(shù)十TB的Redis資源，因此對應(yīng)用進行全面的輕量化有著很高的必要性和預(yù)期收益。在內(nèi)存方向上，我們的主要目標是將單個容器的內(nèi)存從32GB壓縮到16GB，并在以下兩個基本方向上進行了探索：

減少內(nèi)存增長速度：壓縮本地緩存，減少浮動內(nèi)存的產(chǎn)生，并對線程，類庫，參數(shù)和代碼邏輯進行針對性的優(yōu)化和調(diào)整。提升內(nèi)存管理效率：加強JVM等服務(wù)依賴的基礎(chǔ)組件其本身的性能。

由于第一個方向需要根據(jù)應(yīng)用的具體代碼實現(xiàn)來分析和排查，普適性相對較差，所以本文將主要分享查詢服務(wù)在輕量化中對于內(nèi)存管理方向上的探索過程和實踐經(jīng)驗。

二、堆內(nèi)內(nèi)存管理

我們的應(yīng)用原本運行在JDK8的CMS收集器之上，但是在JDK11以后，CMS已經(jīng)被完全淘汰。于是，要提高堆內(nèi)的內(nèi)存管理效率，我們首先嘗試的便是對GC進行升級和調(diào)優(yōu)。因此我們對G1、ZGC和ShenandoahGC等更現(xiàn)代的收集器進行了性能上的測試和對比，來嘗試找出最合適的技術(shù)選型。

2.1 垃圾收集器的選型

首先，在JDK17上，ZGC第一次以生產(chǎn)環(huán)境可用的狀態(tài)登陸了LTS版本，所以我們這次選型起初的目標也是嘗試將應(yīng)用遷移到ZGC之上。相對于大家熟悉的G1，ZGC最主要的優(yōu)勢在于其通過著色指針和讀屏障兩個特性，使得用戶線程幾乎可以全程與標記-復(fù)制算法并行，基本解決了YGC的STW問題。簡單來說，ZGC在標記過程中會向64位指針的高位4bit中記錄三色標記、重分配標記和可達性標記；當(dāng)應(yīng)用線程訪問對象時，讀屏障機制會依據(jù)指針狀態(tài)和復(fù)制表信息去更新對象的地址和狀態(tài)。

這樣，即使GC線程正在后臺轉(zhuǎn)移、復(fù)制或清理對象，也可以保證前臺線程能始終訪問到正確的地址，這使得ZGC幾乎可以做到無停頓回收。除此之外，ZGC還向用戶承諾了可擴展性：由于ZGC的停頓時間基本只和初始掃描中GC Roots的數(shù)量相關(guān)，堆的大小和活躍對象的數(shù)量并不會導(dǎo)致停頓時間的增長。

其次，ShenandoahGC與ZGC同為新一代的零停頓收集器，總體來看，其內(nèi)存布局非常類似于G1，而并發(fā)設(shè)計則與ZGC如出一轍，所以我們也將其作為一個可能的備選方案。

ShenandoahGC與ZGC的主要區(qū)別在于其使用的是Brook指針而非染色指針：即在對象頭中額

外記錄一個指向復(fù)制后正確地址的指針。但是由于額外信息記錄在對象頭中，Brook指針的讀屏障無法在第一次訪問后直接更新正確地址來自我恢復(fù)。另一方面，ShenandoahGC的區(qū)塊布局和回收階段則與G1非常相似，甚至部分代碼都是直接復(fù)用的。其不同主要在于ShenandoahGC利用了一個被稱為連接矩陣的二維數(shù)組來取代G1中開銷巨大的記憶集，來解決跨區(qū)引用問題：例如區(qū)塊N引用了區(qū)塊M，則在數(shù)組的`[N][M]`坐標打上標記。

最后，作為現(xiàn)在最主流的收集器，同時也是CMS的取代者，G1理所應(yīng)當(dāng)?shù)囊脖晃覀冏鳛樽畛墒旌头€(wěn)妥的一個選擇。G1本身的內(nèi)存布局使得其對可控的停頓耗時和吞吐量的平衡上有較好的兼顧，在理論上使它更適合查詢接口這種會短時間內(nèi)突然生成大量臨時對象的計算密集型應(yīng)用。

綜上所述，我們以原本在輕量化前的生產(chǎn)配置（16C32G+JDK1.8+CMS）作為基準，選取了以下幾個組合作為測試方案：

其他各相關(guān)參數(shù)都為默認配置。

2.2G1調(diào)優(yōu)實踐

在橫向比較不同收集器的性能之前，我們首先需要按應(yīng)用的需求對每個收集器做一些簡單的適配和調(diào)整，以發(fā)揮這些收集器的全部性能。由于G1是為開箱即用而準備的默認收集器，使用起來相對簡單，基本上只需要簡單設(shè)置下堆大小和線程數(shù)等參數(shù)即可。然而在實際使用中，我們?nèi)匀挥龅搅艘恍┬栴}，需要對關(guān)鍵某些參數(shù)進行控制。

（1）現(xiàn)象1：某個高壓力場景的計算集群的YGC頻率相對較高，GC吞吐量不足，最終甚至?xí)l(fā)FGC。

由于輕量化配置的資源本身就比較緊張，很難通過增加`ConcGCThreads`線程數(shù)來提升吞吐量，于是我們嘗試放寬了`MaxGCPauseMillis`來減少G1的回收壓力。作為G1最核心的參數(shù)，當(dāng)`MaxGCPauseMillis`過小時，G1會自動調(diào)整其他GC參數(shù)來盡可能滿足該目標，進而導(dǎo)致YGC非常頻繁并影響吞吐量。由于各個應(yīng)用的情況不同，需要開發(fā)人員手動進行基準測試來找到最合適的數(shù)值：當(dāng)我們把數(shù)值從200調(diào)整到300后，平均響應(yīng)有非常明顯的下降，而繼續(xù)上調(diào)的邊際效應(yīng)則很不明顯。

（2）現(xiàn)象2：應(yīng)用在長時間穩(wěn)定運行后，老年代突然大量上漲后卻不及時回收，在數(shù)小時內(nèi)老年代都維持高位，擠占年輕代的占比并影響到了YGC的停頓耗時。

由于查詢服務(wù)主要是無狀態(tài)的計算邏輯，除了一部分本地緩存外大部分的對象都是相對短命的，但是當(dāng)GC壓力上升的情況下仍然會有大量對象進入老年代。這里我們通過縮小`InitiatingHeapOccupancyPercent`來降低MGC的閾值，讓G1可以及時回收掉進入老年代的短命對象。

除此之外，我們也對JDK8、11和17上的G1進行過縱向?qū)Ρ?，發(fā)現(xiàn)實際反映到機器性能和響應(yīng)耗時維度上的區(qū)別非常小，在排除掉宿主機本身的硬件區(qū)別后幾乎可以忽略不計。最終，由于依賴類庫和監(jiān)控平臺等各種原因，最終選擇了相對成熟的JDK11作為G1的平臺。

2.3ZGC調(diào)優(yōu)實踐

與G1的普適明顯不同，對ZGC上的適配工作明顯困難的多，作為最現(xiàn)代的收集器之一，ZGC并不是萬用的銀彈，因此也并沒有成為JDK17的默認收集器。相比G1，ZGC并不能簡單的適配于所有場景，我們在試運行過程中遇到了一系列難以解決的問題，經(jīng)過大量的參數(shù)調(diào)整和性能測試后，才能發(fā)揮其全部的實力。

（1）現(xiàn)象1：在訪問量突然上漲時，會觀察到非常顯著的分鐘級響應(yīng)尖刺。

由于ZGC會使用之前數(shù)次的GC指標來預(yù)測下一次GC的回收策略，使得其相比CMS等傳統(tǒng)收集器更容易受到流量波動的沖擊，在高流量壓力下的魯棒性很差。解決響應(yīng)尖刺的辦法主要有兩個：首先是通過提高`ZAllocationSpikeTolerance`的數(shù)值來減少觸發(fā)GC的閾值，其次是打開周期性的主動回收參數(shù)`ZProactive`，并通過減少`ZCollectionInterval`來縮短兩次主動GC的間隔。兩個參數(shù)的具體數(shù)值需要開發(fā)人員手動調(diào)試確定，但是在高壓力下無論怎么調(diào)整參數(shù)，提升都相對有限。

（2）現(xiàn)象2：GC日志出現(xiàn)大量Allocation Stall/Rellocation Stall，同時監(jiān)控上發(fā)現(xiàn)秒級的STW出現(xiàn)，某些時候甚至伴有OOM報錯。

雖然ZGC的停頓時間很短，但整個回收階段很長，期間用戶線程一直處于并發(fā)運行的狀態(tài)。這使得回收過程中會產(chǎn)生大量的浮動垃圾，只能等到下次GC時再回收。此時如果浮動垃圾占滿了整個堆使得回收無法繼續(xù)，ZGC就會直接暫停對應(yīng)的用戶線程，來優(yōu)先執(zhí)行回收任務(wù)，同時在日志上記錄對應(yīng)線程的Allocation/Relocation Stall。簡而言之，Allocation Stall是一種當(dāng)GC吞吐量不夠時觸發(fā)的用戶線程暫停，大量秒級的Allocation Stall甚至比FGC的影響更大。

這種情況一般都是GC回收速度跟不上內(nèi)存申請速度導(dǎo)致的，如果GC資源相對充足的話，可以通過上面兩個主動GC參數(shù)來增加GC頻率，而如果GC資源本身就很匱乏，則只能通過增加GC線程數(shù)`ConcGCThreads`和`ParallelGCThreads`來根本性的解決問題。

（3）現(xiàn)象3：ZGC堆使用的RSS持續(xù)上升，其大小不會隨著內(nèi)存使用情況智能伸縮，最終導(dǎo)致了堆外溢出。

低版本的ZGC并不會主動將長期未使用的堆內(nèi)存返還給系統(tǒng)，JDK13后ZGC提供了`ZUncommitDelay`參數(shù)來設(shè)置將空閑內(nèi)存返還給OS的期限，可以通過縮短這個值來使得RSS空間被更加靈活的使用。為了保證生產(chǎn)環(huán)境服務(wù)的穩(wěn)定性，我們直接通過讓堆大小的上下限相同來防止堆的伸縮。

2.4 基準測試的結(jié)果

在實際試驗中，我們首先觀察到ZGC確實無愧于其零停頓收集器的名號，可以做到在全程任何情況下都達到百微秒級每次的停頓時間，每分鐘累計不超過1ms，同時CMS中令人困擾的FGC現(xiàn)象也不再成為問題。而與之原理相近的ShenandoahGC的性能表現(xiàn)也非常好，平均每分鐘的停頓時間也不超過10ms。G1與這些新一代的收集器相比雖然遜色許多，但是仍然能在僅僅使用生產(chǎn)配置一半的內(nèi)存下，達到比CMS更好的GC性能：其YGC停頓約下降了50%，每分鐘停頓約為200ms左右，并且MGC也基本可以滿足老年代的回收需要，數(shù)天時間內(nèi)沒有觀察到FGC。

但是隨著流量壓力的上升，我們很快發(fā)現(xiàn)作為首選的ZGC和ShenandoahGC等零停頓收集器實際上并不適合查詢接口這樣的運算密集型應(yīng)用：他們的運行顯著地依賴于資源開銷，最終嚴重擠占了業(yè)務(wù)邏輯的計算資源，使得響應(yīng)耗時飆升，服務(wù)趨于崩潰。

為了穩(wěn)定服務(wù)，我們不得不重新分配了更多計算資源并降低了流量，并得出了結(jié)論：即使使用了兩倍的線程資源，在CPU利用率三倍于CMS的情況下，ZGC和ShenandoahGC仍然只能達到相當(dāng)于生產(chǎn)環(huán)境約50%-60%的極限吞吐量。與之相對，G1在這方面的表現(xiàn)則好得多，在輕量化配置下比起生產(chǎn)配置的整體吞吐量僅稍有下降，在相同QPS下的CPU利用率變高了約5-7%，幾乎可以忽略不計。經(jīng)過后續(xù)排查，我們發(fā)現(xiàn)主要的原因是ZGC的四條ZWORKER線程幾乎每個都會100%的占用一個核心（如下圖），大量的吞吃了CPU資源并影響到了核心處理流程。

在內(nèi)存方面，ZGC的實際表現(xiàn)也并不盡如人意。ZGC不僅比傳統(tǒng)收集器記錄了更多的額外信息，且很多優(yōu)化和特性（例如字符串去重、分代、指針壓縮等）也暫時無法使用，這使得ZGC無論是堆內(nèi)還是堆外的內(nèi)存開銷都要明顯高于G1和CMS。測試中我們使用NMT和JMX簡單對比了各收集器在未接入流量一段時間內(nèi)的平均內(nèi)存開銷，發(fā)現(xiàn)ZGC的堆內(nèi)開銷大約比CMS高三分之一，堆外則高達CMS的10倍左右。

綜合來看，ZGC等零停頓收集器雖然可以達到10ms以下的每分鐘停頓時間，但是其占用的大量GC資源會嚴重影響核心計算邏輯。在資源緊張的輕量化場景下，切換至ZGC導(dǎo)致了服務(wù)在極限壓測中損失了相當(dāng)于100%生產(chǎn)流量的吞吐量，同時接口的響應(yīng)耗時上升了70%。與之相對，G1在響應(yīng)耗時上的表現(xiàn)則幾乎與原來相同，各細節(jié)指標上也僅僅只有CPU利用率略差。

2.5 遷移到JDK11

由于ZGC和ShenandoahGC在測試中表現(xiàn)不佳，且各種問題在資源緊張的限制下幾乎無法解決，我們最終將目光轉(zhuǎn)向了更為成熟穩(wěn)定的G1+JDK11的組合。從JDK8遷移到11是兩個連續(xù)的LTS版本之間的遷移，比起直接遷移到17來說簡單很多。我們在實際遷移中主要遇到了三個類型的問題：官方類庫缺失，權(quán)限控制，以及第三方類庫報錯。

官方類庫缺失：JDK11中移除了一系列官方類庫，其中部分類庫只是從rt.jar中被拆分，可以簡單的通過maven補回，例如javax.*，但是其他一些包含危險操作的類庫則被直接刪除，例如jdk.nashorn，sun.misc等，一般也可以通過重寫來繞過這些代碼。?權(quán)限控制：JDK11中對各種權(quán)限做了更精細的控制。例如自代理需要使用參數(shù)??-Djdk.attach.allowAttachSelf???控制，而跨類庫的反射權(quán)限則需要用??--add-exports=???和??--add-exports??來打開。如果未能注意到這些參數(shù)則會造成大量權(quán)限控制報錯。?第三方類庫報錯：此類報錯一般都是兼容性問題導(dǎo)致，Lombok和AspectJ等類庫需要根據(jù)JDK版本來選擇對應(yīng)的類庫版本。主要排查難點在于報錯的形式五花八門，報錯信息對定位幾乎沒有幫助，有時候很難確定是哪個類庫導(dǎo)致的。三、堆外內(nèi)存管理

一般來說，對于運行在容器中的單個Java應(yīng)用，大部分堆外相關(guān)的細節(jié)都會被虛擬機給屏蔽掉，導(dǎo)致開發(fā)人員往往很少會深入到相關(guān)問題。然而，由于這次輕量化后剩余的內(nèi)存資源非常緊張，我們被迫給堆外留下了非常有限的空間，導(dǎo)致了后續(xù)測試過程中出現(xiàn)的一系列問題。

3.1 問題表象與排查

具體來說，在生產(chǎn)測試中，我們經(jīng)常觀察到應(yīng)用經(jīng)常在半夜多次無故宕機后被拉起，最終反復(fù)點火失敗導(dǎo)致應(yīng)用崩潰無法繼續(xù)服務(wù)。經(jīng)過大量試驗后，我們發(fā)現(xiàn)這一現(xiàn)象與JDK版本和GC無關(guān)，可以在多個輕量化配置上復(fù)現(xiàn)，現(xiàn)象為RSS在較長的一段時間內(nèi)持續(xù)上升，最終導(dǎo)致了應(yīng)用多次崩潰重啟。

由于是RSS持續(xù)上升，我們排查時首先懷疑是堆內(nèi)溢出。但是卻并沒有在應(yīng)用日志上發(fā)現(xiàn)OOM報錯，且使用JFR檢查堆內(nèi)存增長情況后也并沒有找到明顯的溢出跡象。所以我們進一步檢查了機器的dmesg日志，發(fā)現(xiàn)反復(fù)崩潰的原因是malloc申請不到內(nèi)存，導(dǎo)致內(nèi)核的oom_killer線程直接kill掉了DMESGTomcact進程，然后又被重啟腳本重新拉起。

由于堆內(nèi)存是基本穩(wěn)定的，我們使用NMT baseline對JVM的堆外內(nèi)存使用情況進行了檢查。雖然現(xiàn)代GC本身的native占用相對較高，但增長并不顯著，總體內(nèi)存使用很穩(wěn)定，也沒有泄露的傾向。

進一步向下排查，我們用 `gdb --batch --pid 36563 --ex "call malloc_trim()"` 強行回收內(nèi)存后，發(fā)現(xiàn)RSS有明顯下降，至此基本判斷是glibc這一塊造成了泄露問題。

3.2 內(nèi)存分配器

要解釋溢出的原因，首先需要了解一下內(nèi)存管理的機制。對于Java應(yīng)用來說，內(nèi)存管理一般分為四層：內(nèi)核負責(zé)管理和映射虛擬頁，glibc進行通用的內(nèi)存算法管理，JVM負責(zé)屏蔽內(nèi)存申請和回收的細節(jié)，而最上層才是Java應(yīng)用。

由于mmap和brk是系統(tǒng)調(diào)用，如果應(yīng)用每次申請內(nèi)存時都直接訪問內(nèi)核函數(shù)的話，性能會非常差，代碼實現(xiàn)也更加困難。所以，linux會使用通用的內(nèi)存分配算法來緩沖和規(guī)劃內(nèi)存的使用，其主要關(guān)注點在三個指標上：

減少申請和釋放操作的時間和開銷?減少小對象分配帶來的內(nèi)存碎片?減少分配器本身數(shù)據(jù)結(jié)構(gòu)的額外內(nèi)存開

3.3 默認分配器PTMALLOC的優(yōu)缺點

在默認情況下，glibc使用的是其原生的ptmalloc2內(nèi)存分配器，由以下三層數(shù)據(jù)結(jié)構(gòu)組成：

arena（分配區(qū)）是ptmalloc中的內(nèi)存緩沖區(qū)，在一個環(huán)形鏈表上被管理。也是ptmalloc中最小的鎖顆粒度。?bin（空閑鏈表）是arena中用于管理可用內(nèi)存塊的鏈表。不同的bins根據(jù)其管理的內(nèi)存塊大小而被分為fast、unsorted、small和large四種。chunk（內(nèi)存塊）則是用戶申請和釋放內(nèi)存的最小單位。bins的頭部永遠是一個被稱為top chunk的空閑塊，當(dāng)沒有合適的chunk時，會擴容并返回top chunk來處理請求。

ptmalloc作為標準實現(xiàn)，主要使用了以下幾個方法來優(yōu)化以上三個重要指標：

內(nèi)存池（減少頻繁的系統(tǒng)調(diào)用和內(nèi)存碎片）：用戶free掉的內(nèi)存，不會被直接被歸還給系統(tǒng)，而是暫存到bins中，供下次申請時直接分配。

多分配區(qū)（減少鎖競爭）：所有內(nèi)存操作都需要加鎖，如果沒有找到未上鎖的arena，則會新增一個副arena并上鎖，直到arena的數(shù)量上限。?

ptmalloc雖然滿足了內(nèi)存分配器的基本需求，但是本身實現(xiàn)有很多缺陷，導(dǎo)致了內(nèi)在的OOM傾向：

額外內(nèi)存開銷大：每個chunk都需要額外消耗8b的內(nèi)存，而chunk是內(nèi)存操作的最小單位，這會導(dǎo)致整體上浪費了非常多內(nèi)存。內(nèi)存利用率不穩(wěn)定：由于多分配區(qū)的機制，激烈的鎖競爭會導(dǎo)致副arena數(shù)量快速增多。并且，新增的副arena永遠不會被銷毀，且保留會其初始的chunk。這意味著在一臺16核的標準機器上最多會有128個arena，并占用高達8G的堆外緩沖區(qū)。多線程性能差：所有的內(nèi)存操作都需要進行悲觀鎖的加鎖解鎖操作，導(dǎo)致其性能較差。同時，即使有多分配區(qū)機制，在動輒500個以上線程的生產(chǎn)環(huán)境中這個并發(fā)量完全不夠。?回收機制簡陋：由于bins是鏈表結(jié)構(gòu)，ptmalloc的內(nèi)存收縮必須從上向下收縮，這意味著只要后申請的內(nèi)存沒有被釋放，之前申請的所有chunk都無法被收縮，這導(dǎo)致了在管理長周期內(nèi)存時，有內(nèi)存泄漏的可能性。

具體到這次詳情頁的溢出，則主要有三個原因：

前置條件：由于輕量化的需要，應(yīng)用目前僅僅能給堆外大約2.5G的空間。并且G1本身使用的堆外空間是CMS的4-6倍之多。而原來的32G的堆外空間充足，所以之前沒有發(fā)現(xiàn)類似問題。?由于大量的緩存、快照和報文的處理，應(yīng)用本身有非常頻繁和重量級的NIO和序列化/壓縮操作（尤其是點火的時候，線程數(shù)非常多），這導(dǎo)致了應(yīng)用會高頻的申請和釋放堆外內(nèi)存作為IO緩沖區(qū)。因此ptmalloc在這種情況下新增了大量的arena來避免頻繁的鎖競爭（下圖中有大量64M大小的內(nèi)存塊）。ptmalloc本身的釋放機制就導(dǎo)致申請的內(nèi)存被歸還的特別慢，甚至有內(nèi)存溢出的傾向，這些因素綜合在一起引起了OOM的發(fā)生。

3.4 解決方案JEMALLOC

考慮到ptmalloc的性能相對較差，我們將目光轉(zhuǎn)向了第三方的內(nèi)存管理器。無論是谷歌的tcmalloc還是臉書的jemalloc都完全是默認分配器的上位替代，各項性能遠超ptmalloc，并且遷移起來非常方便。雖然tcmalloc和jemalloc兩者之間優(yōu)劣差別不大，但是由于jemalloc相對優(yōu)秀的工具鏈，我們最終優(yōu)先對它進行了測試。

jemalloc是專精于多核多線程場景的內(nèi)存分配器，可以說在并發(fā)量越大的情況下，jemalloc的優(yōu)勢越明顯。對比pemalloc，jemalloc有以下的優(yōu)勢：

（1）內(nèi)存碎片率：jemalloc承諾至多20%的內(nèi)存碎片。

通過將內(nèi)存塊根據(jù)大小進一步細分為232個小類，同一個bins中的內(nèi)存塊大小一致，向上取整申請，來提高每個內(nèi)存塊在分配時的利用率和性能。（同樣處理10kb內(nèi)存的申請，返回10kb的 chunk和返回20kb的chunk之間肯定有區(qū)別）

采用了低地址優(yōu)先的分配策略，進一步降低了內(nèi)存碎片率。（使用紅黑樹記錄了地址排序，總是從低地址開始分配，使高地址的內(nèi)存更整塊）

（2）鎖的顆粒度：jemalloc在大部分場景下幾乎是無鎖的。

每個線程都擁有動態(tài)伸縮的緩存tcache，在小內(nèi)存操作時是無鎖的。

大部分的線程都會被綁定到專屬的arena上，使其操作無鎖化（類似于JVM的偏向鎖）。即使多個 線程共享一個arena，也會在arena內(nèi)部細化為局部鎖，而不是直接使用全局鎖。

（3）內(nèi)存回收：除了類似于ptmalloc的回收機制外，jemalloc還有兩種機制。

當(dāng)發(fā)現(xiàn)某個chunk全部都是臟頁后，會直接釋放整個chunk。

當(dāng)臟頁數(shù)量超過某個閾值的時候，進行主動的purge操作。

（4）額外開銷：僅僅占用約2%的額外內(nèi)存，用于存儲一些meta信息。

（5）工具鏈：jemalloc有完善的內(nèi)存分析工具，可以更好的定位溢出和泄露問題。

3.5 遷移和收益

對于簡單的性能測試，手動安裝jemalloc非常容易，甚至不需要重新編譯代碼，直接在一臺正常運行的機器上安裝好jemalloc后，修改tomcat的sh文件中將LD_PRELOAD變量指定為對應(yīng)的so文件覆蓋glibc動態(tài)庫并重啟tomcat即可。而后續(xù)容器部署也只需要在dockerfile中自定義數(shù)行代碼模擬上述操作，然后構(gòu)建并上傳自定義鏡像便能完成。

目前查詢服務(wù)已經(jīng)在jemalloc上生產(chǎn)運行了數(shù)個月，至今還沒有觀察到再次出現(xiàn)堆外溢出的問題；同時RSS的波動非常穩(wěn)定，即使遇到流量高峰也不會出現(xiàn)內(nèi)存尖刺，可以保持良好的響應(yīng)時間和穩(wěn)定。

從實際的情況來看，jemalloc與ptmalloc相比主要有以下收益：

從運維方面來看，集群為了方便調(diào)度，一般會限制幾個預(yù)設(shè)的容器配置以供選擇。在資源相對緊張的情況下，jemalloc可以使得應(yīng)用整體的部署更加靈活，而使用默認的ptmalloc則會被迫將容器配置向上升級，否則就需要額外對特殊配置進行審批和調(diào)度，這樣不但會造成不必要的資源浪費，同時在流量尖峰時也難以對集群進行調(diào)度和擴容。在成本方面，從測試結(jié)果出發(fā)，僅僅使用jemalloc本身就能比ptmalloc在每臺機器上節(jié)省1-1.5G的堆外內(nèi)存，雖然在單機上可能不夠顯著，但是推廣到整個云的范圍時收益應(yīng)該是非?？捎^的。性能上，jemalloc的內(nèi)存回收和多線程機制更加高效和智能化，對低配置機器更加友好，能大大加強內(nèi)存資源緊張的機器上服務(wù)的魯班性，同時對IO、GC、類加載等多線程native操作有較大的優(yōu)化。從遷移角度看，遷移到j(luò)emalloc幾乎是無成本的操作，僅僅需要簡單的鏡像自定義和一定的灰度測試，就可以完成優(yōu)化。

故綜合來看，jemalloc的收益相比于成本大得多的，有一定的分享和推廣的意義。

四、結(jié)語

本文相對完整的記述了酒店查詢服務(wù)在輕量化中的一次優(yōu)化過程，希望其中的經(jīng)驗和過程能對讀者有所幫助。然而，對于應(yīng)用的優(yōu)化過程是一個從猜想到驗證的循環(huán)。在有了可能的猜測和方向之后，比起反復(fù)的調(diào)研，更重要的則是不斷向著落地驗證去推進。雖然這些經(jīng)驗有一些普適性，但是由于應(yīng)用之間各有不同，仍然需要讀者根據(jù)實際情況親手試驗后，才能最終確定是否有借鑒意義。

關(guān)鍵詞：